by Sun-Li Beatteay
Let’s talk about whiteboarding interviews and the possible alternatives
It’s not news to anyone that many engineers hate whiteboard-based interview questions.
Whether it’s on Twitter, Medium, or LinkedIn, it’s easy to find someone venting. The phrase “the hiring process is broken” is used so often it’s become a cliché.
Unfortunately, much of this frustration is falling on deaf ears.
Despite the chorus of ire surrounding it, “whiteboarding” is still a staple in software engineering interviews. Part of that is due to the fact that developers are quick to voice their resentment, but slow to offer better alternatives.
Are there better alternatives?
This question has been on my mind a lot recently. Four weeks ago, I landed my first full-time software engineering job. While I’m not involved in the hiring process yet, I will be eventually.
Having been on the other side of the table just a month ago, I understand how imprecise interviewing can be. When it’s my turn to ask the questions, I want to make sure that I evaluate my potential colleagues with accuracy and fairness.
This predicament has led me to two questions:
- Are whiteboarding interviews the best choice?
- If not, what are the better alternatives?
In this post, I’m going to attempt to answer these questions. Keep in mind, these are my personal opinions that have been shaped by my own interviewing experience.
I will try to be as objective as possible by approaching this task in true software engineering fashion: examining all the options and weighing their tradeoffs.
Are whiteboarding interviews the worst?
The first step in this process is to scrutinize whiteboarding.
- Fast and low effort
- Not language or domain dependent
- You know (generally) what to expect
- Community support (Glassdoor, LeetCode, Pramp, and so on)
- Luck is a big factor (algorithm lottery)
- Doesn’t necessarily test engineering aptitude
- Favors young engineers and recent grads
For companies who require engineers to have a strong grasp on CS fundamentals, low level algorithms, and aren’t dependent on libraries, the whiteboarding interview is perfect.
SpaceX, MacOS/Windows, and Facebook’s React were all built by engineers with such knowledge. To get a whiteboarding interview from one of these companies is to be expected.
As a job candidate, I love whiteboarding interviews. I know what to expect. Most algorithm questions fall under these general topics:
- Binary Trees
- Linked Lists
- Dynamic programming
Knowing this ahead of time means I can study for it. And there’s a plethora of studying tools to choose from. Technical interview preparation is an entire industry of its own.
It’s for that reason that whiteboarding interviews aren’t the best option for every company. So much of it comes down to luck, memorization, and whoever has spent the most time studying.
Not everyone can study for long swathes of time to master algorithms.
I was lucky that I could and outcompeted other engineers who couldn’t. Am I a better engineer than all of them? Maybe, but I’m not sure a whiteboarding interview is the best means of revealing it.
So if there’s doubt that the whiteboarding interview is the best tool for the job, what could be better?
Let’s take a look at some of the alternatives.
Coding challenges via computer
- Get to use a computer and familiar dev environment
- Can be done remotely via screen share
- All of the other advantages of whiteboarding interviews
- More strict about syntax and run-ability.
- Programming environment and plugins can play a big factor
- Same disadvantages of whiteboarding interviews
Coding Challenges on a laptop are the less rigorous cousin of the whiteboarding interview.
Candidates have the benefit of using their own computers. They can be done remotely or in a pair programming environment.
One nice thing I’ve noticed about these is that they will usually be easier than whiteboarding questions. Most of the questions I got involved string manipulation, or simple algorithms that any experienced engineer wouldn’t need to study for.
The drawback to this is that there is much greater emphasis on functionality.
During my job hunt, I was asked the Coin Change problem twice. One as a whiteboard challenge and the other on an editor.
For the whiteboard challenge, I got away with mainly explaining my solution. On my laptop, I was expected to write edge case tests and guarantee that my solution worked.
Part of the reason I like whiteboarding is due to the leniency. No one is going to run your written function through a compiler. As long as the interviewer understands what you’re thinking and the writing looks good enough, you get full credit.
Not so with code challenges.
Some may argue that the emphasis on functionality is better, because we’re paid to write working code. That’s true, but we aren’t getting paid to do it in 30–45 minute sprints.
Let’s just hope you don’t get nervous during interviews. One small bug that causes failing tests and several minutes of debugging could be the difference between a “strong hire” or a pass.
Code challenges still suffer from the same short comings as whiteboarding because many of them are algorithm-based.
With the added pressure of functionality, it can make the questions even more difficult despite the comfortable environment. If you already dislike algorithm problems, code challenges won’t be much better.
Take home assessments
- Can work on it in your pajamas
- Usually given upwards of a week to work on assignment
- Get to use your own editor and dev environment
- Can be a new addition to portfolio
- Usually more fun than whiteboarding
- Level of difficulty can range drastically
- Much more effort and time consuming than coding challenges
- Can be domain dependent
- Can lead to feature creep due to competition
- Doesn’t represent day to day work
A lot of engineers prefer take home assignments. The timelines for turning them in are usually flexible, and candidates get to actually code. It’s no shock programmers prefer this to standing in front of a whiteboard while being silently judged.
However, take home tests have some major drawbacks.
Firstly, they’re easy to manipulate.
Many companies host their tests on GitHub. Type in “Challenge” or “Test” into GitHub search and you’ll find plenty. This will give the savvy candidate plenty of time to preemptively research the challenge.
That’s not really a complaint. Just more of a pro-tip.
What is an issue is that it’s easy enough to find other people’s answers to these challenges and copy them. Plenty of engineers keep the answers to take home challenges on their GitHub profiles.
You can even test it yourself. Type “<Company Name> Challenge” into GitHub search and see what you find.
I live next to the Etsy headquarters in Brooklyn and was curious if I could find the answers to some of their tests. “Etsy Challenge” revealed four. There were even more under “Etsy Test”.
It’s true that companies can change their assessments. However, it can be a hassle to change an interview process every couple months due to details being leaked.
Secondly, the level of difficulty and time it takes to finish these challenges varies widely.
During my last job hunt, I was given four take home assignments. Three of the companies said they should only take 3–5 hours to finish.
They all took me multiple days.
The main reason for this was because the challenges were often domain specific. They required several hours of researching API docs and new technologies.
The fourth company took a challenge that could easily take a week and gave me two days. I had to build a functioning chat app that supported slash commands.
It was a fun and interesting project, but it required me to drop everything I was doing for two days in order to complete it.
If a candidate is fortunate enough to interview with multiple companies at once, it can become a full time job just working on these challenges.
Additionally, professional developers have to work on legacy codebases and deal with deadlines. A week long greenfield project isn’t going to assess how well the interviewee works in a fast paced environment.
Overall, I like take home assignments as an initial screen of a candidate’s ability. With that said, they should be related to the job the candidate is applying for, and shouldn’t take an obscene amount of time to finish.
- Get a chance to work with candidate/team
- Get paid to work
- Get to work on real projects
- Are evaluated on how well you work with team and ship code
- Long time commitment
- Working without a guarantee of employment
- No health benefits as a contractor
- Can put candidate in bad negotiating position
- Language dependent
Project-based interviews are rare. But quite a few companies stand by them, such as Basecamp and Automatic. I can understand why.
These interviews are probably the most accurate way to assess someone’s skill and evaluate them as a team member. The company gets to work with them directly and see how they handle tasks in a team.
The candidate also gets a chance to evaluate the company and determine if it is the type of environment they would like to work in.
Win-win. Or so it seems.
With all of that said, as a job candidate, I would never partake in project-based interviews or contract-to-hire roles. The negatives far outweigh the positives.
The first couple months of any job are typically the toughest. You’re acclimatizing to a new team, culture, codebase. Now imagine working on a project not knowing if you’ll have a job by the end.
A good friend of mine recently interviewed at Automatic and confirmed how stressful it can be. Everything from the way you interact with coworkers to the questions you ask are judged. In these environments, there is such thing as a “stupid question.”
What’s worse is that he was let go after the three month contract. Luckily, he hasn’t let it impact his self-esteem. He knows his ability and is charging ahead. I’m not sure if I, or many other engineers, could do the same so easily.
Furthermore, contracts put the job seeker in an awful negotiating position. Strength in negotiations comes from the willingness to walk away.
By the end of a contract-to-hire period, the potential candidate won’t have any bargaining chips. They won’t have any other offers and they’ve already poured dozens or hundreds of hours into their projects depending on the contract length.
They would be incentivized to take the position even if it’s not their preferred choice. The alternative is to join the job market back at square one.
The Sunk Cost Fallacy at its finest.
While whiteboarding interviews may not be ideal, I would do a hundred of them before I ever did a project-based interview.
So which is the best?
As you might’ve guessed: It Depends™.
The tradeoffs seem to be between speed and effort versus accuracy. Each method sacrifices one for the other. It is up to each company to judge those tradeoffs for themselves. SpaceX is most likely going to have a different process than small New York startup.
What is true is that a SaaS company should only ask candidates to write out dynamic programming algorithms if it helps them determine the engineer’s skill. Not simply because Google does it.
If I were designing the interview process for my team at DigitalOcean, I would use a mixture of take home assessments and code challenges/pairing exercises. I would also gauge their understanding of availability and distributed systems through a Q&A session and system design challenge.
The good news is that my team already does this. DigitalOcean’s tough yet fair interview process was one of the reasons I accepted their offer. It proved to me that they had already gone through this self-examination process and found out how to fairly evaluate their candidates.
Please let me know what your preferred interview method in the comments below!
Finally, for all you engineers who want to see the interview process change, start coming up with ideas. I’ve seen too many engineers rant about whiteboarding interviews only to continue the process once they get hired because it’s too much work to change it.
Don’t be that person.