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

My experiences

[IIRCAFAIKIANAL]

When I applied for my current programming job, they gave me a barrage of tests and compiled an aptitude and personality profile of me.

It was really freaky how accurately it described me... the main point was to evaluate me with reference to the type of person that excels at my job (Programmer/Analyst with some support duties)

They also asked for source code I had written and numerous references.

THe problem with an interview is it's too easy to bullshit. You need to go beyond the interview, as my current employers did.

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.

Our interview process

[Darth Maul]

At my company, since we're small, we need to know that new developers will click quickly. We do a technical paper exam (one hour) with some standard programming/algorithm questions. We then do a few riddles and logic puzzles. These are the best way to test raw intelligence, IMHO, since you have to think abstractly and quickly. We then do a few more design questions at a white board to test their skills at high-level design and diagrams.

However, the one thing that is difficult to test but really seems to be the deciding factor of a new hire "working out" or not, is whether or not they have the "passion". One way we try to determine their take on programming (just a job vs. a fun hobby) is to ask them to describe one software project that they have developed on their own time (not on the job or necessarily part of schoolwork). It's amazing how few actually code for fun or just to continue the learning process.

We then ask them what their favorite joke is just to jolt them a bit and see if they have a sense of humor. Most people fail this question, unfortunately ;-).

Beware of complex answers...

[Ironica]

... to simple questions.

People who have "training" but lack skill or experience are desperate to show you what they know. You can ask a very simple question, and they'll throw out names of tools they think might be relevant, and buzz words they've heard. They're unlikely to give you the simplest answer.

I once was asked in an interview for a DSL installation tech job, "if you installed a memory upgrade into a laptop, and upon boot up the new memory wasn't recognized, what would you do next?"

I felt kind of foolish saying "Well, I'd open up the laptop, reseat the memory, and try again." But the interviewer nearly wept... he'd been interviewing people with all kinds of "qualifications" all day, and I was the first person who had given this answer. He told me how everyone else had said "Well, I'd start up Tech Tool..." or "I'd get out a memory tester and..." without even checking that the installation had been done right in the first place.

That, of course, is not a comprehensive method for finding a good person for a job, but it might make your technical questions a little more effective.