Technical Recruiters: It's Time to Ditch the Whiteboard Interview

By Dan Pickett

Meet David. When it comes to bubble sort, or many of the theoretical questions that typically get asked in a job interview for software engineers, he’s like most of the programmers I know. If asked on the spot at an interview such a question, they probably experience the internal monologue, “If only I had a computer to look this up like I do every day when I’m doing real work!”

There is, however, one thing that sets "DHH," as he is commonly known, apart from the rest of the programming community: He created the popular web framework used by thousands of developers, Ruby on Rails. It turns out, based on Twitter responses and prior posts, he is not alone in a sea of talented and reputable software engineers who have been frustrated by this phenomenon.

Commonly known as the “whiteboarding interview," prospective software engineers are asked to solve a technical, often theoretical problems in front of other engineers. While being able to recite the theory you read as a computer science or boot camp student, this type of exercise is starkly different from what you actually do on a daily basis as a software engineer. First, in practice, you have the benefit of great tools like the internet and your code editor. Secondly, while knowing such a theory is certainly important, most modern development leverages already optimized libraries that help to apply much of this theory in practice. Last and most importantly, however, a whiteboarding exercise often exercises recall more than what’s really needed in development: problem-solving ability.

Imagine you’re hiring an interior designer to spruce your place up a bit. If you were evaluating a few candidates, how would you pick the right one for you? Would you ask them each to recite the foundational theories of feng shui, or are you more interested in seeing examples of their work? I’d personally be most interested in what a designer could do and less about what theories they know.

So, it begs the question, why are we still using such theoretical questions in our interviews? First, hiring managers will cite that they need a quick means to qualify a candidate’s technical skills, and a tightly scoped theoretical question will help them to screen. Secondly, they will argue that assessing theoretical competence is the true measure of a programmer. While there may be some amount of truth to both of these justifications, I would wager that the real, underlying reason is a psychological one, and one you may often see in instances of hazing. Deep down, I wonder if the feeling really is “I had to do it, so they should, too.”

In a field that is suffering both from talent shortages and a lack of diversity, if true, such roots of this practice are problematic. At best, the assessment then becomes a rite of passage. At worst, it may be akin to hazing. Either way, it encourages conformity at a time when we need to engender a more welcoming community and industry.

Especially for those just starting their career, this can be a very intimidating and stressful aspect of the interview process. In many ways, you can typify it as a high-stakes quiz, where the consequences of not passing are not landing the job. So, you can naturally guess what happens next: You get candidates studying for the test, but not for the knowledge that ultimately makes them more capable. The success of published books and the number of upvotes on this Reddit thread shows us there is a focus in this direction amongst job candidates.

From a practicing professional’s standpoint, I view such a focus as a distraction. I’m much more interested in a candidate advancing their side projects than studying up for such a quiz.

So, what’s a job seeker to do?

1. Assimilate.

Most boot camps and intensive training programs will teach you enough of this material to be successful in such an interview situation. At Launch Academy, our students practice mock interviews to become comfortable with practice. The book, Cracking the Coding Interview is also great for this purpose, and we frequently recommend it to our graduates.

2. Disqualify companies that ask whiteboarding questions. 

When you have the benefit of experience and options, you can elect to simply not engage companies that make the whiteboarding interview a primary means of qualifying job candidates.

3. Resist. 

When you ultimately do land the job, encourage interview practices that assess capability as opposed to rote knowledge. At my company, we spend a morning pair programming with engineering candidates to evaluate a candidate’s development capabilities. As our VP of Engineering puts it, “Pairing offers a huge amount of flexibility when giving a technical interview. The interviewer can focus the time by selecting the theme and difficulty of feature work with your interview candidate.”

With your help, we can improve the software engineering interview process together.

--

Co-Founder of Launch Academy, Dan Pickett has been building web applications and technology teams since 2004. He has a passion for mentoring and educating aspiring developers.

This post was published on the now-closed HuffPost Contributor platform. Contributors control their own work and posted freely to our site. If you need to flag this entry as abusive, send us an email.
CONVERSATIONS