I’ve been responsible for the technical evaluation portion of some developer interviews recently. I stumbled through the first few, unhappy with my aged and worn approach of asking questions, having the candidate write pseudo code on a white-board, and so. A friend challenged me: he said that the interview should be a positive experience for the candidate even if they don’t get the job.

With that in mind, here’s what I decided to do.

A few days before an interview, I’d sent the candidate a link to a repository. Specifically, some code that p&p had worked on and was publicly available. (I’d ask ahead of time what languages and platforms the candidate was comfortable with, and choose a code base accordingly.) I’d tell the candidate to be prepared to write some code during our time together.

Next, I’d pick two or three scenarios (stories or bugs) to work on with respect to that code base. However, I would not share the exact scenarios with the candidate ahead of time. I like to see how a candidate first reacts to a problem. It also give an opportunity to observe the candidate navigating unfamilar source as they acquaint themselves with what needs to be done.

I’d allow the candidate to bring their own computer (if they desired), to search the web (a very important skill), and to ask me questions. Furthermore, I would spend at least half of the time ping-pong pairing. They would write a test and then I’d implement it, we’d switch and so on.

I was also careful to share all of this with the candidate ahead of time. Being prepared is important, and I like to see how candidates prepare. Interviewing is not about solving clever tricks, it is about seeing if they can be a productive team member. My purpose was to simulate actual work.

I think that my approach still has plenty of room for improvement, but I like the direction it’s been going so far.