Clarify, then plan, then code
Restate, confirm with an example, ask what changes the code, then agree a plan before the first keystroke.
Predict first
Before you read: predict
Pair round, 45 minutes. The interviewer says: “Build ExamHall's countdown for the exam page; it shows the time left.” You have heard the task once and nothing is typed yet.
What do you do first?
The 30-second version
Before typing, say the task back, pin it with one concrete example, and ask only the questions whose answers change the code. Read any interface or tests you were given first. Then outline the approach, name what you set aside, and agree it with the interviewer. An unclarified start builds the wrong thing quickly.
Restate, confirm with an example, ask what changes the code, then agree a plan before the first keystroke.
How it works
Step 1 of 7
Analogy: A signwriter and the shop's fascia board
A shop owner says, “Paint the name above the window.” The signwriter reads the name back letter by letter: “S, M, Y, T, H, apostrophe, S?” She asks only what changes the board: does the street number go on, and may it run to two lines if it does not fit? She does not ask which paint brand the owner likes. She chalks the full-size layout on the board, the owner nods, and only then does she open the paint. A signwriter who starts at once has “SMITHS” half-finished in gloss when the owner comes out.
| At the shopfront | In the pair round |
|---|---|
| Reading the name back letter by letter | Saying the task back in your own words |
| The chalked full-size layout | One worked example of input and output |
| “Two lines if it doesn't fit?” | A question whose answer changes the design |
| Not asking about the paint brand | Not asking what changes nothing |
| The owner's nod at the chalk | Agreement on the plan before typing |
| “SMITHS” half-painted in gloss | Code built fast on a guess |
Breaks down when: paint is hard to remove, while code is cheap to change. The cost in the round is the clock and the impression, and you can still ask mid-task. Wrong inference: “after the first keystroke, questions are forbidden.” A shop owner also cannot test the sign; an interviewer may hand you tests that already answer some questions.
In real terms: before the first keystroke, one restatement, one example, the few design-changing questions, and a plan the interviewer has agreed.
Examples, run for real
EXH-3130 is a synthetic recording of a practice pair round. The task, as spoken, is “Build ExamHall's countdown for the exam page; it shows the time left.” The interviewer's notes hold three facts the task leaves out, and give each only when asked. It then runs both builds on one virtual-clock session (a candidate who joins at 09:10, and a laptop asleep from 09:20 to 09:32) against the three examples opening B agreed before typing. The timestamps are the author's hand labels on the fixture.
EXH-3130 opening A: first keystroke 00:35 · facts known before typing 0 of 3
F1 the end time is the server deadline endsAt, not a 45-minute duration: surfaced 09:40 · code already written 9.1 min
F2 the display must be right after the laptop sleeps: surfaced 16:10 · code already written 15.6 min
F3 at zero it shows "Time is up": surfaced 21:30 · code already written 20.9 min
EXH-3130 opening B: first keystroke 04:30 · plan agreed 04:15 · facts known before typing 3 of 3
F1 the end time is the server deadline endsAt, not a 45-minute duration: surfaced 01:20 · code already written 0.0 min
F2 the display must be right after the laptop sleeps: surfaced 02:40 · code already written 0.0 min
F3 at zero it shows "Time is up": surfaced 02:05 · code already written 0.0 min
E1 09:10:00 (joins 10 minutes late): agreed "35:00" · build A "45:00" · build B "35:00"
E2 09:32:01 (one second after the laptop wakes): agreed "12:59" · build A "34:59" · build B "12:59"
E3 09:45:03 (three seconds past the deadline): agreed "Time is up" · build A "21:57" · build B "Time is up"
agreed examples passed: build A 0 of 3 · build B (MR !3430) 3 of 3
Opening A had a timer on screen within a minute. Each missing fact then arrived from the interviewer, after 9 to 21 minutes of code built on a 45-minute duration. Its build fails all three agreed examples, and each failure maps to a question nobody asked.
Opening B spent four and a half minutes before typing: a restatement, three questions, one worked example (“ends 09:45, opened at 09:10, it shows 35:00”), and a plan the interviewer agreed. MR !3430 passes all three. Why build A drifts is fsd-clock-sync-timers' lesson; here the point is when each question was asked.
The script counts and compares; it does not judge whether a question was well phrased. A real recording would need a person to tag it.
Try it
Answer first, then check. Nothing is saved.
Question 1 of 6
Pair round on a payments ledger. The interviewer says: “Write applyRefund(ledger, refund).” You are about to say the task back before planning.
Which of these do you say?
Question 2 of 6
Pair round. You and the interviewer have agreed what reconcile(bankLines, ledgerEntries) must return, with one worked example. Nothing is typed yet.
What do you do with your approach now?
Question 3 of 6
Pair round: “Write settledTotal(payouts, day) for a merchant's daily statement; it returns the day's total in pence.” You have confirmed the input shape and agreed one example.
Which question is still worth asking before you plan?
Question 4 of 6
Pair round in the Monzo style: a Ledger interface with three empty methods, a short description of each, and a test file.
The interviewer says, “Over to you.” What do you do first?
Question 5 of 6
A recorded mock round. 00:00 the task: “Write applyFee(payment).” 01:00 the candidate says it back with an example the interviewer confirms: a 100.00 GBP payment pays a 2.00 fee. 03:30, while the candidate outlines one flat 2% rule, the interviewer adds: “Payments in other currencies pay a fixed 0.50 instead.” The candidate says “Noted” and finishes outlining. 05:40 the candidate starts typing the flat 2% rule. 15:00 the candidate reaches the currency case and rewrites the function.
What went wrong?
Question 6 of 6
A learner's three recorded mock payments rounds each open with 10–12 minutes of questions, and none is finished.
The interviewer's notes say: “Asked, one by one: input size, the Node version, tabs or spaces, variable names, which refunds count.” Which change to the opening fixes this?
Go deeper
Pro tip
Time your next three practice openings with a stopwatch, from the last word of the task to your first keystroke. After each round, write down the one question you most wish you had asked, and when its answer reached you.
Related lessons
- Related: Narrating while you code
- Related: Problem framing
- Related: Scope and time-box a take-home
- Related: RADIO: driving a frontend design round
- Related: Running a backend design round
- Related: Server-authoritative time and client timers
- Related: Testing as you go
- Related: Taking hints and getting unstuck: name the piece, shrink the problem, and use a hint at once
- Related: Extending an existing codebase live
Checked against the tools and docs as of 2026-10-06.