You are stuck mid-round in a live-coding interview and no help has come — what do you do?

## Being stuck is expected; being silent is the failure Interviewers plan for candidates to get stuck. Many problems are chosen partly because a competent candidate will hit a wall somewhere in the middle, and how the candidate behaves at that wall is often the most informative part of the round — closer to real engineering than the parts where everything went smoothly. What is not planned for, and what damages a round, is the candidate who stops speaking. From the interviewer's side, a thinking candidate and a lost one are indistinguishable once narration stops, and they are obliged to grade what they can observe. ## Step one: locate the block precisely *I am stuck* transfers the whole problem to the interviewer and tells them nothing. A located block does the opposite: *I have the counting part; what I cannot see is how to keep the original ordering without a second pass over the data.* That sentence identifies which piece works, which piece does not, and what the constraint is that makes it hard. It is also the sentence that makes any assistance efficient, because a specific block can be answered with a specific nudge instead of a lecture. Writing the block on the artifact helps here too. On a blank whiteboard, drawing the small case that breaks — two records that must stay ordered while the lookup destroys the order — externalises the difficulty and frequently solves it outright. ## Step two: say what you have ruled out Name the approach you already considered and why you dropped it. *I thought about sorting first, but that costs more than the single pass we agreed we wanted.* This is worth real points: it shows the silence had content, and it keeps the round from circling back through a path you have already walked. It also converts a stall into visible reasoning, which is the currency of the round. ## Step three: propose a move, do not just report the state Four moves are almost always available, and choosing one yourself scores far better than waiting: **Fall back.** If you named a slower baseline earlier, take it — *I am going to write the straightforward version so we have something correct, then look at improving it if time allows.* This is exactly what banking a baseline was for. **Shrink the problem.** Solve a restricted version first: the two-element case, or the version where the awkward constraint is dropped. Say that is what you are doing and why. Generalising from a solved small case is a legitimate method, not a retreat. **Work a concrete example by hand.** Take three or four records and do the task manually on the board, noticing what you actually do. Candidates find the missing insight this way remarkably often, because the mechanical version of the task exposes the invariant the code needs. **Ask one narrow question.** *Am I right that we care about preserving the original order here, or is any stable ordering acceptable?* A narrow question is a legitimate collaboration move and reads completely differently from *can you give me a hint?*, which asks the interviewer to do the locating for you. ## Manage the clock inside the stall Give yourself an explicit bound and say it: *let me try the small case for two minutes; if it does not fall out I will write the simpler version.* This prevents the ten-minute silent stall that ends the round, and it demonstrates the same time judgment the rest of the round is testing. If the interviewer offers direction while you are working the block, take it and integrate it visibly — arguing with offered help while stuck is a costly way to defend a position that is not working. ## Worked example The mid-level mobile candidate at the Series C scale-up is merging two activity feeds on a whiteboard with no runner, and hits a wall on the deduplication: they can detect a repeated record, but not remove it without disturbing the ordering they promised earlier. Rather than going quiet, they say: *Here is where I am. Detection is fine — this comparison catches the repeat. What I cannot see is how to drop the duplicate without shifting everything after it. I already ruled out collecting into a set first, because that loses the ordering we agreed matters.* Then: *Let me draw three records and do it by hand for a minute.* They sketch the case, notice they are naturally keeping a marker for the last kept record, and realise that is the missing piece. Total elapsed: under two minutes, entirely narrated, and the recovery itself becomes the strongest evidence in the round. ## The failure mode in full The damaging version runs the other way. The candidate stops talking at minute twenty-six, stares at the board, writes and erases the same line twice, and answers a check-in with *sorry, just thinking.* The interviewer now has no view of the reasoning, cannot help without effectively solving the problem, and records a round in which the candidate wrote in silence and then went quiet under pressure. The recovery does not require solving the problem — a located block, a discarded approach and a proposed next move already turn that record around. ## Ending honestly if it does not come If the round ends unsolved, close it deliberately rather than trailing off: state where you got to, what remains, and how you would attack it with more time. Candidates are hired out of rounds they did not finish. Very few are hired out of rounds that ended in silence.