Whiteboard coding is a popular and common way of assessing a candidates technical ability during an interview. They serve as a talking point to understand a candidates eligibility for the role, how smart they are, their technical and theoretical background and how they tackle problems. To quote Joel Spolsky:
…writing some code on the whiteboard, my real goal here is to have a conversation about it.
As I mentioned in my Basic Tips, interviews are a conversation between an business and a candidate that goes two ways. However, are companies not hiring candidates based on if they cannot get solutions correct? Do candidates get nervous and flunk interviews at the sign of a pen and dry eraser, even if they could be fantastic for the role?
If a candidate doesn’t know a “trivia question” programming problem, then perhaps they just haven’t encountered the problem before and won’t know the answer without the help of an online search. Smart candidates will give it a go and can intelligently talk about how they would tackle the solution, even their solution has bugs. The bugs can be discussed, but would this normally have happened? What about those who have just seen or revised the problem before and can talk about it?
So why then do I opt for a pre-interview technical challenge with Granify?
My thinking is that I want to give candidates a challenge they can spend as much or as little time on as they see fit before our scheduled interview date. Unless the candidate completely bombs or doesn’t put any effort into the technical challenge, we’re likely to interview them. It’s a talking point that I can code review individually, and then with the candidate during the interview.
It opens questions around any bugs founds, technical choices to reveal their insight into technologies used and why, things they would do differently, did they do any testing (and why), how they would make it easier to maintain in the future, coding style and design and more. Through them explaining their code to me as I ask potentially dumb questions of “how does that work?”, I get to see how they could fit as a mentor and collaborate with our technical and non-technical employees.
I feel that the pre-interview technical challenge serves a few purposes over the whiteboard interview:
- Weeds out those who cannot even tackle the problem before bringing them into the office
- Presents a non-trivial, real-life, interesting problem that passionate programmers will excel at. Those without the passion or effort have shown it through their technical submissions.
- Being non-trivial and real-world, the answer cannot be Googled in one or two searches to find a complete answer (although some parts could, and that’s okay as long as the candidate can talk about it and show understanding).
- Enables questions that revolve around the life of a developer, beyond just writing some code to solve a problem.
- Allows code reviewing and questioning motivations without the stress of asking a problem to be solved on the spot.
One down side is that individually it takes much more time. With a whiteboard coding problem I can ask in the interview and get an answer right there and then. With a pre-interview challenge, they candidate must go away and write a solution and then the interviewer spends time reviewing the code before the interview.
Counter to this,having code to talk about from the get go in the interview and bringing out the good from the bad programmers before they walk into the building saves time in the long run for Interview planning and finding the right people.
Tell me your thoughts. Does your company prefer whiteboard, technical challenges or something else? I can’t say my preference is the best or perfect but I strive to find better ways to hire better candidates.