I picked this book up because of a recommendation from a colleague at work.  We’d been working on developing an interviewer training course.  

First of all, this is a terrible cover.  The cartoon images makes it seem like the contents are lightweight.  Although Spolsky has a very casual writing style, the ideas in the book have real substance.

Many things I agree with:

The great software developers, indeed, the best people in every field, are quite simply never on the market.

If you have any grouchy developers that you just can’t get rid of, at least take them off the interview schedule, and if you have cheerful, social, cruise-director types, make sure they’re on it

The original hiring rule for Fog Creek, stolen from Microsoft, was “Smart, and Gets Things Done.”

We look for evidence that the applicant is passionate about computers and really loves programming.

For someone who is basically a good software developer, learning another programming language is just not going to be a big deal.  In two weeks they’ll be pretty productive.  There is, I think, one exception to this rule.  If you’re hiring and architect or head developer – that is, the chief software engineer who is going to have to lay out the initial code and figure out how things work together – you probably want to hire someone with a lot of experience in the technology that you’re using. … Don’t start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you’re building on.

The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes.  Ever.

Never say, “Hire, but not for my team”

It is much, much better to reject a good candidate than to accept a bad candidate.  Don’t be afraid that you’re going to reject too many people and you won’t be able to find anyone to hire.  During the interview, it’s not your problem.  Of course, it’s important to seek out good candidates. But once you’re actually interviewing someone, pretend that you’ve got 900 more people lined up outside the door.  Don’t lower your standards no matter how hard it seems to find those great candidates.

Before the interview, I read over the candidate’s resume and jot down an interview plan on a scrap of paper.  That’s just a list of questions that I want to ask.

Don’t listen to recruiters. Don’t ask around about the person before you interview them.  And never, ever talk to the other interviewers about the candidate until you’ve both made your decisions independently.

Good candidates are careful to explain things well, at whatever level.

I ask interviewers to write immediate feedback after the interview, either Hire or No Hire, followed by a one or two paragraph justification.  It’s due fifteen minutes after the interview ends.

If you do have to say no to someone, do it quickly and respectfully.  You are, of course, under no obligation to tell people why they’re not the right fit, but you do have to tell them, and you have to do it promptly.  It’s just common decency.

One thing I disagree with:

I generally consider the idea of employee referrals to be one of the weakest sources of new hires.

I don’t know how on earth he could think this. I think he seems to make two mistakes here:

1. Assuming smart developers will refer people who aren’t smart.   But smart developers know other smart developers – and want to work with them.  And who cares if they refer candidates who are a poor fit – that’s what the interview process is for.
2. Assuming referrals get special treatment.  He later says “when a Fog Creek employee suggests someone that might be perfect to work for us, we’ll be willing to skip the initial phone screen, but that’s it.”  Where I work we love employee referrals, but they don’t get to skip the phone screen or any other part of the process.  We don’t even make it public to the interviewers that this was a referral.

On Motivation:

He also briefly talks about motivating employees, and suggests The Identity Management Method:

Summon all the social skills you have to make your employees identify with the goals of the organization, so that they are highly motivated, then you need to give them the information they need to steer in the right direction.

At Bazaarvoice we talk about the same concept in slightly different terms – we talk about setting context.  But it’s basically the same idea.  

Spolsky’s short comments on motivation reminded me that I should re-read Daniel Pink’s “Drive: The Surprising Truth About What Motivates Us”

To Conclude:

Spolsky articulates the “Smart and Get’s Things Done” hiring philosophy pretty well in this book, and gives practical advice on how to go about the business of hiring great people.

Personally, I’m a big fan of this philosophy – I think it’s worthwhile to recruit and retain top programming talent.  However, I worry a little bit that this is a zero sum game playing out amongst the tech firms.  Not every employer of software engineers can fill their ranks with A players.  As an industry we also have to work on attracting talent from elsewhere (e.g. finance), and developing talent.  I’ll leave the question of whether we can turn B players into A players for another time.