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
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
| call_id | endpoint | method | status | latency | user_id | call_time | err_msg |
|---|---|---|---|---|---|---|---|
| 8079 | /api/v1/orders | POST | 200 | 4.2 | 100 | 2026-02-02 01:07:00 | NULL |
| 8158 | /api/v2/products | PUT | 200 | 7.9 | 197 | 2026-03-03 02:14:00 | NULL |
| 8237 | /api/v1/search | DELETE | 201 | 11.6 | 294 | 2026-04-04 03:21:00 | NULL |
| 8316 | /api/v1/auth/login | PATCH | 204 | 15.3 | 391 | 2026-05-05 04:28:00 | NULL |
| 8395 | /api/v1/auth/logout | get | 301 | 19 | NULL | 2026-06-06 05:35:00 | NULL |
| 8474 | /api/v2/analytics | post | 400 | 22.7 | 585 | 2026-07-07 06:42:00 | Not found |
| 8553 | /api/v1/payments | GET | 401 | 26.4 | 682 | 2026-08-08 07:49:00 | Unauthorized |
| 8632 | /api/v1/users/ | POST | 403 | 30.1 | 779 | 2026-09-09 08:56:00 | Rate limit exceeded |
| 8711 | /api/v2/products/ | PUT | 404 | 33.8 | 876 | 2026-01-10 09:03:00 | Internal server error |
| 8790 | /api/v1/users | DELETE | 500 | 37.5 | NULL | 2026-02-11 10:10:00 | Bad gateway |
Expected output
| endpoint | rarest_highest |
|---|---|
| /api/v1/search | 1713.7 |
| /api/v2/products | 1696.4 |
| /api/v1/orders | 1679.1 |
| /api/v1/users | 1661.8 |
| /api/v1/auth/logout | 1644.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.
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 DESCCommon follow-up questions
- If 'seen exactly once' meant once across the entire table rather than once per endpoint, how would the query change, and when would the two answers differ? (Tests whether the candidate can rescope the singleton predicate from per-endpoint to global and reason about when the two answers diverge.)
- Suppose the definition softened to 'recorded at most twice' instead of exactly once. What is the one change, and does the shape of the result stay the same? (Probes generalizing a fixed count threshold into a parameterized rarity band.)
- How would you make endpoints with no one-off latency still appear in the output with a NULL, rather than dropping out? (Tests handling of endpoints that produce no qualifying row and whether they should surface with a NULL.)