How Should You Interview a Programmer?

phamlen asks: "Having hired several programmers who haven't worked out, I'm wondering if other people have better success with interviewing techniques. Usually we have a two 'technical interviews' and a final interview. The technical interviews tend to be a combination of specific technical questions ('Is friendship inherited? How would you find out?') and algorithmic ('Given the numbers from 1-10 missing one number, how do you find the missing number?'). In addition, we essentially try to interview for: intelligence/performance. technical skills (algorithmic, etc.), and team compatibility. Unfortunately, we've been burned a couple of times by people whose performance didn't measure up to what we expected from the interviews. So I'm wondering if other people wanted to share their interviewing tricks - how do you find out if someone is a good programmer?" Surprisingly enough, we've done a series of these, so if you are interested in similar questions for sysadmins, network engineers, or the one who will follow in your footsteps, then we've got it covered. We've also covered core IT questions as well. What special ways do you have of evaluating potential coders? How well have they worked out?

Joel's got help

[Arjen]

Joel (of Joel on Software [joelonsoftware.com] fame) has an interesting article [joelonsoftware.com] about interviewing, entitled The Guerrilla Guide to Interviewing. The name is self-explanatory, I guess.

Re:My experiences

[IIRCAFAIKIANAL]

This was a second step...

Here is the order:

1) Introductory interview - they turn on their BS detectors, ask a few standard questions and then call me back later.

2) I show up again, they give me some written tests to take home and some verbal tests on the spot. I bring sample code.

3) They call me back one last time, give me the profile (they hire an outside company to do the tests, btw, they don't perform them). They ask some more questions - more in depth with specific technical questions.

4) They call me and give me the job.

The fact is, they wanted to hire somebody smart. I did not have all of the qualifications (i'm originally a hardware programmer - now I do business apps) but since I was honest and showed my potential, I received the job.

Not freaky, it's called the Horoscope Study

[JUSTONEMORELATTE]

Usually about 2nd-year psyc students learn about the Horoscope Study. The main reason cited by believers of astrology is that the descriptions are stunningly accurate. The trick is, they are stunningly accurate for ANYONE, not just you.

I don't know what survey your employer used, but you spent some effort to complete the survey, expecting that a well-designed system would evaluate some qualitative aspects of you. When presented with results, you subconciously hoped to be:

• described accurately
• described favorably

This subconcious desire on your part made you willing to forgive minor points that didn't fit your desired outcome, and willing to magnify points which did fit the desired outcome.

Again, I don't know what survey you used, and there certainly are valid personality tests out there, but don't get too freaked out when one seems to describe you to a T.

Three questions to ask oneself.

[Mezzrow]

Well, there are many technical questions one can ask to get a handle on a programmer's skill level, but I've always felt that that's only part of the issue. I once worked in a place where, after an interview, each interviewer would answer three questions.

1) Can the person do the job?
- This would be the technical part of the interview. Does the person have the appropriate technical skills to get the job done? Do they have a good, problem-solving mind?

2) Will the person do the job?
- This is as important as number one. You want to get someone motivated to work. Also, if you're hiring someone to do program maintainance, for example, you don't want someone who looks at the job as a three month stepping stone. They need to be excited and ready for the specific task at hand.

3) Am I willing to work with this person while they do the job?
- We all like to think that we can be rational, detached creatures at work, but its important to be able to get along with workmates. It makes work more enjoyable, and workers more productive.

The best hires I've seen, are the ones who receive strong passes on all three questions.

Re:Show me the money....

[Ironica]

I don't think doctors usually see patients for fun after work hours. I do, however, think that doctors talk to their friends and family about medical concerns, and help them see that they're getting appropriate care... except possibly for doctors who are incompetent or really hate their discipline (maybe they only went to med school for the money).

Fact is, while certain factors (such as marital status, religion, age, etc.) cannot by law be considered as factors in hiring, employers in all fields *do* ask about professional association memberships, related volunteer work or internships, and so on. In some fields, if you haven't done any work for free, there's no way in hell you're going to get paid for work (see: Entertainment Industry for further information). The fact that someone has not contributed to any Open Source projects does not mean they are a bad programmer, but those that have probably will be more enthusiastic about their work, and have more easily verifiable skills.

Technical Interviews and other Mistakes

[Malkin]

Technical interviews demonstrate how well someone can handle a technical interview. Exams demonstrate how well someone can take an exam. Neither of these things is that useful.

There are three crucial things you need to find out:

1. Can this person learn quickly and independently? What is far more important than what she knows now is what she is capable of knowing, at some critical moment in the future. Specialists become obsolete when you move on to new technologies, but your fast-learners will be good forever.
   
   
2. Can this person communicate effectively on a technical level? The candidate shouldn't get tongue tied, but you also want to avoid someone who is going to storm out of meetings in a huff, or someone who becomes intolerable when you engage her in discussing her favorite holy war. Some people think that you don't need social skills to be a good programmer. For any environment involving more than one person, these people are wrong.
   
   
3. Does this person enjoy programming? This sounds like fluff, but it isn't. Most people who enjoy programming are addicted to a little high they get with each small success. They learn new things on their own time. Their heads are filled with programming ideas. They may be a little stimulus-hungry (always wanting new, different problems to tackle), but they're always going to have a better intuition for the work than someone who is just going through the motions. The guy who is passionate about programming is going to be the one who pulls your bacon from the fire at the 11th hour, when you think that all hope is lost.