The live exercise, where silence is scored

The setup

Forty-five to sixty minutes, a shared editor or a SQL sandbox, one or two problems, one or two interviewers watching. Sometimes on your own machine with your screen shared, which is better because you keep your own tools.

The four moves, in order

Restate the question. “So you want, for each customer, the date of their second order, and customers with only one order should still appear, with a null.” Thirty seconds, and it catches half of all misunderstandings before they cost you twenty minutes.

State your assumptions out loud. “I am assuming order_id is unique and that cancelled orders should be excluded, is that right?” Interviewers will usually tell you. Assumptions you keep to yourself become wrong answers.

Name the approach before typing. “I will use a window function to number each customer’s orders by date, then filter to row number two.” Now the interviewer can correct your direction before you spend fifteen minutes implementing it.

Check the answer against a case you can compute in your head. Take one customer with three orders and verify by eye. Candidates who do this are rare and it is noticed every time.

Why narration decides the outcome

The interviewer cannot see your thinking. They see keystrokes and hear words. A candidate thinking brilliantly in silence for four minutes and a candidate who is completely lost look identical from the other side of the screen.

So a candidate who says ”before I write this I want to check whether joining to order_items can duplicate rows” scores above one who silently writes the same correct query, because the first has demonstrated the reasoning, and the reasoning is what transfers to the job.

What to say when you are stuck

Be precise about the boundary of what you know. This is a strong answer:

“I know I need the second highest value per group. I am deciding between a window function and a correlated subquery. I would use row_number() over a partition, but I do not remember the exact syntax for the frame clause. May I check the documentation?”

That tells the interviewer you understand the problem, know two approaches, and have a normal professional relationship with reference material. Almost every interviewer says yes to the documentation question, and a refusal tells you something about the job.

The only wrong response is freezing. If your mind empties, say so (”I have lost the thread, give me twenty seconds”) and then restate the question aloud. Restating restarts thinking more reliably than staring.

The exercises that actually come up

• Aggregate with a join, then a group-level filter.
• A cleaning question: “this date column has five different formats: what do you do?”
• “Explain what this query does”: reading, not writing.
• “What would you check before trusting this number?”: the reconciliation answer from the spreadsheet lesson.
• Debugging somebody else’s broken query or script. This one is increasingly common, because it is closest to the job.

The pitfalls that cost points

• count(*) after a left join, which counts one for the null row too. Use count(column_from_the_right_table).
• A where clause on a left-joined table, which quietly turns it into an inner join: the null rows fail the predicate and disappear. Move the condition into the on clause.
• Summing a left-table column after a one-to-many join. The fan-out again.
• Money in floating point. 0.1 + 0.2 is not 0.3, and financial totals drift. Use a decimal or integer minor units.
• Assuming null behaves like zero or like an empty string. It behaves like neither.

Practising for free

You do not need a subscription. DuckDB with a downloaded CSV gives you a sandbox in one command. SQLZoo, pgexercises and Kaggle’s SQL courses are free and cover more than most interviews test. For live conditions, the thing that helps most is doing it with somebody watching: swap sessions with a peer, since the difficulty is the observation and not the SQL.

The limitation

Live coding measures composure under observation at least as much as it measures skill. Competent working engineers fail these regularly, and people who have rehearsed pass while being no better at the job. That is a known weakness of the format, not a judgement about you.

The implication is practical: the fix for failing live exercises is rehearsal with an audience, not more study. If you can solve the problem alone in ten minutes and not in the room, another course will not help you. Ten mock sessions will.