How to Interview a Programmer is a link that’s making the rounds. It’s of interest to me because hiring and getting hired is a huge part of a programmer’s career. If I’m going to work with someone, I always want to be part of the interview process so that I can make sure we don’t wind up with someone that will be challenging to work with due to lack of skills or personality fit. Besides, I’m egotistical to think that I do a good job at interviewing, and often assume that other people will screw it up. I was pleased to see that my interviewing technique was described almost perfectly by one of the roundtable participants:
Chuck Allison: I talk to them. I get a feel for them. I always ask about what they’ve done. I have found that by discovering what a person is excited about technically, you can learn a lot of important things about them. In the past I’ve asked people to describe a project that was especially interesting to them, or that was challenging and successful. On occasion I’ve asked what they’ve done that they’re the most proud of. This usually reveals the depth of one’s understanding and mastery. It also gets them to turn on the fire hose verbally, and you can sit back and get most of the answers you need.
He gets right at what I go for. I want to know what the applicant is passionate about. If they aren’t passionate about writing good software, then they probably won’t get the job. I’m sure there are plenty of people out there who just do the computer thing for the money that do a good job, but I take a pass on them. The odds are just so much lower that you’ll get someone good going that route than if you go with the person that can’t imagine themselves doing anything else.
Another thing I’ve resolved to do in the future is always ask people to bring code to interviews. I’ve seen too much nightmare inducing code produced by people who I would have guessed to be good developers to skip this step. I want to see a coding standard, internal consistency in design, and an acceptable level of attention to detail in a person’s code.
How to Interview a Programmer
How to Interview a Programmer is a link that’s making the rounds. It’s of interest to me because hiring and getting hired is a huge part of a programmer’s career. If I’m going to work with someone, I always want to be part of the interview process so that I can make sure we don’t wind up with someone that will be challenging to work with due to lack of skills or personality fit. Besides, I’m egotistical to think that I do a good job at interviewing, and often assume that other people will screw it up. I was pleased to see that my interviewing technique was described almost perfectly by one of the roundtable participants:
He gets right at what I go for. I want to know what the applicant is passionate about. If they aren’t passionate about writing good software, then they probably won’t get the job. I’m sure there are plenty of people out there who just do the computer thing for the money that do a good job, but I take a pass on them. The odds are just so much lower that you’ll get someone good going that route than if you go with the person that can’t imagine themselves doing anything else.
Another thing I’ve resolved to do in the future is always ask people to bring code to interviews. I’ve seen too much nightmare inducing code produced by people who I would have guessed to be good developers to skip this step. I want to see a coding standard, internal consistency in design, and an acceptable level of attention to detail in a person’s code.
Commentary
interviewing
Previous post
IDE Mini-rantNext post
Readers come first