Don’t make your tech candidates do whiteboarding interviews
Complicated whiteboarding sessions just are not very good at telling you whether a candidate can perform their job. What they test is whether you’re good at interviewing and whether you are good at memorizing textbook solutions to textbook problems. They end up being a series of riddles to test how clever you are, and do not end up reflecting how a realistic day of working in that position actually is. There is a reason that so many companies and books have popped up to help you memorize and pass MAFANG interviews. Facebook themselves run a program to help you pass their interviews! Google has a similar one. And here is an MIT class to help you get hired at Google/Apple/Facebook. 🤦🏾♂️
How often in your job have you sat down and worked on a brain twister for 30 minutes using a non-IDE, without looking it up on Stack Overflow, and then called it done? If that is not how the job is going to be done, why do companies still insisting on testing candidates in that way?
I’m a principal software engineer with over 15 years of professional programming experience. I have a degree in Computer Engineering, which I got from demonstrating my proficiency at math, physics, chemistry, computer science, electrical engineering (why????), and a bunch of other stuff. The point is- my fundamentals are strong.
I run a decently successful and profitable software business where I am responsible for the entire stack, from the frontend design all the way up to provisioning the API containers.
I have managed large teams. I mentor engineers. I am a respected voice in architecture meetings. I have given talks. I can teach CS fundamentals.
Yet- I am not good at whiteboarding exercises. I just am not.
It occurred to me that the engineering hiring process I originally set up at my current company has gotten so complicated that I wasn’t sure if I myself would make the cut. So when the opportunity arose recently to hire for a new team, we completely redesigned it from the ground up. It all starts with the application form. In order to write ours I looked at and drew inspiration from lots of other companies, especially Webflow.
Your application should tell the candidate what they will doing on the job, how you will measure their success, and what kind of person will thrive. Don't use words like "must have"; women and underrepresented minorities seem to remove themelves from the application process when they don't satisfy "must" criterias, whereas most men will not.
Don't ask your candidates to apply only if they're "rockstars". Don't tell your candidates you "work hard, play harder".
I also found that using years of experience with a technology ("5+ years experience with Deno") as a proxy for level of expertise leads to gatekeeping early career engineers who may have a richer understanding of some things than senior developers.
Candidates are invited to apply if they loosely meet any of several qualifications. We don’t require a college degree.
Here's the new interview process:
- The candidate is given a couple take home questionnaires so we can determine where in their career they are, if they actually know how to program, and then invited to a video call. The video call lasts 45 minutes. We go over a basic architecture problem with them, and to really drive home the point the exercise is done in Google Docs. The interviewer types notes into a shared document, allowing the candidate to just speak.
- The next interview is done over Google Hangouts. The day before, the candidate gets emailed a rough outline of the next day and what to expect along with links to documentation. The morning of, the candidate spends 4-6 hours with the team. They start their day meeting with the entire team including the project manager. They are introduced to the project, and given access to a GitHub repo for a fake project that runs entirely on their laptop. They commit code, push to GitHub, send us PRs, hang out with us on Slack.
This process gives us a really really good look at the candidate. We get to see them in an environment similar to a normal working day. Their levels of stress are significantly lower. And they can use StackOverflow / Google to their heart's content because...this is real life. We get a very good idea of how they respond to being stuck, if they ask good questions, if they like to work alone or collaboratively, and things like that.
I'm happy to say that this has worked really well a few different times, and we're excited to continue to iterate on the parts of this that are a bit rusty.
In conclusion, don't put your candidates through whiteboarding exercises. You will end up hiring people that are good at interviews, and not great at things they will actually need to get the job done.