As part of my consulting work, I do technical interviews, both for my consulting company, and sometimes for clients as well. This is fairly new to me, but I've jumped in with both feet and like everything I do with my job, I've tried to read up as much as I can in order to get as much good information and do the best job possible. I take interviews very seriously, and have always seen them as an important step in the hiring process. That's why I found this particular tidbit from a recent Megan McArdle post to be quite troubling:
There's a rich body of literature suggesting that job interviews are actually counterproductive. You are much better off hiring people (or not) based on their resume and/or body of work. Interviewing actually reduces your chances of hiring a satisfactory candidate.
This hit me hard to be honest. Has what I've been doing for the last several months to vet candidates been a waste? My gut reaction is of course to say no, but I think she brings up an important point, which I've read many places. Most people who interview don't do a great job at it, because they let the interviewee do most of the talking. If you let the person being interviewed do most of the talking, of course you won't find out anything. They've practiced their schpeel over and over again, and have it down pat, or at least they should. As a result you might hire somebody who is all fluff and no substance. Worse yet, you can miss out on a great person who has deep knowledge, but is very nervous and not a good speaker, or is introverted, and therefore doesn't know how to sell themselves.
One of the posts from Coding Horror that I found to be incredibly useful was this one on getting a phone screen right. The gist of the post is that you, the interviewer, should drive the interview. The interview should be technical, and very specific. Ask them to define common terminology, describe a sample architecture for some made up problem, or how they would approach solving a problem. Interrupt the candidate often with questions regarding how they did something specifically, or why they chose one method over another.
The problem for technical people is that we usually don't have a portfolio we can share! When a programmer leaves a job, they generally can't bring the source code they wrote with them and show it to a perspective employer as a sample of their work. Megan has the advantage of working in a field where she can do just that. She can take articles she's written for other publications and show them to someone else as an example of the quality of her work. In the technical world, the resume can be pretty useless. They may accurately describe projects that they've been part of, but may exaggerate their part in creating that project. And just because you helped write a piece of software that is in production today... was it written well, with good architectural and object oriented design techniques and is it maintainable? Or was it certified as "Works on My Machine"?
In our profession, its also easy to get roped into the "years of experience myth". Technology changes so quickly that a great portfolio of projects in one technology doesn't show whether or not you can, or are willing to, learn the next great technology that your company wants to employ. In fact, I've often found that the best candidates in highly technical positions are the youngest candidates, because they still remember how to learn, and are passionate about it. The older people get, the more settled into their ways they become, and the more likely they are to pigeon hole themselves into static methodologies. That's why I always ask people what blogs they read, magazines they subscribe to, and what, if any, user's groups they are active in. That is a huge indicator as to how passionate about learning technology someone is. One of the best people I've seen hired recently was in his 50's. Software development for him was a second career, and he took it up with a fierce passion. So you shouldn't simply look at age either.
In short, if you don't think that interviewing is worthwhile, then it probably means that you're simply running down a person's resume, and letting them talk about where they've worked. That is not how to do an interview.