In Defense of Whiteboard Interviews

There's the cliche tech interview: you get a HR screen, you do a phone screen through a tool like coderpad, and then you move onto an onsite, where you'll presumably be subjected to whiteboarding, forced to come up with awful algorithms that you'll never have to use in real life in a dog and pony show to impress your future employer.

Whiteboarding is some common, that it's even being outsourced to other companies. Companies like Triplebyte and Karat promise to outsource your technical screen, Stackoverflow jobs encourages you to use Pluralsight to take a "free coding exam to show off your skills", AngelList has AList that screens candidates beforehand. The "outsource your interview" market is alive and well in the traditional sense too, with HackerRank promising "leading end-to-end technical recruiting platform" and LeetCode drilling algorithms into candidates. There's even a book, titled Cracking the Coding Interview, that enumerates most of the potential problems a candidate might face. Yet, in light of abundance of resources, programmers still whine about whiteboarding.

The most common criticism of whiteboarding is that it's not relevant to the job. You're never forced to come up with algorithms on the spot, and the requirement to draw on memorized knowledge is asinine since working programmers will be referring to documentation constantly. While these criticisms are certainly valid, they miss the point of whiteboarding. Whiteboarding is not to force you to cram the C stdlib into your head, it's to test your knowledge of basic problem solving. The problems you face during a whiteboard interview are usually not of the quality "derive the four color theorem from first principles", they're at best DFS, and more commonly some usage of hash-maps. These algorithms can be grasped by any decent programmer, and complaints that they are "too complex" means that whiteboard filtered correctly.

The follow up comment to this is that whiteboarding can be brute-forced, by simply memorizing various problem sets you can "cheat" your way through the interview. While this is correct, it ignores the fact that people who do put in the effort of memorizing the entire gamut of topics for a specific goal often accomplish said goal. Memorizing problems is not "cheating" the interview, it'd be more impressive if someone memorizes 50 problems involving DFS and doesn't learn how DFS works.

Yet, whiteboarding isn't a panacea for a bad interviewing process. A good interviewing process must be holistic, with well trained interviews. Far too many engineers are shoved into an interview the week or the day of, without proper training in empathy and how to interview. Many engineers will sit there and allow a candidate to struggle, which is terrible on the interviewer's part.

There's a specific point that I want to address here: Joel Spolsky's "lemons" point. For those who haven't read Joel's article, it describes that "good" developers will often have a job, and "lemon" aka bad developers will be left on the market and interviewing at many places. Dan Luu has a good post refuting this, but I wanted to specifically address that the tech industry treats "good" as synonymous with "public" far too often. We treat github stars as some form of meritocracy, and the it couldn't be further from the truth. Hiring processes are incredibly dysfunctional, and the "good developers are nowhere" meme allows bad companies to pawn off responsibility by saying "oh the market is just not good". The tech industry is incredibly bad at hiring, and more often than not companies need a firm introspective on their hiring process.

So how do we make things better?

1. We (collectively as developers and interviewers) need to make whiteboarding less stressful with clearer expectations. Algorithm questions with some form of depth are good, brain teasers that require knowledge beyond second year CS is not. Unless you are hiring for a specific role, you should not be asking about the URG flag in TCP, but web developers should be expected to know how SYN/ACK and flow control works.
2. Better interviewer training. I currently work as an interviewer for Karat, and I could not be happier with the in depth training they put me through. Scripts are required for interviewers, with specific targets on when and how to help candidates through the interview process. Programmers should not be shoved into interviews without proper training, and companies need to be more aware of biases. I don't mean unconscious bias training, which has no scientific proof, but rather understanding that shoving a programmer into an interview a day of will give far different results than planning and training the programmer as an interviewer.
3. More acceptance that failing during the whiteboard is okay. Whiteboarding should be part of a holistic interview process, and if a candidate fails during whiteboarding, we should be aware whether the candidate is having a bad day. We should be giving wiggle room for candidates, as whiteboarding is often incredibly stressful.