Whiteboard interviews have quite a reputation in the software development community. Dreaded by most, many companies use intense “LeetCode” style questions, designed to test for depth of algorithmic knowledge. Most of the time, this style of interview can result in those who have only spent time grinding practice questions passing with flying colors, while neglecting to test for the wide range of other important skills a good developer should possess. It’s still important to test for a candidate’s problem-solving ability in an interview, so how can whiteboard interviews be more effective and a better experience for every participant?
Give Easier Problems for Greater Insight
There are a few issues with the grueling questions typically asked in a whiteboard interview, namely:
- They test for a narrow skill set.
- They reward memorization of common problems.
Most whiteboard interviews test for a specific ability: can this person memorize lots of different solutions? It’s not totally pointless, you’re sure to find someone who really gets algorithms and data structures, but what about all of the other important skills in a developer? Communication and big-picture thinking don’t shine through when someone is tearing through a gnarly binary tree as fast as they can.
Counterintuitively, easier problems provide space for a more wide-ranging interview. You don’t need to do fizzbuzz, but give problems simple enough to allow candidates to fill in the gaps that are left. A book-smart interviewee might blast through the problems with time to spare, but someone more qualified can use that time to showcase broader experience.
Ask, and Receive, Lots of Questions
Most roles don’t involve writing out the most efficient possible algorithm while coworkers watch intensely. Most roles are collaborative, and involve solving real problems with others.
Take opportunities throughout an interview to ask questions. Questions about the solution are great: why did you solve it like this? What if we wanted a different kind of output? Ask, as well, broader questions: what’s a good testing strategy? How might this be organized in a large codebase?
The important piece is that questions with a right or wrong answer should not be asked. Questions should spark discussions and probe different aspects of someones skill set. They should also invite questions in return. Use these to further gauge how someone thinks and collaborates. What assumptions do they make? Do they ask good clarifying questions that demonstrate understanding? Are they curious, or are they overly focused on quick solutions and quick answers?
Focus on Practicality
A good whiteboard interview tests for something more relevant than memorization: do I want to work with this person? Consider the most important skills your ideal hire possesses, and lean into problems and questions that illuminate these.
If mentorship is important, have the interviewee talk through the problem and their solution as if they were a tutor explaining it to a student. If frequent cross-team collaboration is a must, ask how they would ensure their solution is easily reusable and well-documented.
At the end of a whiteboard interview, all participants should walk away feeling like they already work together and just wrapped up a productive meeting. You want to have a good sense of what it’d be like to work alongside the person you’re interviewing. This requires that the interview allow a candidate to be themselves, and nobody can be themselves during a brutal gauntlet of optimizing algorithms.