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?

Comments

Interviewing Programmers 101

[wackybrit]

The original posters questions and theories are a little weak. Testing a programmer's skills in constructing algorithms for random scenarios is a great idea.. if they need to use lots of algorithms.

The key to interviewing is to scope out the person's general work ethic, overall personality, and how well the person can do the job they have applied for. That's it!

In previous Slashdot threads we have learned that it's not wise to sit programmers down with a pen and paper and get them to write C code on the fly! Yet... the interview techniques you are mentioning are a lot like that.

Getting people to 'think on their feet' is good, if you're just talking concepts and ideas, but don't expect people to get things 100% right sitting at an interview table. These guys are programmers, not TV evangelists with all of the answers at the tip of a hat.

From the sound of your post it seems like you have interviewed people, found them to be great at algorithms and answering your questions, but then have found their work ethic stinks or that they're not as ingenious as you thought they were. That's because you assume that someone who can answer questions quickly and proficiently is a good programmer. Wrong!

Instead, look out for programmers who list extra-cirrucular projects on their resume. Look for programmers who have worked on their own projects, and can demonstrate them for you. Would you rather employ someone who coded a great deal of Gecko, or some gimp who can answer your algorithm questions?

Look for people who don't need incentives to work, but those who will program whether they get paid or not! Those are the people who will stick with you, and aren't just learning new languages to make a quick buck.