Recent events have placed me in a position where I will be interviewing people for open positions on my team. Not having experience with such a thing, my first reaction was to set the monkey research squad loose on the subject. As usual, they didn't disappoint.
  • The Guerrilla Guide to Interviewing by Joel Spolsky: I think this is the best article I found. All of Spolsky's stuff is great, and his interviewing style is pretty staightforward: He looks for people who are "Smart, and Gets Things Done". One thing to note about a lot of the interviewing advice on the internet is that it's almost all focused on hiring programmers. In my case, though, I'm not looking for something that technical (though there is some coding involved). I'm looking for someone with usability experience (generally not programmers there) and someone who can work with the business group to write a good requirements document for the programmers. However, a lot of interviewing isn't focused on the technical details of coding, and Spolsky has a few gems in his article. Here's one I found useful:
    Part 6: the design question. Ask the candidate to design something. Jabe Blumenthal, the original designer of Excel, liked to ask candidates to design a house. According to Jabe, he's had candidates who would go up to the whiteboard and immediately draw a square. A square! These were immediate No Hires. In design questions, what are you looking for?

    Good candidates will try to get more information out of you about the problem. Who is the house for? As a policy, I will not hire someone who leaps into the design without asking more about who it's for. Often I am so annoyed that I will give them a hard time by interrupting them in the middle and saying, "actually, you forgot to ask this, but this is a house for a family of 48-foot tall blind giraffes."
    There's a lot more to it than just that, but as I'm looking for someone to work with the business group to write a requirements document, it's pretty important that they ask questions and try to get more details. Lots of people like to ask for specific technologies, etc... even though such specifics might not be what they really want. The important thing is to find out what they really want to do, then figure out how to best achieve that goal. I don't know if I'd be as picky about this sort of question as Joel though. I do ask a design question in the interview, but I've only done one interview, and the guy didn't get it. I'll be interested to see if this sort of design quesiton actually does become a good indicator.
  • How to Hire Like a Start-Up by Rob Walling: Not quite as good or thorough as Spolsky's article, but still filled with solid insight on the hiring process from a slightly different perspective. His article focuses on hiring fast. In Joel's article, there is only Hire and No Hire. Rob has an extra category: Maybes:
    ...the Rule of Thirds: on a 10-point scale you make money with your 7s, 8s, and 9s, break even with your 4s, 5s, and 6s, and lose money with your 1s, 2s, and 3s. There are no 10s in that list since no one is perfect; the highest possible rating is a 9+.

    In every job search there are hires, maybes, and no-hires. Using the Rule of Thirds, 7-9 is a hire, 4-6 is a maybe, and 1-3 is a no-hire.

    The only difference between hiring slow and hiring fast is what you do with the maybes; when hiring slow the maybes become nos, when hiring fast you let the maybes proceed to the next round of evaluation.
  • Microsoft Interview Questions: A blog that started as a collection of interview questions asked by Microsoft, but that has lots of general interviewing stuff as well.
  • The New-Boy Network by Malcolm Gladwell: Now that we've got a good handle on how to interview, Gladwell comes along and pulls the rug out from underneath us. Just how valuable are interviews anyway? Gladwell looks at the situation in his usual thorough manner, and claims that interviewing is a lot more difficult than it seems. Most judgements appear to be based on first impressions and the assumption that people's reactions in one context (the interview) are the same as others (working). However, once he establishes that premise, he goes on to talk about "structured interviewing" with an HR expert:
    Menkes moved on to another area--handling stress. A typical question in this area is something like "Tell me about a time when you had to do several things at once. How did you handle the situation? How did you decide what to do first?" Menkes says this is also too easy. "I just had to be very organized," he began again in his mock-sincere singsong. "I had to multitask. I had to prioritize and delegate appropriately. I checked in frequently with my boss." Here's how Menkes rephrased it: "You're in a situation where you have two very important responsibilities that both have a deadline that is impossible to meet. You cannot accomplish both. How do you handle that situation?"

    "Well," I said, "I would look at the two and decide what I was best at, and then go to my boss and say, 'It's better that I do one well than both poorly,' and we'd figure out who else could do the other task."

    Menkes immediately seized on a telling detail in my answer. I was in-terested in what job I would do best. But isn't the key issue what job the company most needed to have done? With that comment, I had revealed some-thing valuable: that in a time of work-related crisis I start from a self-centered consideration.
    Most of the time, we want to believe that we can derive broad trend of behavior from the interview. The structured interviewing process is very narrowly focused:
    What is interesting about the structured interview is how narrow its objectives are. When I interviewed Nolan Myers I was groping for some kind of global sense of who he was; Menkes seemed entirely uninterested in arriving at that same general sense of me--he seemed to realize how foolish that expectation was for an hour-long interview. The structured interview works precisely because it isn't really an interview; it isn't about getting to know someone, in a traditional sense. It's as much concerned with rejecting information as it is with collecting it.
Interesting stuff. As I mentioned, I've not progressed much in the process just yet, but I'll be interested to see how this information plays out.