Low Latency API Calls

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

Domain: SQL
Difficulty: easy
Seniority: L3
Asked in: British Airways

Problem

A call that took exactly 100 milliseconds still counts as fast in our baseline, and so does anything quicker. Pull every qualifying call record from api_calls in full, fastest first, with equally fast calls listed by call_id, lowest first.

Fast endpoints. Confirmed fast.

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_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

First 5 of 165 rows
call_id	endpoint	method	status	latency	user_id	call_time	err_msg
16000	/api/v1/users	GET	200	1	4950	2023-01-01 00:00:00	NULL
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
21000	/api/v1/users	GET	200	10	2137	2026-02-01 00:00:00	NULL
8474	/api/v2/analytics	post	400	22.7	585	2026-07-07 06:42:00	Not found

Worked solution and explanation

Why this problem exists in real interviews

Querying api_calls for endpoint data using query construction tests whether you can translate a business requirement into the right column references and filter sequence. It shows up as a fundamentals check to verify practical fluency.

Break down the requirements

Step 1: Filter to the target rows

Filter api_calls to rows where latency is at or below the 100ms fast-call threshold

Step 2: Order the final output

Return all columns for matching call records

The solution

Threshold filter for baseline dataset

SELECT * FROM api_calls WHERE latency <= 100 ORDER BY latency ASC, call_id ASC

Common follow-up questions

What happens to your result if `api_calls`.err_msg contains NULLs for some rows? (Tests whether the candidate accounts for NULL behavior in aggregates and comparisons on `err_msg`.)
How would you verify that your aggregation on `api_calls`.call_id is not double-counting due to duplicate rows? (Tests data quality awareness and deduplication strategies.)
With millions of distinct values in `api_calls`.call_id, what index strategy would you use to keep this query performant? (Tests indexing knowledge specific to high-cardinality columns like `call_id`.)