Joel recently posted “The Guerrilla Guide to Interviewing” on his site, and it describes almost perfectly the whys and wherefores of my own interview process. This isn’t too surprising, since Joel and I both started at Microsoft a few years apart and in teams that were not so distant, so we probably both got very similar kinds of indoctrination. I don’t follow every point that he outlines, but it’s pretty close.

I’d have to say that even after eleven years at Microsoft one of the hardest, hardest, hardest things to do is follow his dictum to Make A Decision. Most people at Microsoft are generally nice people who want people to feel good about themselves, so even at a company renowned for its hard-headed competitiveness people are sometimes very reluctant to say “no hire” about someone if they managed to seem not totally unqualified. Case in point, at the beginning of the summer we did a round of interviews for summer interns, and one of the interviewees was a very nice guy who seemed pretty smart but wasn’t so strong that he just jumped out as an obvious intern hire. For various reasons I had to call the recruiter before I had the chance to write up feedback in email and they asked, “So, is it hire or no hire?” And my immediate reply? “Well, I think he’s kind of a weak ‘hire’.” The recruiter was good enough to shoot back, “What does that mean?” and I came to my senses and said “Oh, yeah, right. Sorry. He’s a no hire.” As they say about pregnancy, you can’t hire somebody “just a little bit.” Either they’re working for you or they’re not. There’s no in-between.

Any time I start to get mushy on this point, I just remind myself of an experience I had a long time ago, back when I had done only a few interviews and was very insecure about making hire/no hire calls. My group at the time was interviewing for a position that had opened up on our team, and we interviewed this guy I’ll call Fred. Fred’s resume looked good, with lots of relevant experience. He sailed through the coding question, no problem. However, during the interview something nagged at me about him, something that was just not right, something that made me doubt that he was going to be a good hire for the team. Being young and insecure, I overrode my concerns and gave him a ‘hire’ recommendation. Everyone else on the team who interviewed him gave him a similar recommendation, and he was hired.

As it turns out, Fred was a disaster. I realized later that my nagging doubts had probably been caused by some subtle negativity on his part towards his current management during the interview. Once he was on the team, this subtle negativity blossomed into a full-blown bad attitude towards authority in general. As far as I could tell, Fred didn’t really give a crap what other people thought he should be doing or how they felt about what he was doing. As you might imagine, this made the quality of his work wildly uneven and also made him a generally unpleasant person to work with a lot of the time. Somehow this had worked out OK on his previous team, but it didn’t fly so well on my more functional team. Fred’s tenure with the team was not that long, thankfully, and after he left the team most of his code ended up being tossed out of the product and completely rewritten (much of it by me).

In the end, no permanent damage was done, but it was a very valuable learning experience for me personally. The experience taught me that the most important thing you can do in an interview is Trust Your Instinct. Had I listened to my instinct, I could have perhaps questioned Fred more closely about his views on management. Or I could have raised red flags that later interviewers could have honed in on. But I didn’t, and I (and the rest of the team) ended up paying the price. So now when I interview people, I look at the resume, I look at the coding question, I look at all the other factors Joel outlines, and then I do a gut check: is this someone I can see working closely with for the next three years? If they fail the gut check, that’s usually a pretty good indicator of a “no hire” recommendation.

Joel’s foreward to Rich Chapman’s book In Search of Stupidity resonates with me because it’s what I’ve always said about Microsoft: it’s not that we’ve been so much smarter than our rivals over the years, just merely that we’ve been less stupid. Joel says that the worst mistake Microsoft’s made has been the dancing paperclip, but that’s not really true. I can think of a legion of boneheaded, wrongheaded and just plain dumb things that Microsoft has done, large and small, since I first came to work here. Microsoft Bob jumps to mind. Or the first, oh, I don’t know, five years of MSN’s life. Or the Tiger media server – we must have dumped a lot of moolah down that black hole. And for all the public failures that we’ve had, there are plenty of internal screwups that never make it to light.

One thing I think that has made more difference than anything else was the fact that Microsoft tends to be pretty dogged about following the old maxim “if at first you don’t succeed…” Plenty of eventual success stories at Microsoft started off life as fiascoes, but we kept plugging away at them until we made them work. Through the years, I’ve been amazed at the way that major competitors who could really give us a fight in some area seem to lose interest once we start to do well against them. (OS/2 springs to mind.) I sometimes wonder if Bill knows the secrets of the Jedi… “This is not the market you are looking for. We can go about our business. Move along.”