Why is hiring broken? It starts at the whiteboard. by Quincy Larson

Open source extraordinaire Sahat Yalkabov has given up his search for a front end developer job after a series of technical interviews that he described to me as a “humiliating and dehumanizing process.”

Various recruiters lined up interviews for him at six different companies over the past few months. Each of his interviews revolved around scrawling algorithms on a whiteboard, in front of other developers, who stood by to render judgement on his fitness for the job.

And after each interview, he received a brisk email informing him of the company’s decision not to proceed with his candidacy, without any further explanation.

Sahat isn’t exactly an outsider. He has a computer science degree, has worked as a developer at Yahoo, and is among the most prolific open source contributors.

Sahat’s open source contribution activity on GitHub.

At a time when big tech companies are scrambling to find capable developers, why is he having so much trouble getting job offers?

The answer lies in part in with how big tech companies interview developers.

You might assume that in this high tech industry, interviewers use fancy tools to analyze the quality of code samples, or look at how widely a candidate’s code was included as a dependency in a package ecosystem like npm. That’s how an academic researcher’s work would be judged — by how many other academics cite them.

Unfortunately, interviewing practices at big tech companies aren’t that scientific. The decision of whether to hire a developer usually comes down to the candidate walking up to a whiteboard and regurgitating algorithms that haven’t changed since the 1970s, like a (classically) trained monkey.

Sahat is not alone in his frustration with the whiteboard-centric technical interview process used by most major software companies. Virtually every developer I’ve talked with agrees that one’s ability to write algorithms from memory on a whiteboard has almost nothing to do with real day-to-day developer work.

How whiteboard interviews work

The most common tasks meted out at the whiteboard are recalling algorithms and writing them bug-free on the whiteboard.

There’s usually an element of time pressure. If you don’t remember the algorithm or never learned it (i.e. never had a use for it), your interviewer may push you to guess your way into a working implementation.

Your interviewer will probably ask about time complexity, seeing if you can reduce the time it takes to run your algorithm from say O(n log(n)) to O(n).

And remember that this is a whiteboard — not a code editor. You can’t actually run the code to see if it works, let alone benchmark it. So your interviewer serves as judge, jury and (literally) executioner of your code.

The good news is you can prepare for whiteboard interviews, just like you can cram for a college entrance exam. And there’s a cottage industry of books and websites aimed specifically at helping you ace the whiteboard interview process.

Whiteboard interview questions generally come from a predictable pool of around 200 questions, the solutions of which are all available in Cracking the Code Interview. This book is the closest thing to a whiteboard interview playbook. Its author wrote it based off of her experience interviewing developers for Google, Amazon, Microsoft, and Apple.

Of course, your interviewer is under no obligation to ask you one of those questions you so diligently prepared for. If you’re unlucky, they could ask you to write out an algorithm you’ve never heard of before. This is the essence of the “algorithm question lottery.”

Developers will often defend whiteboard interviews as meritocratic. Anyone who wants to spend months of their life toward committing algorithms to memory can go and get that job at Google.

And a majority of these algorithms are already touched on as part of a computer science undergraduate program.

So what’s the problem?

The case against whiteboard interviews

The problem is that writing algorithms on a whiteboard has almost nothing to do with modern software development.

In real life, you would rarely just whip up an off-the-cuff algorithm from memory in the middle of a coding session. You are almost always going to use an existing library, which has its own test suite, and has survived the scrutiny of other developers.

The only world where you would actually need to be able to recall an algorithm would be a post-apocalyptic one, where the hard drives of all the computers connected to the internet were fried, and all copies of foundational academic papers and computer science textbooks had been reduced to ashes.

Whiteboard interviewing is a discrete skill, much like being able to remember Pi to a thousand decimal places. And students of programming are spending a disproportionate amount of their time mastering this skill instead of practicing real software development by building projects, maintaining legacy code, or contributing to open source.

This ultimately reduces the quality of entry-level hires, as it becomes difficult for the average interviewer to figure out who’s good at developing software, and who’s merely good at whiteboard interviewing.

It also freezes out many of the people who are under-represented in the software development field. If you’re busy working and raising kids, you want to spend as much of your scarce time as possible learning to code — not performing rote memorization that won’t matter once you start your job.

Even if you could afford to pay for a cram school (and some will garnish your future wages instead of asking for cash up front), you would still need to allocate time from your busy life to attend.

Whiteboard interviews also punish more experienced developers who are too busy doing real software development to drop everything and cram for a month. They also punish people who don’t have a computer science degree, or who finished theirs so long ago that they’ve forgotten most of these (rarely needed) algorithms.

Whiteboard interviews favor fresh graduates from theory-heavy computer science programs. But it’s hard to believe that those are the people who will perform best in the highly collaborative, practical 21st century developer workplace.

So why do we do whiteboard interviews?

Whiteboard interviews are akin to a hazing ritual — a rite of passage that one must endure before joining an organization — because everyone else there did. “I went through a battery of whiteboard interviews when I got here, so why shouldn’t this person?”

Supporters of the whiteboard interview will argue that it tests one’s ability to solve problems under pressure, or that it tests fundamental competence.

Whiteboard interviews provide an interviewer a defensible reason for passing on a candidate that their gut tells them they don’t like. Instead of attributing a no-hire decision to a poor “culture fit”, the interviewer can tell themselves and their superiors that “she just didn’t know how to invert a binary tree.”

It also provides the interviewer with an opportunity to feel smart and validate that “they’ve still got it” and that they aren’t themselves an imposter, by critically examining the work of an outsider who wants in.

Because of these forces, whiteboard interviews may stick around for a long time, like a circle of retribution — an ordeal inflicted upon one generation of developers by the previous, that will in turn be inflicted upon the next.

How can a good developer cope with whiteboard interviews?

There are only two good options here (other than to give up and go farm goats).

Option 1: Accept it and cram.

Every responsible academic program is encouraging new developers to learn these algorithms. Dozens of the algorithms in Free Code Camp’s curriculum come directly from common whiteboard interview questions.

Many of our students have told me that their prior experience with these specific algorithm questions was critical in landing their first developer jobs.

We have also created a lot of videos focused on time complexity and data structures, and are working on a system for conducting live mock coding interviews through our platform.

Option 2: Avoid companies that do whiteboard interviewing

Already, many experienced developers will flat out refuse interviews that involve whiteboards. Many of these developers are so good that they can often afford to be more selective.

Four Square has publicly ditched whiteboard interviews in favor of take-home assignments.

We were concerned that [the whiteboard interview] process filtered out many other great engineers for reasons other than their abilities. Some possible reasons include variation between interviewers, candidate nervousness, or the unnaturalness of whiteboard coding generally.

In doing so, Four Square has gotten rid of the random false negatives that can result from the “algorithm question lottery.”

Pivotal Labs is famous for their pair-programming-centric interview. You come in to their office in the morning and pair all day with a one of their developers. One of our students went through their interview process, loved it, and accepted a job there.

Whatever you do, don’t give up and go farm goats. Regardless of the stubborn hiring practices of big tech companies, the world needs a lot more good developers! So keep fighting the good fight.

---

Thanks for reading my article! If you found it helpful, recommend it to your friends on Medium by clicking the green heart bel

Quincy Larson

Teacher at FreeCodeCamp.com