Last Server Activity
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
- DoorDash
Problem
A server shows up in server_logs once for every line it writes, but we only care about the last time each one spoke. List every server with its most recent log timestamp, most recently active first, so the ones that have gone quiet sink to the bottom.
Each server's last heartbeat.
Tables
server_logs
Columns: log_id INTEGER, server_name TEXT, log_level TEXT, message TEXT, response_time_ms INTEGER, log_timestamp TEXT
| log_id | server_name | log_level | message | response_time_ms | log_timestamp |
|---|---|---|---|---|---|
| 137 | web-prod-02 | WARN | Connection timeout after 30s | 23 | 2026-02-02 01:07:13 |
| 174 | api-prod-01 | ERROR | Database query slow: 2.5s | NULL | 2026-03-03 02:14:26 |
| 211 | api-prod-02 | DEBUG | Cache miss for key user_123 | 49 | 2026-04-04 03:21:39 |
| 248 | db-primary | CRITICAL | Memory usage at 85% | 0 | 2026-05-05 04:28:52 |
| 285 | db-replica-01 | INFO | SSL certificate expires in 7 days | NULL | 2026-06-06 05:35:05 |
| 322 | cache-01 | WARN | Rate limit exceeded for IP 192.168.1.x | 88 | 2026-07-07 06:42:18 |
| 359 | worker-01 | ERROR | Disk space low: 10% remaining | 101 | 2026-08-08 07:49:31 |
| 396 | cdn-edge-us | DEBUG | New deployment v2.3.1 started | NULL | 2026-09-09 08:56:44 |
| 433 | cdn-edge-eu | CRITICAL | Health check passed | 127 | 2026-01-10 09:03:57 |
| 470 | monitor-01 | INFO | Failed to connect to upstream | 140 | 2026-02-11 10:10:10 |
Expected output
| server_name | last_activity |
|---|---|
| cdn-edge-us | 2026-09-09 08:56:44 |
| api-prod-01 | 2026-09-08 11:05:35 |
| worker-01 | 2026-09-07 14:14:26 |
| web-prod-02 | 2026-09-06 21:15:45 |
| cache-01 | 2026-09-06 17:59:41 |
Worked solution and explanation
This is a last-seen heartbeat check dressed up as a log query. server_logs holds one row per line a server wrote, so every server repeats many times, and the answer wants exactly one row per server carrying its latest log_timestamp. Anyone can sort the log newest first. The skill is collapsing each server to a single last-seen time and then sorting the servers by that time. Sort the raw lines instead and the first row looks right, but the list repeats busy servers and buries the quiet ones you were asked to find.
Walking to the answer
Step 1: Settle the grain first
One row per server is the output grain, so server_name is the only key you collapse on. Everything else on a log line (its log_level, its message, its response_time_ms) is noise for this question. Put any of it in the key and a server splits into several rows.
Step 2: Take the latest time per server
MAX(log_timestamp) per server_name is the last time each server spoke. You need only the time, not the rest of that line, so there is no row to pick and nothing to tie-break.
Step 3: Sort by the collapsed value
Name the aggregate once as last_activity and sort by it descending. The freshest server leads and the silent ones fall to the bottom, which is exactly where an on-call engineer reads.
The query
SELECT server_name, MAX(log_timestamp) AS last_activity
FROM server_logs
GROUP BY server_name
ORDER BY last_activity DESC- Sorting the raw lines
SELECT server_name, log_timestamp FROM server_logs ORDER BY log_timestamp DESCreturns all 200 lines.cdn-edge-ussits on top and then reappears further down, and a quiet server only shows up after you scroll past every busy one.- Collapsing first
- Grouping on
server_namewithMAX(log_timestamp)returns 11 rows, one per server. The last row is the server that has been silent the longest.
Common follow-up questions
- How would you list only the servers that have logged nothing in the last hour? (Moves the condition onto the collapsed value: filtering servers after their last-seen time is computed.)
- What if you also need the `log_level` and `message` of each server's last line? (Now the whole row matters, so picking the latest line per server, with a tie rule, comes back.)
- A server that never logged does not appear in `server_logs` at all. How would you still report it? (Needs a registry of expected servers kept on the outer side of a join to the log.)
- How would you keep this cheap once `server_logs` reaches billions of rows? (Partition pruning, or a last-seen table maintained incrementally as lines arrive.)