The “perfect” code interview
You’ve probably been there — Interviewing a potential developer. Most people (both sides of the table) dread this situation, and with most interview “processes”, its no fucking wonder. (Yeah, I went there kids, strap in.)
A disclaimer
Interviewing is different for every person & company, there is no such thing as a “perfect” strategy for an interview. Tricks filter out the baddies, and also some goodies too, so let’s try to come up with something more accurate.
Bad things about code interviews
- Tests/tasks given often consist of non-realistic scenarios that you’ll probably never encounter — Write a game? Whattt?
- Programming isn’t theatre or performance, “on demand” isn’t how your job works
- Stress compounds in the mind of the interviewee; You wonder what your interviewer is thinking, about trying to stay cool and collected… anything other than the task at hand
The rundown
- The developer in question has a github account — cool. You can see their interests, and the fact that they’re engaging with the community around them. How well do they do? Do they write tests for open source? Pull requests? Communication? Code quality?
- Find a project of theirs, perhaps a favourite / most actively contributed to.
- Setup a remote meeting time, connect with them beforehand on skype, google hangouts, or whatever you can use to screenshare with them. Keep it simple.
- Now, the project: Are there any bugs/issues listed? If there aren’t, come up with a new feature idea. Pitch it to the developer.
- Talk through the bug or idea, and ask them to spend 20 minutes fixing the bug, or implementing the feature.
Why this is awesome
- They’re using code that they’re familiar with
- You get to see their workflow
- You get to talk over creative ways of addressing the changes required
- They’re using their computer, the project, editor, bashrc, autocompletes — everything is ready to go
- You’ve demonstrated that you understand (and perhaps value) their work.
I’ve already said that no technique is perfect, but this technique could be fantastic for situations where you feel that this person can code, but you want to understand how they communicate, deal with real requirements and generally work (toolchain, process, ideals & methodology).
You’re a professional, someone has given you the job of figuring out who cuts the mustard, so you better get good at it. Do you have a better idea?


