Once and Only Once

A hard SQL interview practice problem on DataDriven. Write the query and run it against a real database, with instant feedback.

Domain
SQL
Difficulty
hard
Seniority
L4
Asked in
LinkedIn

Problem

On-call is triaging latency anomalies, where a reading that recurs is routine noise but a reading seen a single time is the real signal. For each endpoint, surface the highest such one-off latency, worst first.

Repeated readings are noise. The value seen a single time is the signal.

Tables

api_calls

Columns: call_id INTEGER, endpoint TEXT, method TEXT, status INTEGER, latency REAL, user_id INTEGER, call_time TEXT, err_msg TEXT

api_calls: 10 of 670 rows
call_idendpointmethodstatuslatencyuser_idcall_timeerr_msg
8079/api/v1/ordersPOST2004.21002026-02-02 01:07:00NULL
8158/api/v2/productsPUT2007.91972026-03-03 02:14:00NULL
8237/api/v1/searchDELETE20111.62942026-04-04 03:21:00NULL
8316/api/v1/auth/loginPATCH20415.33912026-05-05 04:28:00NULL
8395/api/v1/auth/logoutget30119NULL2026-06-06 05:35:00NULL
8474/api/v2/analyticspost40022.75852026-07-07 06:42:00Not found
8553/api/v1/paymentsGET40126.46822026-08-08 07:49:00Unauthorized
8632/api/v1/users/POST40330.17792026-09-09 08:56:00Rate limit exceeded
8711/api/v2/products/PUT40433.88762026-01-10 09:03:00Internal server error
8790/api/v1/usersDELETE50037.5NULL2026-02-11 10:10:00Bad gateway

Expected output

First 5 of 12 rows
endpointrarest_highest
/api/v1/search1713.7
/api/v2/products1696.4
/api/v1/orders1679.1
/api/v1/users1661.8
/api/v1/auth/logout1644.5

Worked solution and explanation

What this is really testing

Strip the SRE costume off and this is a singleton filter wearing a max. The real question: within each endpoint, which latency values were recorded exactly once, and of those, which is the largest? Anyone can write MAX(latency) grouped by endpoint. The catch is that the loudest latency on an endpoint can be a value that fired more than once, a systemic slow path, not a one-off. Filter for 'exactly once' AFTER you count occurrences, or you will hand on-call a recurring reading and label it an anomaly.


Why a plain MAX fails

Naive: MAX(latency) per endpoint
Takes the tallest reading per endpoint whatever its count. If an endpoint logged 1200 ms twice and 900 ms once, this reports 1200: a recurring slow path, exactly the noise on-call wants to ignore.
Correct: MAX over the one-offs
Drops 1200 first because its count is 2, so the answer for that endpoint is 900. The filter changes which reading wins, not just how it is computed.

Step 1: Count occurrences per endpoint and latency

Count occurrences per endpoint and latency with GROUP BY endpoint, latency. This gives you one group per distinct latency an endpoint saw, along with how many times it fired.

Step 2: Keep the exactly-once values

Keep only the singletons with HAVING COUNT(*) = 1. This is the post-aggregation predicate: it runs on the grouped counts, which is why WHERE cannot express it. What survives is the set of one-off latencies for each endpoint.

Step 3: Take the highest per endpoint

Take the tallest survivor per endpoint with an outer GROUP BY endpoint and MAX(latency), then sort by that max descending so the worst offenders sit on top.

Max of the one-off latencies per endpoint
SELECT endpoint, MAX(latency) AS rarest_highest
FROM (
    SELECT endpoint, latency
    FROM api_calls
    GROUP BY endpoint, latency
    HAVING COUNT(*) = 1
) unique_vals
GROUP BY endpoint
ORDER BY rarest_highest DESC

Common follow-up questions