Whiteboard Interviews: Using The Right Tool For The Job

Whiteboard interviews have gotten a lot of flak recently: they’re broken, they’re awkward, there’s nothing more indicative of a bullshit job. To be completely fair, some of this flak is deserved. Interviewing is a high-stress situation, and the mechanics of a whiteboard interview (putting the candidate in the front of a room, effectively presenting to a panel) certainly don’t help. So why do we use them at all? How did they become such a de-facto standard in the first place? And why continue to use them if they’re so clearly broken?

Here’s why: whiteboard interviews aren’t about programming.

 

Oh. 

 

Wait. Why would you want an interview that’s not about programming?

Because when it comes down to it, a good engineer is more than just a good programmer. 

Think about the best people you’ve worked with. Who adds the most value to your company? Where does everybody in the company go when nobody else seems to know the answer? Who best embodies your culture? Who is advocating for the user when everyone else is worrying about database schemas? 

Are those people the best programmers?

It’s possible. But it’s just as likely that those people are so well regarded and respected for other reasons: because they have an uncanny ability to recognize where a design will fail, or because they can break things down into things anyone can understand, or because they can translate technical problems for non-technical audiences. Maybe they’re just super clever, and fine cute solutions to tricky problems, even though their code is nigh-illegible. Maybe they’re just really patient. 

The point is, there are lots of things that make an engineer great, and programming is just one of them. This is why a good interviewing process is multi-faceted: It should test programming, sure. But it should include background or behavior questions. And it should also include an architectural exam, with a focus on communication. That’s where whiteboarding comes in.

The key thing to remember about doing (or giving!) a whiteboard interview is that it is not just about the solution. Whiteboard questions are just as much about process. The questions themselves should be selected because they lend themselves well to interesting conversations about trade offs, edge cases, and design—if they don’t do this, they probably shouldn’t be whiteboard problems at all. Moreover, the rubric (you should have a rubric) should adequately recognize candidates who are excellent communicators, effective problem solvers, and good thinkers.

So what makes a good whiteboard problem?

Here are a few examples:

  • Design a developer-friendly API for animating transitions between CSS states. How does it work?
  • How does a templating language work? How could you build one from scratch?
  • Sketch out a LESS or SASS compiler.
  • An elevator is essentially a state machine that responds to a couple external events (elevator request, floor request). Implement an elevator dispatcher.
  • How would you design a traffic-light controller for a four way intersection?

What all of these have in common is they require some bigger-picture thinking: they’re greenfield prompts that aren’t too hard to provide an answer to, but are tricky to get right. They have edge cases to be considered; they require the candidate to evaluation tradeoffs; they prompt meaningful discussion. Moreover, they’re answerable with pseudocode, or maybe even just a few diagrams describing a system. If a question really is about implementation, and you really do want to see code, perhaps the question isn’t well-suited for a whiteboard. Questions that really are about programming should betested during a different interview segment, and should certainly be tested on a real computer. 

While it sounds obvious, the point here is that interviews should accurately reflect the work that is done at your company. Your engineers do more than write code, so your engineering candidates should too. And as an interviewer, you should still be striving to create as realistic an environment as possible. When a candidate is whiteboarding, work with them. Offer feedback, or toss out alternative solutions. After all, your goal is to hire a colleague—and the whiteboard interview is the best test-drive you have for seeing how collaboration will work once they join the team.