[…] I can tell you from extensive experience that if you spend less than one hour on an interview you’re not going to be able to make a decision.

You’re going to see three types of people in your interviews.

• At one end of the scale, there are the unwashed masses, lacking even the most basic skills for this job. They are easy to ferret out and eliminate, often just by asking two or three quick questions.
• At the other extreme you’ve got your brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Nintendo DS.
• And in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something.

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.

That means you can technically end the "day" of interviews after the first two if the candidate is not going to be hired, which is not a bad idea, but to avoid cruelty you may not want to tell the candidate in advance how many people will be interviewing them.

If even two of the six interviewers thinks that a person is not worth hiring, don’t hire them.

[…]

I have heard of companies that allow any interviewer to reject a candidate. This strikes me as a little bit too aggressive; I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn’t like them.

[…] Even if you have a candidate that would be brilliant at doing your particular task, but wouldn’t be very good in another team, that’s a No Hire.

In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them.

If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire.

You’ll solve some short term pain in exchange for a lot of long term pain.

This is a topic I was willing to write, how modern "sofware developers" has a small vision and remain in their "sector"/subarea for his whole career. The shame of a:

• Eternal front-end
• Stagnant with a old stack
• Windows user
• Backend engineer that doesn't understands neither HTML generation (this might not be a real blocker. however the opposite is)

Never say "Maybe, I can’t tell.” If you can’t tell, that means No Hire. It’s really easier than you’d think. Can’t tell? Just say no! If you are on the fence, that means No Hire. Never say, "Well, Hire, I guess, but I’m a little bit concerned about…" That’s a No Hire as well. Mechanically translate all the waffling to "no" and you’ll be all right.

Why am I so hardnosed about this? It’s because it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people’s time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it.

In some situations it may be completely impossible to fire anyone. Bad employees demoralize the good employees. And they might be bad programmers but really nice people or maybe they really need this job, so you can’t bear to fire them, or you can’t fire them without pissing everybody off, or whatever. It’s just a bad scene.

True, already suffered from this evil. The emotional bound with the "good guy that doesn't delivers" is tying and demoralizing for the team: In daily work and in firing.

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.

Golden rule, wish I had this tough conviction earlier.

[…] The other way to identify these people is that they have a tendency to show up at your office, coffee mug in hand, and try to start a long conversation about the relative merits of Java introspection vs. COM type libraries, on the day you are trying to ship a beta.

They are the kind of people who decide to refactor your core algorithms to use the Visitor Pattern, which they just read about the night before, and completely misunderstood […]