In a coding interview, how do you narrate a fork between two approaches before writing code?
answer
- the interviewer is scoring the choosing
- two candidates out loud, not one
- one line of cost each, not a lecture
- then pick one, and say why
- end on a question, then stop talking
basics
~20 sState each approach in a sentence or two, name the cost that separates them, say which one you would take and why, then ask the interviewer to confirm before you write a line of code.
solid answer
~50 sThe fork is the moment an interviewer can actually score, so make it audible in four beats. Beat one and two: name each candidate approach and the single cost that characterises it — "a direct scan, easy to get right, but it re-checks everything on every query" versus "build a lookup structure once, more memory and more code, then each check is cheap". Beat three: pick one and say what made you pick it, tying the choice to a constraint you already clarified. Beat four: check in — "I'd go with the second, shall I start there?" — and then stop talking and listen. The check-in is cheap insurance: redirecting a plan costs seconds, redirecting twenty lines of code costs the round. It also invites the interviewer to hand you a constraint they were holding back.
go deeper
Be ready to speak two approaches before you type anything. Rehearse the four beats until they are automatic: approach A and its cost, approach B and its cost, your pick with a reason, then a direct question to the interviewer.
Expect to justify the tradeoff rather than just name it: which resource each branch spends, and which constraint makes that resource cheap here. What is listened for is whether your pick actually follows from the costs you just stated.
Show that the agreed plan stays live. Refer back to it while coding, and announce any deviation the moment you notice it. Quietly drifting away from a plan you committed to two minutes ago reads worse than never having planned.
Own the framing itself. Surface the constraint that decides the fork — expected size, how often it is queried, who maintains the result — and make the interviewer a participant in the decision rather than an approver of a plan you present finished.
## Why the fork is the scoreable moment An interviewer has almost no access to your reasoning except what you say out loud. Two candidates can write the same accepted solution and be scored differently, because one of them made the *choosing* visible and the other only made the *typing* visible. In a scheduling assistant that must flag whether a newly requested booking collides with what is already on a shared calendar, there is usually more than one workable shape of solution. The interviewer already knows that. What they do not know is whether you know it, whether you can price the options, and whether you can commit to one without dithering. The fork narration is the artefact that answers all three in about ninety seconds. ## The four beats **1 and 2 — name each approach and its characteristic cost.** One or two sentences each, no more. "The direct version checks the new booking against every existing one. It is obvious, hard to get wrong, and does full work on every request." "The other version pays a setup cost once and builds an auxiliary structure, so each later check is cheap, at the price of extra memory and more code to get right." You are not lecturing; you are labelling. The cost you name should be the one that actually distinguishes them — time per query, extra memory, code you can finish in the time available, or how badly it degrades when the input grows. **3 — pick, and say why.** This beat is the one most candidates drop. Two approaches described and neither chosen reads as indecision, not thoroughness. Tie the pick to something concrete: a constraint you clarified earlier ("you said a calendar rarely holds more than a few dozen entries"), a risk ("the simpler one I can finish and test in the time we have"), or an intended path ("I'll start simple and upgrade if we care about repeated queries"). **4 — check in, once, and then stop.** "I'd go with the second — shall I start there?" Then be quiet. Silence after a question is not awkward; it is the interviewer's turn. What you get back is worth having: a confirmation, a nudge toward the other branch, or a constraint they were deliberately withholding until you asked ("assume the calendar is huge and queries are frequent"). This is why the check-in beats simply announcing your choice — an announcement invites no correction, a question does. ## Why before coding, specifically Correction is cheap in prose and expensive in code. A plan you spoke in three sentences can be redirected in one sentence. Twenty lines already typed create sunk-cost pressure on both sides: you defend them, the interviewer hesitates to make you throw them away, and you burn the middle of the session on an approach that was known to be wrong at minute six. The check-in moves the cheapest possible correction to the earliest possible moment. It also converts your plan into a shared reference. Once the interviewer has agreed to approach B, everything after that can be narrated against it: "this is the setup step we talked about", "this is where I said the memory goes". That is far less talking for far more signal than commentary invented on the fly. ## Failure modes to avoid - **Typing first, narrating after.** Post-hoc explanation cannot be redirected, and it reads as reconstruction rather than reasoning. - **Presenting one approach as if no alternative existed.** Even when you strongly prefer one, naming the one you rejected and why is nearly free and shows you searched. - **Describing both and choosing neither.** The interviewer will eventually choose for you, and you will have shown that you cannot. - **Turning the check-in into a request for the answer.** "Which one do you want me to do?" hands over the decision. "I'd take the second because X — does that match what you have in mind?" keeps it. - **Checking in constantly.** Once at the fork, and again only at genuine decision points. Permission-seeking every few lines reads as low confidence. ## When you genuinely see only one approach Say so, honestly, and price it anyway: "The only thing I see right now is the direct scan. Its weak point is that it repeats work on every request — I suspect there's something better if repeated queries matter. Shall I get the direct version correct first and then look at that?" That is a strong answer. It names the approach, names the weakness, offers a plan, and checks in. Inventing a straw second option to fill the script is worse than admitting you see one path. ## The register Two sentences per branch, not two minutes. Speak in decisions and costs, not in narration of your own mental state. "I'm thinking, hmm, maybe, well…" is not the same as "here are the two shapes, here is what each costs, here is my pick". The first is noise; the second is a plan someone else can agree to.
- The interviewer answers your check-in with 'either is fine, you pick' — what do you do?Take the decision back immediately and commit out loud: "Then I'll take the direct scan, because I can get it correct and tested in the time we have, and I'll say where I'd upgrade it if queries get frequent." A neutral answer is not an invitation to keep deliberating; it usually means both branches are acceptable and the interviewer wants to see you own a choice and move.
- How do you check in without sounding like you are asking for the answer?Carry the decision yourself and ask for confirmation, not for instruction. "I'd go with the second because repeated checks are cheap there — does that fit the constraints you have in mind?" states a position and a reason, so the interviewer is validating your judgment. "Which one should I do?" hands the judgment over, and the thing being scored is exactly the judgment you just gave away.
- You are ten lines into the agreed approach and realise it will not work — what do you say?Say it as soon as you know, name what changed, and re-fork briefly: "I'm hitting a case my plan does not cover — a request that touches both ends of an existing entry. That pushes me toward the other approach; I'd rather switch now than patch this. Any objection?" Announcing the deviation is the signal; silently drifting away from a plan you just committed to is what reads badly.
It is a pilot reading back a clearance before turning: cheap to correct in words, expensive to correct once the aircraft is committed.
saying these in an interview costs you the question
- Starts typing immediately and explains only at the end
- Presents one approach as if no alternative existed
- Describes both approaches but commits to neither
- Turns the check-in into 'which one do you want?'
- Asks permission every few lines instead of once at the fork
- Spends five minutes pricing branches and never starts coding