I've sat on both sides of the interview table more times than I can count. Here's the thing nobody tells you going in: the interview almost never tests what it claims to.
You think it's testing SQL. It's testing whether you panic.
The whiteboard SQL problem
Somewhere along the way, "write a window function while a stranger watches" became a proxy for "will you be good at this job." It isn't. I've worked with people who nailed a ROW_NUMBER() OVER (PARTITION BY...) from memory, then shipped a pipeline that silently dropped 4% of records because nobody asked what "duplicate" meant to the business. I've also watched someone fumble join syntax live, apologize twice, and turn out to be exactly who you want paged at 2am when a DAG falls over.
The instinct that predicts job performance isn't recall. It's asking "what happens when this data is wrong, and who notices first?" Almost nobody tests for that directly.
What actually separates candidates
Two things, from what I've seen over and over:
- Whether they narrate their reasoning instead of going silent and typing
- Whether they ask a clarifying question before writing a line of code
That's most of the signal. Not cleverness — just, do they think like someone maintaining this in six months, or someone racing to produce an answer?
I once watched a candidate pick a "wrong" schema — normalized where I'd have gone semi-denormalized — but she named the exact tradeoff and the metric she'd watch to know if she'd guessed wrong. We hired her. The "correct" answer was never really the point.
Where I contradict myself
And yet I still ask SQL questions. Still make people code live, which everyone hates, me included. Because there's a floor you can't skip — if someone can't reason about a GROUP BY at all, no amount of narrated thinking saves that. The theater is annoying. It just isn't pure noise.
If you're early career
Stop sounding like you already know everything. Experienced interviewers can smell a memorized answer — the explanation stops adapting the moment someone pushes on it.
Instead: say "let me think out loud" and actually do it. Ask about data volume before picking an approach. Admit a design's weakness instead of defending it like it's your firstborn. None of that takes more study hours. It takes being a little less afraid of looking uncertain for forty-five minutes.
The part I keep coming back to
The interview is a lossy proxy. Someone great freezes and gets filtered out; someone mediocre gets through on a rehearsed question. That's not a scandal, it's just what happens compressing "will you be good at this for two years" into forty-five minutes and a shared screen.
So prep less syntax you'll forget by Thursday. Prep the muscle of thinking out loud when you don't know the answer yet. That's the actual job.
Top comments (3)
The self-contradiction section is the most honest part of the piece — "the theater is annoying. It just isn't pure noise" is exactly right, and most interview rants skip it because it weakens the thesis.
What I'd add from the operator side: the thing I actually test live isn't SQL recall, it's what a candidate does the moment the data contradicts their plan. I run small data pipelines where the real incidents are silent — a 4% drop nobody noticed, like your duplicate example — so I put a deliberately inconsistent row in the sample and watch whether they ask about it or route around it. Nobody has ever noticed that question being the differentiator, but it's the same instinct you describe as "who notices first." Did you find candidates ask about volume unprompted at a useful rate, or only after you nudge?
That “think out loud” muscle is underrated: I’ve found it helps to practice a 10-second loop—restate the goal, name assumptions, propose a simple approach, then check an edge case—before touching syntax. It makes a freeze recoverable and gives the interviewer useful signal even when the final query isn’t perfect.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.