Project Ariadne.

Field notes · was Appendix B

The whiteboard method

Most people fail the whiteboard not because they cannot solve the problem but because they have no method — so they panic, leap at the first idea, start coding before they understand the question, and run out of time with a mess on the board and no way back.

Last reviewed 2026-09-04

The method, in one breath

Read twice, so you solve the right problem. Solve by hand with three examples, because you cannot code an algorithm you have not found. Optimise the approach while it is still cheap to change. Write pseudo-code, separating logic from syntax. Convert to clean real code — the easy part now that the thinking is done. Optimise the implementation, reviewing your own work. Hunt the corner cases, because the edges are where it breaks.

Here is why a method matters more than raw cleverness. Under pressure your judgement degrades and your brain reaches for autopilot — the exact failure the book's chapter on the five percent describes, now happening to you, live, with someone watching. A method is the checklist that re-activates a panicking brain: it does not make you smarter, it makes you available to the intelligence you already have, by giving you somewhere to put your hands while the panic subsides.

The interviewer is watching the process far more than the answer. A candidate who methodically works toward a solution reads as a strong engineer even without finishing; one who blurts a clever answer with no visible reasoning reads as a gambler.

Seven steps, in order, every time — especially when the problem looks easy, because the easy-looking problem is where overconfidence skips a step and the corner case bites.

  1. Step 1#

    Read the problem twice

    So you solve the right problem.

    Once for the gist, again to actually understand it — and the second read is the one almost everyone skips in the hurry to look fast. It is where you catch the constraint you assumed away, the word “sorted” you did not register, “return all” versus “return the first”, the input range that changes everything. The first read pattern-matches the problem to something familiar, and the familiar match is often subtly wrong. Thirty seconds, and it saves you from solving the wrong problem beautifully.

    In the room Say your understanding back: “so, to confirm, I'm being asked to…”. If you have misunderstood you find out now, for free.

  2. Step 2#

    Solve it manually, with three sets of data

    Because you cannot code an algorithm you have not found.

    Before any code, solve it by hand, on the board, with real example inputs — and not one example, three. A typical case reveals the main logic. An edge case (empty, single element, the boundary) reveals what breaks, and the best time to discover that is now, by hand, not later in front of the interviewer. A third case tests whether the pattern generalises or just happened to fit the first two.

    In the room Three is the minimum that distinguishes a real pattern from a coincidence.

  3. Step 3#

    Optimise the approach — still by hand

    While changing your mind is still free.

    Look at the manual solution and ask whether it is the good approach or merely the first one. Is there a better algorithm than the obvious one? Am I doing redundant work I could avoid? Would a different structure make this fall out — a hash map turning a nested loop into a single pass? What is the complexity, and is there a known better bound? The cost of changing approach is lowest now, when it is a few notes on a board.

    In the room Talk through the approaches you reject and why. “I could do this with a nested loop — O(n²) — but a hash map gets it to O(n) at the cost of O(n) space, which is the right trade here” is worth more than the final code.

  4. Step 4#

    Write pseudo-code

    Separating logic from syntax.

    The bridge between the manual solution and real code. It keeps you from doing two kinds of thinking at once — what are the steps and how do I express them in this language — which is exactly how people tangle: wrestling a loop's syntax while trying to hold the algorithm in their head, dropping one to manage the other.

    In the room It is also your safety net. If you run out of time, correct pseudo-code plus some real code shows you solved the problem far better than half-finished real code that reveals nothing about where it was going.

  5. Step 5#

    Convert to real code

    The easy part, now that the thinking is done.

    Pure translation. Write it cleanly even here: real names, not x and temp; small clear steps. Partly because clarity is the habit and an interview is no place to abandon it, and partly for the cold tactical reason that the interviewer is forming a judgement about what your production code looks like.

    In the room Narrate as you translate — “now I'm implementing the main loop from the pseudo-code” — so a small slip gets caught in conversation rather than in silence.

  6. Step 6#

    Optimise the code

    Reviewing your own work, unprompted.

    Now look at the implementation rather than the approach: a redundant operation, an unnecessary pass, a clumsy condition, a clearer structure. Do not over-engineer — a working clear solution beats a clever fragile one — but show that “it works” is the beginning of your standard and not the end of it.

    In the room Most candidates skip this. Going back over your own solution with a critical eye is the senior habit the whole hour is trying to detect.

  7. Step 7#

    Hunt the corner cases

    Because the edges are where it breaks.

    Deliberately and out loud: empty input, a single element, the maximum, the minimum, duplicates, negatives, zero, null, already-sorted and reverse-sorted, an input larger than you assumed. Walk the finished code through each, on the board.

    In the room Saying “let me check the corner cases” tells the interviewer, more convincingly than any answer to “are you detail-oriented?”, that you think like someone whose code survives production. And if you find one and fix it calmly, that is one of the best signals you can send.

The card#

Print this page and only this list survives.

  1. Read it twice. Say your understanding back.
  2. Solve it by hand. Typical case, edge case, one more.
  3. Ask if this is the good approach or the first one. Say the rejected ones out loud.
  4. Pseudo-code. Logic now, syntax later.
  5. Real code, clean names, narrated.
  6. Review your own solution before they do.
  7. Empty, single, max, min, duplicates, negatives, zero, null, sorted, reversed.

The method will not make you a better engineer. It will let the engineer you already are show up to a room designed to make them disappear. That is the whole job of a method under pressure: not to supply the intelligence, but to keep the panic from hiding it.

← The interview, from both sides · All field notes