Why Whiteboard Interviews Suck (And What To Do Instead)
Posted on September 24, 2020 by P.K. Maric
Whiteboard interviews have long been a staple in tech hiring. And they’ve been a terrible mistake the entire time.
Programmers hate them. They want them to stop. Even some interviewers hate them, but not nearly enough because they’re still a widely used interview technique.
Why Are Whiteboard Interviews so Terrible?
A recent study by Microsoft and North Carolina State University has shown that whiteboard interviews primarily focus on performance anxiety, rather than actual technical skills required for the job.
Many hiring managers would argue that this is still okay, as it tests how well the candidate performs under pressure, which might be necessary for the job. They are wrong. This is not the same kind of pressure any candidate is going to feel on the job. Nobody is going to stand over their shoulder and watch them code for an extended time. It’s an entirely artificial situation that they’ll never encounter at work.
Pressure in a programming job may come in many different forms, but live coding on a whiteboard in front of an audience is not one of them. The pressure might be a deadline before the release of a product. Or an online service being down that needs to be fixed ASAP. These situations are nothing like whiteboard interviews.
In a whiteboard interview, candidates are often expected to explain their work out loud while they are doing it. This is something they’d never have to do on the job, so candidates that quietly think about the problem they need to solve may be mistakenly seen as less skilled. In contrast, talkative candidates can be perceived as more knowledgeable. This is very misleading, as explaining your thought process aloud has nothing to do with how well you can solve a problem.
The environment developers actually work in is completely different from a whiteboard interview. At work, developers will code using a computer, and have various tools at their disposal that enable them to do their job. The most obvious one is an IDE, but also Google, which is crucial for effective programming and should be accessible to developers in interviews. Asking developers to code on a whiteboard is like asking a professional cyclist to race using a stationary exercise bicycle.
Whiteboard interviews are not only bad for job candidates. They’re also bad for you because they prevent you from actually finding skilled candidates, which is the whole point of your hiring process.
The Better Alternative: Automated Testing
Testing a candidate’s programming skills on a computer is a much better way of evaluating their knowledge. The candidates can do the work in a familiar environment and have the tools they need to effectively use their skills. It’s also much easier and more effective for you to screen candidates this way.
For this to work properly, the interview tasks need to be relevant to the actual work they’re applying for.
While you can manually review each candidate’s code, a more effective approach is to use automated testing. This allows you to test dozens or even hundreds of candidates at once. Their answers will be automatically evaluated, so you can see their score as soon as they finish the test. You can still examine their solutions manually if needed and better understand how they approached the problem— something that’s often considered an advantage of whiteboard interviews.
You can also follow up with a candidate after the test if you want to know more details about their thought process during the problem. Candidates may find it easier to explain their thought process after they’ve already completed a task, rather than having to do it in the middle of solving the task on a whiteboard.
Another advantage of automated testing is that you can test candidates’ skills remotely before inviting them to an interview. You can save a lot of time this way by eliminating less-skilled candidates at the start of your hiring process. You don’t need to spend an hour interviewing each candidate to find out that they’re not what you were looking for.
If you are concerned that candidates may cheat if left unsupervised during a coding task for a job interview, you shouldn’t be. It’s fairly easy to prevent. For example, TestDome has multiple systems to prevent cheating, like copy/paste protection, email verification, and webcam proctoring. But the essential tool that prevents cheating is a unique coding task that’s not found anywhere else. All our questions are custom made, and you can even create your own custom questions if you’d like. If you’re creating your own test, don’t just copy common interview coding problems anyone can find online.
Conclusion
Programming job candidates shouldn’t be asked to code on a whiteboard in front of a live audience. It’s an unfamiliar environment that’s distracting and often makes them feel out of place, making it hard to focus on the actual problem. Developers are meant to code in a dark room illuminated only by the soft glow of the monitor, with their only companion being a rubber duck. The way nature intended. Coding interviews should be no different.
