What does done mean differently in a whiteboard round versus a shared-editor round?

## One problem, three finish lines Take a single small exercise and hold it fixed: a feed of restock records, each carrying a SKU key and a quantity, some quantities negative because they represent returns. Produce the net quantity per SKU and drop the SKUs that net out to zero or below. The algorithm never changes across formats — accumulate into a keyed total, then filter. What changes, and what candidates routinely misread, is **what the room will accept as a finished answer**. The governing idea is simple: *each format grades what its medium can verify.* A room that cannot execute anything grades your reasoning. A room that can execute grades execution. A format with hours and no interviewer grades scoping and communication. Bringing the wrong currency to the room is the single most common format mistake, and it is invisible to the candidate because the code itself may be perfectly good. ### Whiteboard and other no-execution rounds Here there is no compiler, no test runner, and often no scrolling. The interviewer knows this, which is why they will accept a compact sketch — `totals[sku] = totals[sku] + qty` with an elided guard for the first sighting of a key — as long as you say what the elided part does. What they will not accept is unexamined intent. Finished, at a board, looks like: - the approach named and justified against at least one alternative you rejected; - the loop invariant stated (after processing the first `i` records, `totals` holds the exact net quantity of every SKU seen so far); - the complexity given precisely, including the space term and what `k` is; - the boundary cases enumerated out loud — empty feed, one record, a SKU that appears only as a return, a SKU whose net is exactly zero — and each one walked through the sketch by hand; - a small trace on a three- or four-record example, because a hand trace is the only execution available. The trace is the whiteboard's substitute for running the program, and skipping it is the most expensive omission in the format. Two records and thirty seconds catch the off-by-one that no compiler is present to catch. ### Shared-editor and IDE rounds The same content is necessary but no longer sufficient. The room can now run things, so the bar moves to demonstrated behaviour. Finished means: it compiles or interprets cleanly; you ran it; you ran it on the boundary cases you yourself named; and when a case failed you diagnosed and fixed it in front of the interviewer. That last part is the signal these rounds exist to collect — how you behave when your own code disappoints you is far more informative than a clean first attempt. Two practical consequences. First, budget time for execution, not just for typing; a solution finished at the buzzer with nothing ever run is a weaker submission than a slightly simpler one that was exercised. Second, drive the cases from your own analysis rather than waiting to be handed inputs — announcing the nets-to-zero case and then running it is worth more than the interviewer discovering it for you. ### Take-homes With hours instead of minutes and no interviewer in the room, the medium can verify a great deal — but it verifies it *without you present to explain*. So the bar moves again, to scoping and to written communication: a working core path, a short honest note on what you cut and why, and a documented way to run it and its tests. A take-home is graded as a small delivery, and delivery includes the words around the code. ### The misconception this replaces *Good code is good code, the format does not matter.* It is half true — nothing here excuses wrong code — but it predicts the wrong behaviour every time. It leads candidates to write syntactically immaculate code from memory at a board while never tracing it, and to spend the last ten minutes of an editor round renaming variables instead of running the empty-input case. Both are effort spent in a currency the room does not accept. A quick self-check before you call anything finished: *what can this room verify that I have not yet shown it?* At a board the answer is your reasoning, so speak it. In an editor the answer is behaviour, so run it. In a take-home the answer is your judgment, so write it down.