7.6.3. White Board Interviews
A whiteboard interview is called this because it typically involves solving problems on a whiteboard (or similar medium) in front of an interviewer. This format is common in technical interviews.
These interviews are meant to simulate how you think and problem-solve in real time. Interviewers aren’t just interested in whether you get the right answer—they want to see how you approach problems, communicate your thought process, and respond to feedback.
What to Expect​
Typically whiteboard interviews are used for one of two purposes:
- Algorithmic Problems: You’ll be asked to solve a coding problem, often involving data structures and algorithms.
- System Design Problems: You’ll be asked to design a system or architecture, which tests your understanding of software design principles and scalability.
This is how you should approach a whiteboard interview:
- Clarify the problem — Ask questions, define constraints, and state assumptions.
- Plan your approach — Talk through your initial ideas before jumping into code.
- Whiteboard your solution — Write code or diagrams on the whiteboard, explaining your thought process.
- Analyze time and space complexity — Big-O notation is expected.
Algorithmic Problems​
Algorithmic questions are designed to evaluate an engineer’s understanding of core computer science concepts, such as data structures and algorithms, by asking the participant to complete a code problem with the best possible time and space complexity.
Examples of algorithmic prompts include:
- Write a function to reverse a linked list.
- Find the longest substring without repeating characters.
- Implement a binary search algorithm.
- Given a sorted array, find the first and last position of a target value.
- Merge two sorted linked lists.
- Given a binary tree, find its maximum depth.
The best way to prepare for whiteboard algorithmic interviews is through a combination of practicing algorithmic problems on sites like LeetCode or HackerRank while also practicing coding by hand on a whiteboard or paper.
System Design Problems​
System design questions are not a common type of interview for students and early-career candidates but are occasionally included. These questions ask candidates to describe, at a high level, how they would hypothetically design a system to solve a given problem.
Examples of system design prompts include:
- How would you design a ride-sharing app like Uber?
- How would you architect a video streaming platform like YouTube?
- How would you design a search engine like Google?
- How would you design a file sharing platform like Google Drive?
These interviews focus on assessing a candidate’s understanding of system components, their ability to identify key requirements and constraints, and their capacity to account for edge cases that could impact the system’s design.
Although rare for students, I have definitely seen these questions once or twice. I was once asked to explain how I’d design an app for managing parking spaces as a 2nd year student and was caught off guard because I didn’t know how to properly approach the question.
The best way I've found to prepare for these questions is to follow system design walk through videos on YouTube.
How to Do Well​
Communicate Constantly​
One of the biggest mistakes candidates make is silently working through the problem. Remember, the interviewer can’t read your mind.
Narrate your thinking:
- “I’m thinking of using a hash map to track counts…”
- “One edge case could be when the list is empty…”
The interviewer is evaluating whether they'd actually want to work with you, so showing your thought process is crucial.
Don’t Be Afraid to Start Over​
It’s okay to take a wrong approach—as long as you recognize it and explain why you’re changing course.
Interviewers know that real development involves iteration. What they care about is whether you’re able to adapt and keep your cool when things go sideways.
Practice Without an IDE​
One of the best ways to prep for whiteboard interviews is to simulate them.
Practice solving problems:
- On paper or a whiteboard
- In a shared Google Doc
- With a timer and no syntax highlighting
This helps build confidence coding by hand and forces you to focus on logic instead of relying on autocomplete.
Common Mistakes to Avoid​
- Jumping straight into code without discussing the approach
- Making too many assumptions without clarifying constraints
- Not mentioning edge cases