Whiteboard and Live-Coding Etiquette

## The phase exists because the problem is deliberately underspecified Problems given in live technical rounds are almost always stated loosely on purpose. The prompt names a goal and leaves the input shape, the scale, the tie-breaking rule and the failure behaviour undefined. That vagueness is part of the exercise: an interviewer wants to see whether you close those gaps by asking, or by guessing silently and hoping. Guessing silently is the single most common way a candidate loses points in the first five minutes of a round, because everything built on the guess is now unverifiable — the interviewer cannot tell a deliberate assumption from a misunderstanding once code is on the board. ## What is actually being graded Most rubrics for this stage carry a line about problem comprehension or scoping that is separate from correctness. It rewards three observable things: that you restated the problem accurately, that your questions changed what you were going to build, and that you made your assumptions inspectable. Notice that none of those require you to be right. A candidate who says *I am going to assume the identifiers are unique; tell me if that is wrong* has scored the point even if the assumption is wrong, because the interviewer can now correct it in one sentence. ## Four families of question worth asking **Input shape.** What am I actually handed, and in what form? A list, a stream, a nested structure, something already sorted? Is it handed to me whole, or do I have to request it in pieces? **Scale.** How large can it realistically be — hundreds of entries, or millions? This is the question that decides whether an approach that re-scans the input is acceptable or disqualifying, and it is the question candidates most often skip. **Boundaries and malformed input.** What happens on empty input, on a single element, on duplicates, on entries that are missing a field? Ask which of these the interviewer wants handled in code versus merely acknowledged; that answer alone can save you ten minutes of defensive branches nobody wanted. **The contract.** What exactly comes back — the value, the index, a count, a new structure, or a mutation of the one I was given? Confirming the return shape is cheap and it is where silent mismatches hide. A question fails to earn its place when the answer cannot change what you write. *Should I use good variable names?* and *Do you want this to be efficient?* are filler; they cost time and read as nerves. ## The budget, and where it sits in the round In a 45-minute round, this phase should take roughly four minutes — long enough for a restatement and three or four questions, short enough that the interviewer never has to steer you into starting. If clarification is still running at minute eight you have overspent, and the recovery is to state your remaining open items as assumptions and move on rather than keep asking. ## Record the assumptions on the artifact in front of you Whiteboards and interview editors have no runner, no test harness and no autocomplete: the artifact remembers nothing you did not write on it. Use that. Put the confirmed assumptions in a corner of the board, or as three short comment lines at the top of the empty file, before the first line of real code. They serve as a contract you can point back to when the interviewer probes an edge case later — *I flagged malformed rows as out of scope here; want me to fold them in now?* — and they let a second interviewer reading the notes afterwards see that the scoping happened. ## Worked example A mid-level mobile candidate interviewing at a scale-up that recently raised a Series C is asked to merge two lists of activity records into a single feed for a profile screen. The blank editor has no run button. Instead of typing, the candidate says: *So I am combining two record lists into one ordered feed and returning the merged list — is that right?* Then: are both lists already ordered by timestamp; can the same record appear in both; roughly how many records does a heavy account accumulate; and what should happen when two records share a timestamp? The interviewer answers that both are ordered, that overlaps happen, that a heavy account holds a few thousand records, and that ties can break either way. Four questions, well under two minutes, and the shape of the solution is now decided. The candidate writes *sorted inputs / duplicates possible / ties arbitrary* on the board and starts planning. ## The failure it prevents The alternative is the pattern interviewers see constantly: silence, then typing within seconds of hearing the prompt. It looks decisive for about three minutes, and then the candidate hits an ambiguity, resolves it in their head without saying anything, and builds twenty lines on top of it. When the mismatch surfaces at minute thirty there is no time to rebuild, and the round ends with an interviewer who never saw how the candidate thinks — only that they were wrong.