Hacker News Reader

Comment by geebee | Hacker News Reader

Having tried to recruit for an unsexy university staff job, I will agree that it is tough to find developers. But having been through the interview process at amazon and other "top" tech companies, it is clear that they acct (by their own admission) a high number of false negatives.

I understand why - a bad dev can really wreak havoc. But theymve gone so far, they seem like a man claiming to starve who turns his nose up at an apple with a small bruise. It feels a little insincere.

I won't hire if there's a big red flag, but I'll. Give a candidate a chance. Maybe top companies with more pull don't have to, but then how seriously should I take these stories of how hard it is to hire.

View on HN

"they seem like a man claiming to starve who turns his nose up at an apple with a small bruise. It feels a little insincere"

Agreed, but I am not sure it's just these companies. My general feel of the market in Europe is: if you're looking for an experienced hire, you're not willing to train them. It feels like solid experience in a semi-related area is not enough to get the jobs in the current environment, exact experience is asked for. So small "skill bubbles" exist, with only the most desperate or broad minded taking a risk on someone without 80% experience already.

I call B.S. on most of these articles, and most of them are perpetuated by the people with the absolute most to gain: recruiters.

I couldn't agree with you more. My thoughts exactly.

There is simply no-such-thing as job training now. Even related experience often does not cut it. Companies expect to hire people with exact experience.

I've worked on teams with that attitude - and a _single_ mis-hire created large problems. Sure, you can fire people, but

a) Once you hired somebody, you already spent a lot of money on them

b) It affects team morale. No matter what skills people have, team mates still form personal attachments. Seeing somebody go is hard.

c) Firing means HR and legal need to spend a lot of time to make sure this is handled properly. So, more cost.

So, I'd rather have false negatives than false positives overall.

I think not firing someone is a much bigger hit on team morale. If someone is either doing something that affects everyone badly/not doing what they're supposed to do (causing other people to do their work), why keep them? Firing is a temporary downer; keeping someone on staff who shouldn't be there is a long-term one. If your team is great and they care (which I think all great teams do) you owe it to them to replace that person with someone who is on the same level.

Well, yes - I'm just talking about the cost of a wrong hire. Sure, if you have a bad apple, get rid of it. But it's better to ignore a few good apples if that means you reduce the likelihood you get a bad one.

Talking with friends at Google, the perception there is that the cost of a false negative is larger than the cost of a false positive. The catch is that you need to have an agile hiring process, AND actually let go of people who don't carry their weight. Most companies fail at both points especially the second, until hard times come and investors demand rolling heads.

I agree with everything you have said. A hiring manager has every right to be as choosy as he or she chooses. I've read plenty of blogs that talk about how rigorous the hiring process is at company x, how good you have to be to get hired, and how they pass on candidates that would probably be good employees because the damage of a false positive is so much higher than a false negative. All a-ok in my book.

The part that irritates me is when these companies start talking about the serious problem of a shortage of developers. I feel that if you want to throw out many people who would have been good employees, you should accept the consequences - that hiring will be very hard and you will face a shortage of your own making.

The point is, even if you desperately need people (i.e. a shortage), you are still better off avoiding false positives.

Reply on news.ycombinator.com