Dev Discussions: Eradicating Whiteboard Interviews with Jon Nguyen of NoWhiteBoard.org
Raise your hand if you’ve ever had to do a whiteboard interview for a job. 🤚
Now raise your hand if you like doing whiteboard interviews.
… I’ll wait.
If you didn’t find your hand waving in the air, you’ll enjoy the insights Jon Nguyen of NoWhiteboard.org provided during his discussion with CoderPad developer advocate Corbin Crutchley.
Jon’s website is a goldmine for people fed-up with having to jump through hoops to get a job. It’s a job board for companies that don’t do whiteboard interviews and are transparent about their interview process.
Inspired by the “Hiring Without Whiteboards” repo on Github, Jon wanted a job board as candidate-friendly as possible. His goal in starting it was to help candidates who don’t have the luxury to spend months preparing for interviews or days carrying out whiteboard tests.
He also posts the salary (when possible), the recruiter’s contact information, and the needed skills, so you have all the essential information when you’re ready to apply.
What’s wrong with whiteboards?
Jon’s journey to NoWhiteboard.org stemmed from the frustrations he and many other developers encountered while looking for a new job.
First, there are the companies that put you through eight rounds of interviews – including hours-long coding tests – only to ghost you near the end. That’s a lot of wasted time and effort.
Second is the time of the actual coding/whiteboard tests. They take time, some more than others.
If you already have a full-time job or kids – or like many others, both – finding the time to take these tests can be difficult. These developers may not have time to take them at all, and you eliminate many developers from your pool. You are also biasing your candidate pool towards those who have lots of time to work on a test.
Not to mention the issue in point #1 again. How would you feel about spending your weekend on a coding test to not move on to the next round while also not getting any feedback about what they were looking for?
Third is what companies typically use them for and what they’re actually good at measuring.
Looking for a new job is already nerve-wracking enough. Spending your relaxation time on overly-long take-homes or coding in front of people you don’t know can leave you with a bad taste in your mouth – especially if they’re not measuring anything meaningful.
Companies often use these to “test” your coding skills with an algorithm question. They don’t test coding skills more than they test your ability to remember things from your university or early career that usually don’t have any bearing on the actual job. How often are developers actually coding standard algorithms in their day-to-day job?
That can be annoying for junior candidates – especially if they don’t come from a computer science background – and downright insulting to more senior developers.
If the question is something that a candidate can easily Google and find the answer to, it’s probably not a good question. It’s not a practical way to evaluate the thought process or problem-solving skills of how someone would actually work within your company.
A better way
So what are the things that interviewers should be evaluating, whether they use whiteboard interviews or not?
Corbin and Jon both agree that communicating well with others is one of the most significant measures of success for employees.
You can easily add this into a live coding interview by doing a paired-programming exercise with the candidate, asking them how they document their code or asking them what they would do if they found a bug in another developer’s code.
Additionally, you can gauge how a candidate thinks by giving them a difficult choice to make – for example if you’re a tech lead leading a team behind on feature development with a looming deadline, what do you sacrifice? Do you miss the deadline to get all the features in? Do you request your devs to work overtime to meet the deadline?
Corbin stresses again that whatever question is asked should represent an issue the developer candidate would face on the job; the question should also be clearly written with explicit requirement criteria.
Jon adds there are ways companies can show respect for a candidate, and the time they’re investing in the process:
- Allow the candidate time to read the question and collect their thoughts before the timer starts, whether in a take-home test or a live interview.
- Pay the candidate for completing any project or test that is part of the interview (MindsDB does this).
- Create a time limit for the test so that the candidate isn’t spending their entire weekend working on the project.
Keep in mind: Good developers and engineers will often stay in their current roles because of how bad the tech interview process is these days. If you want to increase your talent pool, you need to fix any broken processes you have in your interview process.
What was your worst interview experience?
Corbin and Jon then shared their best and worst interview experiences, which should serve as a list of do’s and don’ts if you find yourself interviewing anyone anytime soon.
Corbin’s worst interview experience started well with a take-home test he enjoyed and did well on. It went downhill when he was asked an algorithm question about reversed linking. He fumbled through that as he was self-taught and didn’t take the traditional computer science degree path to become a developer.
To add insult to injury, they went deeper into theory – rather than into practical application – by asking him “tech trivia” questions like the difference between async vs. defer keywords in <script> tags. You know, the kind of questions one could easily Google.
His best interview experience was with Hilton. He did both a take-home test and a live interview coding exercise, and where Hilton shined was during the exercise. Instead of the standard “code anxiously in front of the interviewer,” Hilton turned it into a peer programming exercise where Corbin coded side-by-side with the interviewer.
The interviewer turned it into a conversation about the different ways to solve the problem and the pros and cons of each. Corbin felt that it was so informal, and he learned so much that he didn’t even realize he was being evaluated for his problem-solving skills.
Jon’s worst experience happened near the beginning of the interview process when the recruiter gave him an update on the process. Five minutes into that phone call, the recruiter started asking him “tech trivia” questions out of the blue.
What made matters worse, the questions were asked by a recruiter with no technical background, only looking for Jon to give the correct keywords. They didn’t understand much of the nuance of Jon’s answer, and he ended up stopping the phone call early and not finishing the interview process.
His best interview experience was with his most recent company. He had a take-home assignment to create a REST endpoint, and it was short enough that he didn’t feel like he had to give up his weekend to work on it.
After that, he had a live interview with a question that was built upon the work he did for the take-home assignment. That helped him feel more prepared for the interview and more interested in it. He got to talk about the tradeoffs of his solution versus others, and it felt more relevant to the job.
Wrapping up
Jon is so passionate about eliminating whiteboard interviews that he recently resigned from his job to pursue NoWhiteboard.org full-time. He has more tidbits on questions he asks as an interviewer and why he thinks side projects are an excellent way for junior developers to stand out – and you can watch him talk about those in the Twitch playback video here.
Interested in more conversations with developers about their career? Checkout these other Dev Discussions: