Interviewing developers

July 12, 2007

I’m still working on my PHP job hunter book project, which is getting closer to completion.  This post doesn’t have much to do with that except to give an update, then segue in to a related bit.  I just stumbled on this post from a few years ago.  What I found interesting was the differing views that the respondents had on certain topics, like writing code at an interview.  An excerpt:

Bruce Eckel: I ask candidates to create an object model of a chicken. This eliminates any problems with uncertainties about the problem domain, because everyone knows what a chicken is. I think it also jars people away from the technical details of a computer. It tests to see if they are capable of thinking about the big picture.

Scott Meyers: I hate anything that asks me to design on the spot. That’s asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it’s fundamentally an unfair thing to request of a candidate.

Matt Gerrans: I don’t like when I’m asked to write a program that does X on a piece of paper. Don’t ask the candidate to write a program on paper. That is a waste of time and sweat. People don’t write software on paper, they do it with computers using auto-completion, macros, indexed API documentation, and context-sensitive help. They think about it, refactor it, and even rewrite it. If you want to see a person’s work, ask them to write some small module or implement some interface before the interview and bring the code on a notebook PC or on hard copy. Then you can review it and discuss the design, coding style, and decisions that went into it. This will give you a much more realistic and useful assessment of a person’s work and style.

I particularly liked Matt’s answer, yet I’ve found it to be quite a rare occurance.  Thinking back to interviews at the last few places I’ve been (including this one), I’ve never been asked for code examples.  In fact, I brought some to interview here, and was told explicitly that they didn’t want to look at that sort of stuff.  One of the rationales later given was that “anyone can just copy any code and claim it’s theirs - it doesn’t prove anything.”

I’d agree, just showing code on paper doesn’t, but asking someone to explain how and why they developed things in a certain way, and being able to see it in black and white (or on screen) is much more powerful than simply talking about ideas, or even whiteboarding those ideas.  It allows some people to BS their way past less-than-experienced interviewers.  If you’re interviewing for a development position, I would think it would be mandatory to see code samples and to walk through those code samples one on one to get a feel for how the person thinks.  I’m just not sure why it’s not done more often.  Is it that many developers don’t feel they’re up to the task of judging others?  Does it feel more like art than science?

Posted in Book, Job