Whiteboard Interview Tips & Techniques

The whiteboard interview — physical or virtual — adds a cruel twist to problem-solving: you must think, code, and perform simultaneously, in a medium with no autocomplete and no undo that anyone can see. The good news is that whiteboarding is a learnable performance skill, almost independent of how strong an engineer you are at your desk.

The reframe: the whiteboard is not where you solve the problem — it's where you show the solving. Your narration, layout, and error recovery are being scored alongside the code itself.

Own the first five minutes

Resist the marker. Clarify the problem verbally, agree on the input and output shape, and state your plan before a single line goes up. Then stake out territory: divide the board mentally — problem restatement and examples on the left, main solution in the centre, scratch space on the right. Candidates who skip this end up squeezing code into corners, and cramped code reads as cramped thinking.

One more first-five-minutes habit: agree on a tiny example together and write it in the corner immediately. That example becomes your test harness at the end — when the code is done, you trace it line by line and catch your own bugs before the interviewer does. Candidates who skip the example end up "testing" by vibes, and it shows every time.

Write for the reader

• Bigger than feels natural. The interviewer reads from a distance; if they can't read it, it doesn't exist.
• Say everything you write. "Now I'm initialising the window boundaries" — silence at a whiteboard feels ten times longer than it is.
• Sketch before syntax. Draw the tree, the array indices, the window boundaries. A picture unlocks the code and proves your mental model.
• Leave whitespace between logical blocks. You'll insert the forgotten base case into that gap later, guaranteed.

The mistake-recovery playbook

You will write something wrong. Everyone does. The scored behaviour is what happens next: don't panic-erase in silence. Say "wait — that index should start at one, here's why," fix it, and move on. Calm self-correction is a senior signal; interviewers have watched a thousand candidates and remember the composed ones. And when you're stuck, verbalise the stuckness with structure: "I'm choosing between a heap and a sorted scan — the heap wins on inserts" — that invites the hint that unblocks you.

Virtual whiteboards: same rules, new friction

For remote rounds, rehearse in the actual tool beforehand — drawing with a trackpad is its own skill, so prefer typing text boxes over freehand where possible. Keep the example trace visible on screen the whole time; on a virtual board it's tempting to scroll it away. And test your setup in advance: camera angle, screen-sharing flow, and a backup plan for the day the tool itself decides to misbehave mid-interview.

Common mistakes

• Writing code before agreeing on the approach. You optimise the wrong thing in front of an audience.
• Micro-handwriting and corner-cramming. Layout is communication.
• Going silent for three minutes while drawing. Narrate or lose the room.
• Not leaving space, then overwriting your own example trace — the very thing you needed for testing.

FAQ

Should I practise on an actual whiteboard? Yes — at least a few sessions. The physical difference (no undo, arm fatigue, distance legibility) changes how you plan, and you don't want the real interview to be your first encounter.

What if I blank completely? Fall back to process: restate the problem, write a brute-force approach, and narrate its weakness. A structured recovery impresses more than frozen brilliance.

Rehearse the performance side with Aissence mock interviews, and keep your fundamentals sharp via the design spine for architecture rounds.