The SQL round's answer key is unwritten, and that is the interviewer's defect

The rubric splits in an awkward place. Of the three scored dimensions, only edge-case correctness leaves evidence in the query itself; clarification and narration happen out loud and are then gone ^[6]. Two thirds of the weight sits in one person's recollection of a conversation, and the guide says plainly that the recollection can outrank the code: a correct query written in silence earns a weaker write-up than a slightly imperfect one the candidate explained ^[5]. Read as an instruction to interviewers rather than advice to candidates, that sentence concedes the round will sometimes rank the worse answer higher.

The ambiguity is not accidental either. According to the dev.to guide, interviewers plant the question of what counts as an active user on purpose ^[7], and rarely hand over a clean specification because the job never does ^[8]. As a simulation of the work, defensible. The difference is that on the job an analyst already knows requirements arrive incomplete and that pushing back is expected, while in the room the prompt reads like an exam question and answering the question asked is the trained response.

One of the three shapes has no correct answer at all ^[10]. The guide's example is whether retention improved after a March release, where there is no single correct query and the interviewer is watching how the candidate decomposes it ^[9]; the buried trap is that the March cohort has had less time to churn than the February one ^[11]. That is a good question and the least auditable part of the round. Whether the candidate spots the cohort window asymmetry is a checkable item. Whether their definition of retention matches the one in the interviewer's head is not, unless somebody wrote that definition down first.

Then the variants. The analyst version weights breadth and business translation, with more questions, less depth in each, and definitional precision valued over query elegance ^[12], and the guide calls confusing the variants the most common preparation mistake in the function ^[13]. It is also the most available interviewer mistake, and much harder to catch: a candidate who prepared for the wrong variant usually finds out, while a panel scoring a data scientist's depth against an analyst's breadth simply records a weak signal and moves on.

Volume is what makes this expensive. SQL sits 0.7 percentage points ahead of Python in the 2025 Stack Overflow figures ^[14] and turns up in loops for roles that are not nominally data roles at all ^[15]. So the round is run often, frequently by people whose main job is not running it, against a scoring key that is mostly unwritten. None of the repairs need new questions. They need an answer key produced before the call: which planted ambiguity counts, which edge cases count as noticed, and which variant of the round this actually is. That is the half of the interview nobody prepares for.