The routine of a software developer normally turns around design, implementation and testing. But hopefully there will be times in which the team needs to grow, and then he will be asked to do something extraordinary: Interviews.

In the software industry, it is natural to ask technical people to conduct interviews: After all, the company needs to evaluate the professional skills of the candidate, sometimes in a very specific field or technology, and this surely cannot be done by a HR person.

But planning a successful interview is a real challenge. The interviewer must conclude in a short time if the candidate is suitable or not to the open position. Thus, the time of the interview cannot be wasted on questions that do not really contribute to a decision, or, worse yet, questions that may cause the interviewer to make the wrong decision.

A recent article at TechCrunch claims that the most important thing to consider in the recruiting process is the candidate’s achievements. The author recommends:

“Don’t interview anyone who hasn’t accomplished anything. Ever. Certificates and degrees are not accomplishments; I mean real-world projects with real-world users.”

Similarly, Joel Spolsky says that the ideal candidate must be Smart and Get Things Done. According to Joel:

“The only way you’re going to be able to tell if somebody Gets Things Done is to see if historically they have tended to get things done in the past.”

I agree with these views, and I always start my interviews with a question about the candidate’s previous professional experience. I ask the candidate to select one of the projects he has participated in the past, and then describe me its requirements, high-level design and some implementation details. If the project is too big or complex, I may ask the candidate to talk about a particular module, or about a particular aspect, such as scalability or robustness.

In any case, if the candidate really contributed to this project and knows what he is talking about, this first question is just the opening for many interesting ones:

• What was the biggest challenge in this project?
• Did this project have any conflicting requirements?
• What were the trade-offs you had to consider in your design decisions?
• What were the non-functional requirements and how they affected the design?
• What were the design patterns that you used in this project?

Thus, by talking about the candidate’s previous projects, we can learn a lot about his real skills and experience. In my opinion, this is much more valuable than discussing generic questions about software engineering or asking the candidate to solve logic puzzles.

But we must pay attention not only to what the candidate says, we must observe how he talks about his experience:

• Does the candidate talk with enthusiasm?
• Is he proud of his previous work?

Ideally, the candidate should be so enthusiastic when talking about his contributions to past projects that he should forget that he is in an interview. He shouldn’t feel he is in a kind of exam, but that he is talking to a fellow developer, enjoying the opportunity to describe all the smart things that he did and that he is proud of.

As I said in a previous post, I believe there is nothing more effective than enthusiasm. So we want to hire someone who is smart and gets things done, but with enthusiasm. Achievements alone are not valuable if the candidate is not proud of his achievements.

Good luck hiring the best people; to find them you don’t need more than a single question.