A whiteboard interview is a technical interview where you solve a problem by writing code or drawing a system design on a whiteboard, or on a virtual whiteboard during a video call, while explaining your thinking to the interviewer. There is usually no compiler, no autocomplete and no way to run the code, so the interviewer is judging your reasoning, structure and communication rather than whether a program executes.
Whiteboard rounds are most common in software engineering interviews, both for algorithm problems and for system design. On a video call, the "whiteboard" may be an online drawing tool or a plain shared document with no code execution. The skills are the same: plan the space, think out loud, write clearly and check your own work by hand.
What happens in a whiteboard interview?
A typical whiteboard round runs 45 to 60 minutes and follows this shape:
- The prompt. The interviewer states a problem out loud or writes it on the board.
- Clarification. You ask about inputs, outputs, constraints and edge cases, and write the answers on the board.
- Approach. You describe one or two approaches, compare them and agree on one with the interviewer.
- Writing. You write the code or draw the design, explaining as you go.
- Verification. You trace an example through your code or walk a request through your design.
- Discussion. Complexity, trade-offs, failure cases and how you would extend it.
The whiteboard is one of several technical formats; see our hub on types of job interviews and the comparison of live coding vs take-home interviews for the others.
Coding vs system design on a whiteboard
The same board serves two quite different rounds. Knowing which one you are in changes how you use the space.
| Aspect | Coding whiteboard | System design whiteboard |
|---|---|---|
| What you produce | A function or small program written by hand | A diagram of services, data stores and data flows |
| Typical problem | Arrays, strings, trees, graphs, dynamic programming | Design a URL shortener, a chat app, a news feed or a rate limiter |
| Main signals | Correctness, complexity analysis, clean logic, testing by hand | Requirements gathering, trade-offs, scaling, data modeling |
| Who drives | You, with occasional hints | You, with frequent probing questions |
| Common mistake | Starting to write code before agreeing on the approach | Drawing boxes before agreeing on requirements and scale |
| Where to prep | Coding interview cheat sheet | System design cheat sheet |
For the design side, our guide to what a system design interview is covers the full structure.
How should you lay out the whiteboard?
Running out of space halfway through, or writing code that snakes around the board, makes your work hard to follow and hard to fix. Decide the layout before you write anything. Here is a layout that works for most coding problems:
| Board zone | What goes there | Why it helps |
|---|---|---|
| Top left (small) | Problem summary, constraints, the agreed input and output | You and the interviewer can point to the agreement at any time |
| Below it (small) | One or two examples, including an edge case | Used later to trace and test your code |
| Top right (small) | Approach in 3–5 bullets and the target time and space complexity | Keeps you on plan when nerves hit |
| Center and right (large) | The code, written top to bottom with space between lines | Leaves room to insert a missed line without rewriting |
| Bottom (small) | Trace table of variables for your example | Shows you verify your own work |
For system design, a similar idea applies: requirements and scale estimates in one corner, the API and data model in another, and the diagram in the center, drawn left to right in the order a request travels. Leave space for the second version of the diagram, because the interviewer will usually push you to scale it.
How to narrate while you write
Silence is the most common reason good engineers underperform on a whiteboard. The interviewer cannot see inside your head, and long quiet stretches leave them guessing. A simple narration pattern:
- Before writing a block: say what it will do. "Next I'll loop through the array once and store each value's index in a map."
- While writing: name decisions as you make them. "I'm using a map instead of a list so the lookup is constant time."
- After writing a block: summarize in one sentence and check in. "So at this point the map holds every value we've seen. Does that make sense so far?"
- When stuck: say what you are considering instead of going quiet. "I'm deciding whether to sort first. That costs n log n, so let me see if a single pass works."
Face the interviewer when you talk and the board when you write; trying to do both at once usually means mumbling into the board. Our guide on practicing thinking out loud in coding interviews has drills that build this habit, and the coding interview mistakes list shows what silence costs.
What about virtual whiteboard interviews?
Remote whiteboard rounds use an online drawing tool or a shared document. They test the same skills, but the mechanics are different:
- Drawing with a mouse is slow. Practice with the tool beforehand. Learn the shortcuts for boxes, arrows and text so you are not hunting for them mid-design.
- Typing replaces handwriting for code. In a plain document, keep consistent indentation by hand and write short comments marking each section.
- Zoom and scrolling hide work. Keep the important parts in one visible area and tell the interviewer when you scroll ("I'm moving down to the code section now").
- Test the setup. Join the link early if possible and confirm you can draw and type. A drawing tablet is optional; a reliable mouse is enough.
How do you practice for a whiteboard interview?
Most people practice coding problems in an editor, which hides exactly the skills a whiteboard tests. Use drills that recreate the conditions:
- Paper or board, no editor. Solve two problems a week by hand on paper or a cheap whiteboard, with a 30-minute timer.
- Hand-trace every solution. After writing, trace a small example line by line in a variable table. You will find bugs you would have relied on a compiler to catch.
- Record yourself. Prop up your phone and record a full problem. Watching it back shows silent stretches and messy layout immediately. Our guide to recording yourself for interview practice explains how.
- Do one system design drawing per week. Pick a classic design prompt and draw it in 35 minutes, starting with requirements and ending with bottlenecks.
- Practice with a person. Ask a friend to play interviewer and interrupt you with questions, because real interviewers will.
- Do one virtual run. If your round is remote, practice at least once in the drawing tool the company uses, or one like it.
Pair these drills with a Big-O cheat sheet so you can state complexity confidently at the end of every problem.
Practice it
The talking part of a whiteboard round is the easiest to practice and the most often skipped. You can use an AI interview assistant like CoPilot Interview to rehearse technical explanations: a mock interview built from your résumé and the job description asks questions aloud, you answer out loud, and each answer gets a score out of 10 with what to fix. It is free for 15 minutes a day with no account. Combine it with the paper and recording drills above for the writing side. Follow each employer's rules on AI tools, and use AI to prepare beforehand.
Practice explaining your solutions out loud
Answer coding, system design and behavioral questions by voice, get a score out of 10 for each answer and a model answer to compare with.
Try a free AI mock interviewFAQ
Do companies still do whiteboard interviews?
Yes, though the format has shifted. Many remote interviews use a virtual whiteboard or a shared document instead of a physical board, and system design rounds still commonly rely on drawing. Some companies have moved to practical or pair programming rounds instead.
Does my code have to be perfect on a whiteboard?
No. Interviewers commonly accept minor syntax slips when the logic is correct and clearly explained. What matters more is a sound approach, correct handling of edge cases, stated complexity and evidence that you checked your own work.
What language should I use in a whiteboard interview?
Use the language you know best unless the role requires another. Languages with compact syntax, such as Python, save board space, but fluency matters more than brevity.
How do I handle running out of space on the whiteboard?
Plan the layout before you start, write smaller than feels natural and leave blank lines between sections. If you still run out, ask if you can erase the examples you no longer need and say what you are removing.
How is a virtual whiteboard interview different?
You draw with a mouse or type in a shared document, which is slower and harder to read. Practice with the tool beforehand, keep key content in one visible area and tell the interviewer when you scroll or move between sections.
How long is a whiteboard interview?
Commonly 45 to 60 minutes, including a few minutes of introductions and time for your questions at the end. Ask your recruiter for the exact length and whether the round is coding, system design or both.