When interviewing for a software engineering job, it's common to be handed a dry erase marker and told to solve some arbitrary problem:

"Write a function that determines if the letters in a given string can be rearranged to form a palindrome."

"Implement a memoization function."

"How would you sort an array containing up to 100,000 randomly generated integers?"

As an interviewee, I used to hate whiteboard problems. The pressure of having to understand and solve a seemingly pointless or obscure problem in front of a stranger is enough to give anyone anxiety. I'll never actually write a merge sort during my day-to-day responsibilities as a software engineer anyway, so what's the point?

Now, as I sit on the other end of the conversation conducting the interviews, I'm beginning to see the merit of this format. The truth is, watching someone code for 30 minutes can tell you more about them than you would ever learn by asking them a hundred theoretical questions.

In practice, a mix of theoretical questions and coding exercises is important to include in the interview. For now though, let's examine why the whiteboard questions are so crucial.

The Merits of Whiteboard Interviews

As you watch a candidate code, there are many skills and attributes you can observe:

1. Does the candidate ask clarifying questions up front in order to better understand the problem? Or do they immediately start writing code?

2. Does the candidate begin with thinking through some test cases to solve for? Do they only consider the happy path? Or do they also think about where things could go wrong?

3. How does the candidate organize their code? Are their variables and functions clearly named?

4. What sort of syntax do they use? For example, in JavaScript, are they using ES6+, or are they sticking with ES5? Do they reach for the for loop, or do they use one of the array helper methods like map, forEach, or reduce?

5. If the candidate gets stuck, how do they react? Do they get frustrated? Do they freeze? Do they ask for help? Can they explain their reasoning to you?

6. How does the candidate respond to gentle pushes and other feedback from you? Are they annoyed, or do they welcome the help?

7. Can the candidate optimize their solution? If they started with a brute force approach, can they think of ways they could be more efficient?

8. Can the candidate poke holes in their own approach? Are they willing to admit to things they don't know?

The Shortcomings of Whiteboard Interviews

Even with all the benefits of whiteboard interviews, there are still some drawbacks.

There are two prevailing arguments against using whiteboard questions in interviews:

1. Whiteboard interviews don't actually test for coding ability - they test for anxiety.

2. Whiteboard interviews favor computer science students who are recent graduates and have all the algorithms they learned fresh in their minds.

To some extent, I agree with both points. However, I think both of these shortcomings can be mitigated.

Anxiety

Regarding anxiety, the interviewer should do everything they can to help the interviewee feel comfortable. If they look flustered, encourage them. Assure them that they're doing great. Have them take a couple deep breaths.

You could also assess coding ability in the form of take-home assignments or online assessments. When using these formats, you do miss out on being able to be there when they code and to help coach them, but you do still get to see their coding style. The other drawback is that these two approaches make it fairly easy to cheat. There are always pros and cons to every decision.

Favoring Recent Grads

To ensure your interview process isn't biased against those with non-traditional computer science backgrounds or against those who graduated from college a long time ago, it's important to choose whiteboard questions that don't require specialized knowledge of a certain algorithm or formula.

Instead, choose a question that focuses more on general problem-solving and less on regurgitating information from a Data Structures and Algorithms class.

Theoretical Questions

In addition to whiteboard questions, it's still important to ask some theoretical questions too. For a frontend software engineer, you might ask them about event delegation, closures, variable hoisting, the this keyword, or how the call stack works.

The thing is, though, all of those questions are easy to search for online. Anyone can memorize this information. As an interviewer, you may be able to discern when someone knows their stuff and when they're just reciting something they crammed for last night, but not always.

It's not until you see someone code that you can actually get a good sense for whether or not they have the right skillset for the job.

Conclusion

Love them or hate them, whiteboard interview questions are an essential part of the interview process.