Interviewing Programmers

Post by Scott Vlaminck

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.

About Scott Vlaminck

believes software development is more about people than technology; believes in agile processes; software developer, engineer, designer, architect, or whatever they're calling us these days; enjoys discussing software design; working on a program to write other programs (but it hasn't written itself yet).
This entry was posted in Agile Processes and tagged , . Bookmark the permalink.

Related Posts:

One Response to Interviewing Programmers

  1. Ben says:

    In Rules for Revolutionaries, Guy Kawasaki talks about bringing the right people into a startup, into your own company rather than the company you work for. He puts hiring into perspective in this way: (I’m paraphrasing) “Hire only people who, if you saw them at the mall on the weekend, you would run over to them and say hi.” In other words, hire people you are excited about and like. Don’t fall into the trap of looking too hard at resumes and experience, enthusiasm, fit, and just “being the right type of person” will get you farther in the hiring process.

    Another thing he mentioned in his book was that people looking to hire a team should not “succumb to the temptation of hiring people who are underemployed or unemployed because it’s easy to recruit them. Great people are usually contributing to important projects and are quite busy, if not unavailable. Convincing them to join a team is, in fact, the first confirmation that an idea has merit.”

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>