Nat Pryce has a good post about interviewing programmers. Everyone that I’ve talked to has the same problem: How to figure out if a programmer is any good before you hire them. A similar problem exists in just hiring people in general, but this is the more specific problem of determining skill level.
Some people can talk a good game without actually being able to think through a problem to a logical and feasible solution. Others can walk through a hypothetical example at a whiteboard with ease or explain in detail how and when to use inheritance vs. delegation. These same people, however, may not be at all capable of tracking down how to fix a coding defect or how to add new functionality to an existing codebase. Ultimately, you really don’t know much about their actual skills until you see them code in a real environment. I think that Nat has a lot of good ideas here.
In my own experience on a smaller team, we’ve had good luck with getting referrals and checking references as a start. Then we interview and if we decide they seem like a fit, we bring the developer in as a contractor with a hire clause. That way, if they work well in our team we can bring them in full time. The interview process ends up being what I expect is pretty typical, but we start all of our developers as contractors. This lessens the hiring burden and gives us some time to figure out if the person is a fit for our team. It’s not perfect, but like I said, we’ve had pretty good luck with it. We haven’t had any pushback from our developers on this stance either. Most don’t seem to care of they are full-time employees or contractors. In some instances, candidates have asked that the hire clause be removed because they had no interest in a full time position.
Another thing that originally interested me in Nat’s post about interviewing was the comments. Since interviewing and hiring is a problem that everyone faces, I’m interested hearing what others have learned about hiring developers over the years. Regardless, I plan to start incorporating some of Nat’s ideas in my next interview.
Another problem that agile teams face is making sure that the developers understand the customer and/or the business. Along those lines, Martin Fowler has a good post about what he calls Customer Affinity: The ability for developers to really get involved with the customer and maintain a two-way conversation about software. I’m not sure of a good way to interview for this, but our current approach of contract-to-hire allows us to get somewhat into this before a hire decision must be made.