Fog Creek

6. Hire or No Hire?


When it comes to making the hiring decision, hear why we think there should be no Ifs, Buts or Maybes.


We know we’re going to have some false negatives, we’re going to ding people when in fact they may have been great. But we err on the side of that versus being too easy and possibly hiring people who are not good enough. And that’s far worse than losing a good candidate because if you do hire somebody that is not going to be good enough, then it’s hard to fire them later on, you know you have to go and clean up after them in the codebase, or whatever responsibilities they are given. They’re going to go and not do a good enough job and you’re going to have to spend someone else’s time trying to fix these things and sort of, they become a liability, which is bad.

If they’re a weak hire lets just not hire them, ok. If they’re a weak no-hire, a strong no-hire, it doesn’t even matter – we’re not going to hire them. So the only two possible answers are hire, no-hire. Sometimes you get people who want to say maybe, or I don’t know, and we don’t allow that. If you’re about to say maybe, just say no-hire because why bother. The basic rule is, it’s much, much easier to interview ten people and find somebody good than it is to hire ten people and have to fire nine of them. In other words, the cost of interviewing is much lower than the cost of trying to get rid of someone that you hired by mistake.

We have to reject a lot of good candidates, just because we weren’t absolutely certain that they were good. But that’s a small price to pay, rather than the price of having a whole bunch of people messing up your code. It’s just not worth it.