Interviewing
How to Prepare for the SQL Interview Round
Four things a screen scores you on, in the order the interviewer checks them.
It opens on your dashboard and ticks itself off as you go. Every step below is a chapter or an exercise that already ships.
01
When you finish, you can
You can take a vague prompt to a defended answer and explain the cost.
Screen day You can hold a live SQL screen
02
The plan, 4 parts
Ordered by what each one buys you, not by topic. Every step says why it is here.
Part 01 · ~1h
Read the prompt, not the schema
You restate the ask and pin the output contract before writing SQL.
Skip this if you already state grain, ties and NULL handling unprompted.
- SectionReading a prompt and restating it6 minRestating buys thinking time and catches the ambiguity for free.
- SectionGrain, filters, time, dedupe, output7 minFive questions. Most wrong answers are wrong here, not in the syntax.
- SectionColumns, ordering, ties, NULLs7 minSay what the result looks like before you build it. Ties included.
- SectionDiagnosing table grain first6 minOne row per what? Ask the table, not the column names.
- ExerciseInterview country revenue contract18 minin the studioThe contract, made real: the shape is graded, not just the number.
- InterviewLogical vs physical schema6 minChecks you separate what data means from how it is stored.
- QuestionsSQL · Query formulation15 minTwenty prompts. Say the contract out loud before writing.
Part 02 · ~2h
The join, and what it did to your number
You can predict a row count and prove why a total doubled.
Skip this if you check join cardinality before trusting any SUM.
- SectionPredicting row counts7 minPredict the row count before running it. Then check you were right.
- SectionFan-out: when a join doubles a metric7 minThe number looks plausible. That is what makes it dangerous.
- SectionON vs WHERE: the LEFT JOIN trap6 minA filter in the wrong clause turns LEFT JOIN into INNER.
- SectionSemi & anti joins6 minExistence without multiplying. The fix for half of all fan-outs.
- InterviewIN vs EXISTS6 minThe NULL behaviour is the answer. The speed answer is folklore.
- ExerciseInterview fanout-safe order revenue20 minin the studioProve the total survives the join. Then say how you proved it.
- ExerciseAmazon: net revenue across two fan-outs30 minin the studioTwo fan-outs at once. One fix does not cover both.
- InterviewDISTINCT vs GROUP BY6 minA DISTINCT that fixes the row count usually leaves the SUM wrong.
- ExerciseReconcile order totals18 minin the studioTwo totals disagree. Find which join is lying about the grain.
- QuestionsSQL · Output prediction15 minThe query runs. Say what comes back without running it.
Part 03 · ~3h
Windows, ordering and ties
You pick the right ranking function and handle ties deliberately.
Skip this if you can say when RANK and ROW_NUMBER differ, and why.
- SectionOVER: partition, order & frame7 minThe frame is the part nobody reads. It changes answers.
- SectionRANK vs DENSE_RANK vs ROW_NUMBER6 minReported verbatim in loop after loop. Know which one ties need.
- SectionTop N per group6 minOn the screen in almost every loop. Usually "top 3 per day".
- SectionLAG & LEAD for event sequences6 min"What happened next" is a window question, not a self-join.
- SectionFiltering window results safely6 minYou cannot filter a window in WHERE. Know where it goes instead.
- ExerciseInterview top buyers with ties18 minin the studioTies are where a nearly-right answer gets marked wrong.
- ExerciseInterview latest snapshot status18 minin the studioLatest row per key. The most reused window pattern there is.
- InterviewDid B happen right after A?6 minReported at Apple as AirPods-after-iPhone. "Immediately" is the word.
- ExerciseGoogle Ads: last-touch attribution in a 7-day window35 minin the studioLast touch inside a window. Ordering and the boundary both matter.
- ExerciseNetflix: a 7-day unique count you cannot add up35 minin the studioA 7-day unique count you cannot add up. Additivity, asked as SQL.
- QuestionsSQL · Conceptual15 minExplain it with no editor open. The second half of a screen.
Part 04 · ~2h
The follow-ups: NULLs, cost, and the explanation
You can find your own bug and argue the cost of your query.
Nothing to skip — this is the half of the screen nobody rehearses.
- SectionEdge-case checklist6 minNULLs, empty groups, duplicates. Rejection notes name these.
- ExerciseStripe: reconcile the processor against the ledger35 minin the studioReconcile a processor against a ledger. Missing on each side, and why.
- InterviewReconciling two systems6 minFULL OUTER, then classify. Matching totals is not reconciliation.
- SectionReading a query plan7 minRead the plan aloud. Guessing at indexes is a junior tell.
- InterviewWhy is this query slow?6 minFive buckets. Have the structure before they ask for the plan.
- ExerciseInterview query-cost triage18 minin the studioBytes are dollars. Triage the query nobody wants to pay for.
- InterviewProving the optimization worked6 minSame answer, less money. The first half is the one people skip.
- SectionLive debugging strategy6 minYour query is wrong and they are watching. Have a method.
- SectionFinal answer narration6 minClose out loud: what it returns, what you assumed, what next.
- QuestionsSQL · Debug & fix15 minIt runs, the number is plausible, and it is wrong. Find it.
03
Start it now
Reading is free and needs no account. The plan itself tracks on your dashboard.
