In a live-coding interview, how do you test code in an editor with no run button?

## Nothing runs, so verification is something you perform The artifact in most live coding rounds — a whiteboard, or a plain shared editor — has no run button, no test harness, no autocomplete and no compiler. Code in that environment is never *known* to work; it is only argued to work. That changes what verification means. You cannot press a button and read a result, so you have to perform the execution yourself, out loud, in a way the interviewer can follow and check. Candidates who treat *I have finished typing* as *I am done* systematically lose the verification rubric line, and they lose it while sitting on a solution that was often correct. ## The hand trace Pick one input and commit to it. The right input is small — five or six elements is plenty — and chosen to exercise the branch you are least sure about, not the easy path. An input that only walks the happy path proves the least interesting thing about your code. Then walk the code line by line and speak the state as it changes: *index is at the second element, the accumulator holds two entries, the condition is false so we skip the append.* Write the changing values beside the code — a short column of variable states down the margin of the board, or a comment block under the function. This is the part candidates skip, and it is the part that finds bugs, because saying a value aloud forces you to actually compute it rather than assume the line does what you meant. A loop with many iterations does not need all of them. Trace the first iteration fully, the iteration where the interesting branch fires, and the last one. Say that is what you are doing: *I will do the first pass in full, then jump to where the duplicate appears, then the exit condition.* Skipping silently looks like hand-waving; skipping with an announced reason looks like time management. ## The boundaries, and why the earlier scoping pays off here After the main trace, walk the boundary cases quickly: empty input, exactly one element, everything identical, and whatever the problem's awkward case turned out to be. This is where the assumptions you wrote down at the start of the round earn their keep — you can point at them and say which cases you agreed to handle and which you agreed to skip, instead of improvising a scope on the spot. Do not trace every boundary in full. Name each one, say in a sentence what the code does with it, and only expand a full trace where the answer is not obvious. ## When the trace finds a bug It often will, and finding your own bug is a positive signal — it is roughly the strongest evidence available in the round that you verify your own work. The move is to say it plainly and immediately: *my index is off by one here; on the last element this reads past the end. I am going to change the bound.* Then fix it in place and re-trace only the affected part. The anti-pattern is the quiet edit — noticing something wrong and silently altering a character while continuing to narrate as if nothing happened. The interviewer usually sees the edit, and now they cannot tell whether you understood the bug or were poking at it. A named bug is a point scored; a hidden one is a point lost twice. ## Budget the time before you need it In a 45-minute round, reserve the final nine minutes or so for verification and hold that boundary. The temptation is always to keep coding, because coding feels productive and tracing feels like admitting you might be wrong. The exchange rate runs the other way: a traced solution with one small gap beats an untested solution that is probably complete, because only one of the two has been shown to work. ## Worked example The mid-level mobile candidate at the Series C scale-up has just finished a single-pass merge of two activity feeds on a blank whiteboard. Instead of putting the marker down they say: *Let me run this on a small case.* They write two short feeds — three records each, with one timestamp deliberately shared and one record present in both. Then they walk the loop, writing the pointer positions and the output list in the margin after each step. At the shared timestamp they notice the code advances only one pointer, which would drop a record. They say so, name the line, change the comparison, and re-trace only those two iterations. Then, in under a minute, they narrate the boundaries: both feeds empty returns empty; one feed empty returns the other unchanged; a record present twice appears once, matching the assumption written at the top of the board. Roughly four minutes total, one real bug caught by the candidate rather than the interviewer. ## The contrast The failing pattern is a candidate who codes in silence, stops typing at minute thirty-eight, and says *I think that is it.* Nothing was verified, nothing was narrated, and the interviewer's notes for the whole coding phase read as a blank. If a bug is then found by the interviewer, the candidate has lost both the correctness point and the verification point on a solution that a four-minute trace would have saved.