Your SQL Take-Home Is Marked in the Margins

How many minutes did HealSync’s doctors spend on telemedicine sessions in 2023?

That was the whole question: one line, two tables, and a note saying it should take “no more than two hours”. It came as a take-home for an analyst job at a hospital network, and the candidate in this story, Noor (invented, like the job), spent three, naturally, because nobody in the history of take-homes has spent two.

The tables, though, are real practice data. They belong to HealSync, the fictional hospital network behind our book Explain Your Query, and they’re messy on purpose, the way practice data should be.

So Noor did what a conscientious candidate does. She joined the sessions to the staff table, so the answer could be broken down by doctor if anyone asked. She checked that every date fell in 2023 (they do, 1 January to 31 December). She wrote a tidy query with sensible aliases, and it came back with 7,056. She formatted it nicely and sent it off.

A week later: “Thank you for your time. We’ve decided to move forward with other candidates.”

Which leaves the question Noor spent that evening asking the ceiling: what, exactly, was wrong with 7,056?

7,056 is a real number

That’s the maddening part. Nothing about 7,056 is invented. Run Noor’s query on those tables and that’s what comes back: no error, no warning, no little red squiggle. If the marker’s answer key had said 7,056, she’d have sailed through.

It didn’t, because there’s no single number to put on it. We ran the question the way four different, perfectly reasonable candidates might:

-- 7,383: every row
SELECT SUM(Duration_Minutes) FROM telemedicine_usage;

-- 7,160: each session once
SELECT SUM(Duration_Minutes)
FROM (SELECT DISTINCT * FROM telemedicine_usage);

-- 7,056: Noor's query, joined to the staff first
SELECT SUM(t.Duration_Minutes)
FROM telemedicine_usage t
JOIN healthcare_workforce w
  ON w.Worker_ID = t.Doctor_ID;

-- 6,833: each session once, doctor on file
SELECT SUM(t.Duration_Minutes)
FROM (SELECT DISTINCT * FROM telemedicine_usage) t
JOIN healthcare_workforce w
  ON w.Worker_ID = t.Doctor_ID;

Four queries, four numbers, zero errors. Here’s where the differences come from. Three sessions (IDs 2011, 2029 and 2047) appear twice, identical down to the minute, so summing every row counts their minutes twice. And a handful of sessions name a Doctor_ID that isn’t in the staff table at all: staff IDs run from 5001 to 5100, and these start with a 3. An inner join keeps only rows that find a match, so it quietly drops those sessions, minutes and all. That’s not a bug. It’s the job description of an inner join.

Each of those is a decision. Count the duplicates once or twice? And are doctors missing from the staff list “HealSync’s doctors” or not? Two decisions, two choices each, four answers. Noor’s submission had one of the four on it. So which decisions had she taken?

Her join had taken both.

That’s what the marker saw. Not a wrong number: an unexplained one. 7,056 keeps the duplicates and drops the missing doctors, and nowhere in Noor’s submission is there a sentence saying either of those was on purpose. The join she added as a courtesy, for a breakdown nobody had asked for yet, made two decisions about the data on her behalf, and didn’t tell her.

Now picture a candidate who sends 7,160 with three short lines above it. The number differs from Noor’s. It’s also the submission that gets a call back, and not because 7,160 is “the” answer. It’s because if the team meant something else, they can see exactly which line to change.

What the marker is actually reading

In a question this short, the vagueness is part of the test, whether the person who wrote it planned that or not. Real requests arrive exactly like this: a line long and missing half their definitions. The job is noticing what’s missing before you answer, and a take-home is the cheapest place for a team to find out whether you do.

None of those three needs cleverer SQL. Noor’s SQL was fine. What it lacked was the sentence before it and the sentence after it.

The live version, said out loud

A live SQL round is the same test with less time and an audience. The expensive part is the silence while you type, because an interviewer can’t give marks for reasoning they can’t hear.

Our two-page cheat sheet for live tests uses a six-step spoken framework: restate the question, name the grain and the key, plan, write, check, then explain the result and its limits. Here it is, worked on Noor’s question.

Step five costs one query. Put the two counts side by side before you trust any sum:

SELECT COUNT(*)                 AS all_rows,
       COUNT(DISTINCT Usage_ID) AS sessions
FROM telemedicine_usage;

Two numbers that should match, and don’t. Say that out loud and you’ve shown the interviewer the habit a live round is really looking for. Then do the same around every join: count before, count after, and say why they differ.

For daily practice, PlexQuest posts a new SQL quest every morning. Treat each one as a take-home in miniature: write your assumption line first, count the rows before you trust them, and only then submit.

The answer key problem

Here’s the snag, though. Suppose you do everything right. You state that you kept the sessions with missing doctors, you explain why, you send 7,160. But the marker’s key says 6,833, because on their team the staff table is the source of truth, and nobody thought to say so in a one-line question.

If a well-argued answer can still lose to the key, what is a take-home really measuring?