In 2017, prominent software engineers took to Twitter to confess that they would fail a whiteboard interview. A popular way to evaluate programmers of all experience levels, “whiteboarding” involves presenting candidates with a computer science problem to solve on a whiteboard in real time. Engineers have been complaining about them for years.
David Heinemeier Hansson, the founder of Ruby on Rails, one of the most successful web frameworks in history, led the way. Top developers from Google, Microsoft, and the New York Times joined in.
Yet whiteboarding still constitutes a core part of the interview process at many tech companies, especially at FAANG (Facebook, Apple, Amazon, Netflix, and Google) and unicorn companies.
But the new normal of remote recruiting during the coronavirus pandemic presents an opportunity for recruiters, tech leaders, and the entire software industry to reexamine the original purpose of whiteboarding interviews. We need to ask whether they deliver on those goals and look at who they serve — computer science graduates — and who they don’t — those coming from nontraditional backgrounds. We need to realize that remote interviewing only makes the problem worse.
We need to implement alternatives that more effectively and inclusively measure engineering talent, team fit, and growth potential in video and phone interviews. It’s the most important reform toward a more diverse and inclusive industry.
The headache of hiring developers
Getting into Google is more difficult than getting into Harvard. (The former has a 0.2% acceptance rate against the Ivy’s 4.9%.) Top tech companies are well-known for conducting grueling interviews, especially for software engineers.
When faced with thousands of applicants, how does a company sift through applicants, shortlist the best, and hire the very best? No matter the industry or role, recruiting is difficult. Companies inevitably hire a poor performer on occasion and allow excellent candidates to slip through.
It is incredibly difficult to evaluate a candidate’s technical skills without actually working with them.
Hiring software engineers is particularly difficult. Competition for top talent is high. There are over 150,000 open roles on LinkedIn and “software engineer” consistently ranks as the most in-demand job, even during a pandemic. The primary pain point: It is incredibly difficult to evaluate a candidate’s technical skills without actually working with them.
Common ways companies conduct technical screens include:
- Take-home projects where a candidate is given a few days to build a simple web app
- Code review of existing work
- Quiz questions on coding and web fundamentals
- Solving algorithm and data structure questions in a one-on-one whiteboard interview
With all the criticism and ample alternatives, why do companies still conduct whiteboard interviews?
Hazing ritual or necessary evil?
When computers were first invented, time on the computer was expensive. It was not uncommon to write code on a piece of paper before inputting to a computer. Computer programming has changed a lot since then. Although sketching out a system or handwriting code can help one plan and more deeply understand a piece of software, real-world programming today leans heavily on different frameworks, libraries, and Google searches. Building functional and beautiful software requires a profound understanding of how all of these tools build upon each other and at least a basic understanding of how they work under the hood.
Why remove the normal tools a programmer now has at their disposal, including the obvious: a computer? Why ask algorithm and data structure questions?
Some say it is an important “rite of passage,” an inevitable hurdle to conquer on the road to becoming a software engineer. Interviewing should not be used as a hazing ritual.
Some posts about the topic argue that studying algorithms shows a candidate’s eagerness to learn. Successful candidates, beginners and experienced programmers alike, spend hours preparing for these types of interviews.
There is an entire industry built around technical interview prep — from subscription-based practice sites like LeetCode and InterviewCake, to mock interview platforms like Pramp, and entire boot camps devoted to algorithms and data structures. The fact that even experienced developers use these supplemental and often costly resources proves the point: In general, a developer’s real everyday work has little to do with the questions asked in a whiteboarding interview. (There are also plenty of other ways to measure curiosity and hustle.)
The most compelling reasons I found for using technical screens are to determine whether a candidate is lying about their programming abilities and to better understand their thought process and collaboration style.
With these goals in mind, technical interviews should be centered around answering these questions:
- Can you code?
- Can you collaborate?
Coding on a whiteboard, or during Covid, on a noncompiling text editor or Google Doc while on Zoom (I have been asked to do both) are not the best ways to evaluate these skills.
The diversity problem
I recently shared my path to starting my first software engineering role. After failing to make it through the University of California, Berkeley’s introductory computer science courses, I spent the early years of my career in a communications role before eventually finding my way back.
My key learning was that although companies rarely require a computer science degree (job postings will often say something like “CS degree or equivalent”), the interview process heavily favors a formal background in computer science. As someone with experience in university CS as well as a boot camp — I did Flatiron’s full-stack program earlier this year — people often ask me the difference between the two types of education.
College courses primarily focus on computer science concepts and principles including algorithms and data structures, which are necessary to succeed in a whiteboarding interview. Most boot camps spend little-to-no time on this type of material. Flatiron focuses on learning web development, and you build several full-stack applications in the program. I never built a web application or used a framework in college CS.
While both types of education are valuable, boot camps provide an important entry point to software engineering for underrepresented groups. Boot camp grads come from a diverse range of backgrounds. Many slipped through the cracks in college or didn’t see software engineering as a viable path until later in their careers.
Whiteboard interviews are also intimidating, especially for those who suffer from imposter syndrome (which disproportionately affects women and people of color). The remote experience could compound the intimidation factor. It did for me.
We are all now experiencing how difficult it is to form a personal connection on Zoom, especially with someone new. It’s that much more difficult when working outside of your confidence zone.
Because my job search coincided with the first few months of Covid lockdown, all of my interviews were remote. Whiteboarding interview questions provided me with little opportunity to authentically convey my ability to work effectively with others. Even for something as simple as writing a clear commit message, collaboration, and communication are crucial for effective software development. I was unable to show these strengths or even just be myself. I know I’m not alone.
There’s a better way
Plenty of companies recruit talented engineers without whiteboarding. My previous company, Artsy, does not have any technical component in their interview process. Even early on, they were able to recruit some of the best engineers in the industry. There are simply so many better ways that more effectively answer: Can they code? Can they collaborate?
My top three alternatives:
1. Pair program
Pair programming — working with another developer on one machine — has grown in popularity to boost code quality and help engineers grow. When I was interviewing at my current company, VTS, the second of my three interviews was a “pair programming” exercise in which the interviewer and I collaborated on implementing a few simple methods in JavaScript. Simply framing the interview as a collaborative exercise alleviated so much of the anxiety. I felt like I could ask questions and bounce ideas off of my partner. Remote pairing is now part of many developers’ daily workflow so is, in itself, a valuable skill to assess.
Simply framing the interview as a collaborative exercise alleviated so much of the anxiety.
2. Talk through past code
A past project or pull request is preferable, but take-homes work too. Use the candidate’s previous code as a jumping-off point to determine how they understand code, make trade-offs, and communicate their decisions. I read that companies worry about cheating — candidates asking friends or paying a developer on Fiverr to complete the assignment. Instead of training interviewers to ask esoteric whiteboarding questions, train them to ask thoughtful and thorough questions about previous work.
For companies who choose this method, be respectful of your candidate’s time. Many of my peers are balancing other jobs and taking care of kids at home. I completed several take-home assignments for companies that were either not seriously considering me or never had a conversation with me about the work and moved onto the next step. If take-homes are time-boxed, designed to help engineers learn something new, and followed by a comprehensive discussion, they can be well worth the effort.
A lot of people think references are fluff, but most companies conduct references poorly.
3. Lean into references… but be thorough
Past performance is the best indication of future performance. Talking to people who have previously worked with your candidate can provide invaluable insight into how they will perform in a new context. A lot of people think references are fluff, but most companies conduct references poorly. Asking a set of specific questions and digging for substantive answers will reveal more than you think. Here are some examples used by Artsy, which heavily weighs references in their interview process:
In your capacity as [relationship to the candidate], how many people have you worked with in the candidate’s role?
In just terms of job performance, how do you rank the candidate out of that [X] many people?
What’s the difference between [the candidate’s rank] and number one? How would the candidate need to grow to get to number one?
Fear of asking for help
Whiteboard interviews were hard for me, not because the questions were too challenging or I didn’t want to put in the work. They were hard because I was scared to ask for help. Knowing when and how to ask questions, whether from your colleagues or Google, is one of the most important skills to develop as an engineer. Virtual whiteboarding sessions do not allow for sufficient back-and-forth between the candidate and the interviewer. In the remote setting, it is so hard to be vulnerable.
When I saw veteran software engineer Estelle Weyl’s tweet from the 2017 trend, I deeply identified with the fear of admitting you don’t know something. Amidst her mostly male colleagues revealing their inabilities to sort a binary tree, she said:
Eliminating whiteboard interviews didn’t happen in 2017, but maybe it can in 2020.
To connect with Anna – Linkedin
