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 (0)