Alternatives to the Whiteboard
Inspired, I wrote my own essay about the whiteboard problem and shared it on Medium back in May 2016. I've reproduced it here partly for posterity, and partly because hiring software developers is still a broken process and worthy of discussion. See my December 2018 post The Best Selling Tech Book on Amazon Is ... for more thoughts about this.
A long time ago, when I applied for my second software development job after college, I was thrust in front of whiteboard and asked to code a rudimentary strcpy() function. I felt uncomfortable, with one hand grasping a marker, and the other hand — fingers really — improvising as an eraser.
I wasn’t doing very well, as one interviewer looked unimpressed. The other, however, apparently saw something more in me, and put me in front of his PC and fired up the editor. I took to it like a fish took to water. And I got the job.
Now older, I find myself on the other side, conducting the occasional interview. I try to avoid using the whiteboard, but don’t always succeed. Over time, however, I have developed useful alternatives.
1. Bring me a sample of code that you are proud of and be prepared to discuss it.
Unfortunately, code nowadays is often confidential or under NDA. Open source, or in my day, shareware, fixes that… sort of. You can tell a lot about a candidate from the code’s style and discipline. And yet, Larson wrote of Sahat Yalkabov whom he described as open source extraordinaire, still could not land a job at a big tech firm. To be fair to the interviewers, reading other people’s code is a real talent and takes energy. Looking over the open source code of ten candidates would be prohibitive. Perhaps then, it would be best to use this alternative for your most promising candidates.
2. Look over the resume and find a project related to your own. Ask the candidate about it.
How long did it take? What algorithms did you use? What problems did you encounter? If the candidate was deeply involved, he or she should be able to speak at considerable length (points for being clear and articulate).
3. Tell me a few things that you love about C++ (or your preferred language) and a few things that you hate about it.
This reveals the candidate’s passion for programming, and tells me much much more than having him or her invert a binary tree on a whiteboard. One candidate couldn’t stop telling me things that were bad about C++. Even as I gently nudged him to tell me what he liked about C++, he would eventually drift back to everything wrong with the language. From this, I knew he wouldn’t be a good fit.
These are my core approaches. I try to tease out what the candidate knows and feels, rather than try to test for arcane knowledge. But sometimes, the whiteboard is unavoidable, as is the case for a recent grad who doesn’t have work experience to talk about. But even then, I focus on learning what they know, and make sure to provide a real eraser.
Comments