Whiteboard Interview Guide: The Good, The Bad, and The Ugly

Hiring is a risky, expensive process. How can you know if the candidates you’re considering are competent and will be a good fit for your team? The kinds of problems developers solve are long and complex. How can you get a glimpse into their thought process in less than an hour? You need to evaluate their problem-solving ability and communication skills as well as their coding prowess.

Whiteboard interviews are a long-used tactic to measure developers. But are they still effective?

In this blog, we’ll explore the history of the whiteboard interview. We’ll discuss how to run one effectively, and we’ll look at other alternatives worth considering.

What Is a Whiteboard Interview?

Whiteboard interviews are a style of interview question that assesses both the technical and non-technical skills of a potential hire. They can either be a specific algorithm and data structure problem, or they can be a more abstract systems design and architecture-based question.

An algorithm-based question would be something like:

“Given a string, identify the longest sequence of identical characters.”

A systems-based question is something broader:

“You’re building a real-time chat app for a mobile phone application. Sketch out the structure of the system.”

History of the Whiteboard Interview: How Did We Get Here?

Back in the 1980s and earlier, portable computers were large and expensive. Bringing a computer along to a candidate interview wasn’t practical. Instead, testing software developers using pen and paper was the norm. After all, it wasn’t that far removed from the times when computer programming required punch cards. Interviewers would ask interviewees to implement a linked list on college-ruled paper.

Later, in the 1990s, whiteboards were all the rage—from the classroom to the boardroom. Engineers loved them too. They made collaboration easier because everyone could see what you were working on. They were a clear choice over paper.

It stands to reason that the popularity of whiteboards would carry over to the interview process. It was easier for both the interviewer and candidate to look at what was being worked on and discuss it in real time.

Using a whiteboard in in-person interviews still happens today. Now more than ever, people are interviewing remotely and using virtual alternatives to physical whiteboards.

Why Conduct Whiteboard Interviews?

Unfortunately, job openings for programming positions often attract people who can’t program at all! It may sound harsh, but some of the candidates that coding jobs attract simply aren’t qualified.

When you’re hiring for a developer position, you need a competency check to establish baseline confidence. No single interview technique can separate good candidates from truly great ones. But using the right interview techniques can certainly help you ensure minimum qualifications.

Whiteboard interviews force both the interviewer and interviewee to focus on problems at a higher level. There are no development environments, syntax highlighting, or syntax errors to get in the way.

A whiteboard interview shouldn’t be a test to see if a developer has memorized their particular language’s syntax. It should do the opposite – removing those factors so you can both focus on solving the problem.

That’s right—both of you.

Whiteboard Interview as Productive Conversation

A whiteboard interview should be a conversation. It shouldn’t be a scenario where a developer tries to solve a problem under the interviewer’s cold, Simon Cowell-esque gaze.

Instead, it would be best to use the whiteboard interview to learn a bit about how the candidate does these things:

• Handle gathering requirements
• Deal with feedback and criticism
• Explain complex concepts clearly
• Plan before they start writing code

People solve real software development problems iteratively over weeks and months. Of course, you can’t do that during an interview process. But you can use these questions as a small-scale proxy.

Some developers detest being asked questions based on data structure and algorithms. Still, it isn’t easy to find a better solution for judging so many qualities of a candidate in a fixed amount of time.

Let’s explore some of the criticisms leveled against whiteboard interviews.

Criticisms of Whiteboard Interviews

Some developers discourage others from participating in these interviews at all. For that reason, you may potentially miss out on talented developers who are unwilling to participate in these practices.

But why are these developers so reticent? There must be some reason so many developers have such hostility toward whiteboard interviews.

Some developers resent that whiteboard interviewing is a skill set entirely detached from the skills needed to perform the job they’re interviewing for. Interviewers may choose to spend time getting better at the interview instead of getting better at the job. They may practice the kinds of algorithms and data structures that come up frequently. And they may work on treating code as a performance, not as a craft.

This makes it more difficult for the interviewer to discern who’s a strong candidate for the job versus who’s less qualified but better at interviewing.

For those reasons, these kinds of questions can punish potential candidates who don’t have the time to work on these skills. Who are these candidates?

• Newer developers may be preoccupied with learning new, practical skills.
• More experienced developers may want to invest their time in other pursuits, such as side projects, writing, or open-source projects.
• Some developers have family or other personal time constraints, regardless of their skill level.

However, no interview practice is perfect. If you want to use whiteboard-style questions as a part of your interview process, here’s how you can make the most effective use of them.

Whiteboard Interview Tips

Let’s look at 4 ways you can make these questions work for you:

1. Ask questions that are the right level of difficulty.

You want to thread the needle between “so easy it doesn’t reveal anything” and “so difficult they would have had to study it in advance.” Aim for questions that would be a 3 to a 3.5 on a 5-point difficulty scale.

2. Test problem-solving skills, not memorization.

Once I interviewed for a job that required using a particular variation of the knapsack algorithm. Without knowing that, I had zero shot at the interview. You want to test that your candidate can solve problems, not just match algorithm X with whiteboard problem Y.

3. Ask multiple-part questions.

This gives you and the interviewer chances to give and receive feedback, and then iterate on the problem. Here’s one way this could work:

• Give the candidate a question.
• Tell them to solve for a single case.
• Follow up by asking them to refactor it for a more generic or complex case.

Advent of Code is a good example of this, as they give questions that are all two parts. In fact, Advent of Code could be an inspiration for several whiteboard questions.

Having said that, don’t ask questions that you pick up verbatim from popular sources. All that does is give candidates who have looked at the same resources a huge advantage. And that’s a disservice to your company and the other candidates.

4. Ask follow-up questions.

Allow the candidate to iterate on their work by asking open-ended questions. Here are some examples.

• How would you improve on that?
• Do you like that?
• Do you want to add anything else?

This also allows the candidate to show off what they could do with more resources. They can explain how “what I did on a whiteboard with a time constraint” differs from the “what I would do on a production system that I’m responsible for maintaining” version.

Whiteboard Interview Alternatives

Whiteboard interviews are just one example of tools you can use to evaluate candidates.

Take-Home Project

One popular alternative is the take-home project. This allows you to see how the candidate works in an environment that more closely resembles the work they’ll be doing at the job, but at the expense of removing real-time communication from the equation.

CoderPad and Other Online Tools

You can also use online tools, including CoderPad, to evaluate candidates. CoderPad provides an integrated experience that more closely resembles day-to-day development work. This allows the interviewer to not only see how the candidate does “real work” but also collaborate with them in that environment.

Which Options Are Best for You?

Whatever you decide, remember that you’re trying to find the right candidate for your team. Also, keep in mind the problems you’re trying to solve. It’s not about how the candidate tackles a particular problem. Instead, it’s about getting a sense of whether the person on the other side of the table will become a valuable addition to your team.

This post was written by Glenn Stovall. Glenn is a full-stack senior software engineer who works at the intersection of marketing and software engineering. He loves to teach others, whether it’s mentoring junior developers, or helping developers with writing and publishing. When he isn’t helping others, Glenn enjoys spending time with his wife and two dogs hiking the Great Smoky Mountains.