chief among them is the high cost of hiring the wrong person, or missing out on the right one.
As a hiring manager, I've never cargo culted this particular view. In fact I think it's completely misguided. I always work in at-will states, it's trivially easy to let someone go. I also personally have no problem doing it.
I generally will hire based on conversation alone (no coding tests). If you ask someone detailed questions about work a candidate has done you can get a really good idea if they know what they're talking about. I know people say that they've interviewed people that can talk a good game but can't code a for loop once in the door, but I've interviewed hundreds of people and I can't say this is often the case.
Easy in, easy out. You know what though? There's very rarely ever the out part. If I can look at your Github, like what I see and you can back that up in a conversation, you're hired. That has worked out really well for me and reduces a lot of friction and wasted time (mine and other engineers') during the hiring process.
The moral of my story is that just because Google or some other tech giant espouses a theory like "false positives are way more costly than false negatives", it doesn't mean it works for all organizations or that it's even true at all.
I've worked at places where the managers hem and haw over firing someone even going so far as to use passive-aggression to make them leave on their own. In environments like that, the cost of hiring the wrong person is huge. It could take a couple of quarters to shake the dead weight and the entire team suffers.
I've also worked with managers who have no problem being the hatchet man and it's great. They sniff out the losers, put them on a plan, and they're either out the door soon after or stick around to get fired.
I would rather managers teach each other to wield the hatchet than try to get seven steps ahead of a dud hire during the interview process. "Release early, release often."
I totally agree. I think so much of the "it's really hard to get rid of bad people" story comes from weak management. Firing people is part of the job, you need to be comfortable doing it.
Interviewing people is extremely disruptive to an engineer's time and in a large company it could potentially happen a lot. I think that is the metric that should be optimized for, not minimizing firing work for the hiring manager.
I wonder about this - am I doing a candidate a disservice by hiring them without knowing that there is a non-trivial chance that they'll be fired within 1-2 months? If someone doesn't already have a job, that's fine, but someone might quit a situation where they are suited for one in which they aren't. Or, if someone is a junior developer, they've just spent 2 months before being let go, and has to explain the situation to the next place.
I care about the people I hire as humans and don't want to put them in a bad situation.
I wouldn't say there's a non-trivial chance that they'll be fired in 1-2 months. Being able to effectively screen people is another technical managerial skill. There is a very, very small percentage of candidates that make it through the interview and later turn out to be duds.
I think there are two issues at play:
1. Ineffective managers are terrified of firing people.
2. Ineffective managers rightly or wrongly think they can't screen people without code tests, white boarding...
Like I said in my original comment I look at their Github or any other work portfolio they provide and have a deep discussion about it with them.
What about the impact on the person for the false positive? Taking a new position can be hugely disruptive for someone, so making sure they are a fit (both directions) seems like the respectful thing to do.
Like I said, it rarely actually happens but when it does it's because the person really was incompetent (I don't worry too much about "culture fit" and other vaporous qualities).
As a manager, it's my responsibility to do what's best for the business.
It's not about being cold blooded. It's a function of the job and what's best for the team. Better to get them out early than let them bring everyone down then let them go.
I don't disagree with your rationale. I once saw the statement that in order for a company to succeed, they either have to figure out how to hire well or how to fire well. If you do one well enough, you don't have to worry as much about optimizing the other. Most companies just prefer to focus more on hiring well because firing people is unpleasant.
If someone can't perform the job, the only option is to let them go. As I said in my original post, it rarely happens because it's actually not that difficult to vet someone without forcing them to write tons of code.
In order of importance a manager should put the company first, then team, then individual employees, then themselves. Poor performers hurt everyone on that list.
If you hire someone who is currently employed and then fire them, you are doing very real damage to their finances and career. Empathy for employees is a valid reason to err on the side of avoiding bad hires over easy in/easy out.
I disagree. By optimizing to protect poor performers, you jeopardize all employees. It's more important that the company succeed and that people who are good at their job get to work unencumbered.
Have you ever been a manager? Again, it's not being cold blooded, it's one of the main responsibilities of the job. Being a leader isn't easy and you often have to make tough decisions and sacrifice in the name of the team. This has been well known throughout the history of leadership.
It shouldn't be looked at that way and it's not black and white. Ideally they're treated like people, not cogs, and the manager and company does what it can to either get the person the skills they need to succeed, move them to a role they can succeed in, or give them a path out in a reasonable amount of time.
Most of the time the under-performer will be happier after any of these scenarios than they would knowing they're under-performing in their current role. It just takes a bit of time and maturity to realize.
It sounds like you're working in some specific (and enviable) circumstance where people can get productive right away, and where job success is fully defined by meeting your expectations. False positives get more expensive when there is training or provisioning effort required to get someone onboarded, or when you expect your teams to satisfy multiple stakeholders or to grow beyond initial job requirements.
When you start working with someone day to day you can very quickly find out if they are good or not. You don't have to fully get them up to speed and have them learn all of the domain knowledge of your company. Start small and evaluate quickly. Certainly you can learn more when they start working than you can in the interview process.
> when you expect your teams to satisfy multiple stakeholders or to grow beyond initial job requirements
Those people should of course be part of the interview process if the developer will be interacting with them. I don't see how that makes a bad hire any more expensive though. Maybe I'm misunderstanding what you're trying to say.
I've offered to give many interviewers access to my private github repos so they could review my code and see how I've worked. I have ~5 relatively large projects, full tested, where I was the sole, full-stack dev. 1 out of 20+ took me up on the offer and I work there now.
So true. This argument is simply bullshit in the US. It's just another justification for ridiculous hiring tests and other stupidity that weeds out a lot of good candidates. You can hire someone today and fire them next week. It happens all the time and there isn't a high cost other than the compensation for a week. You can, although a really shitty move, even delay someone's benefits for a few weeks or even months while they go through a trial period, often known as probation. It's shitty, but if costs are that important, it can be easily done. If you can't tell if a candidate is good after a few weeks or months of them working with you, that is a problem with your company not the candidate.
As a hiring manager, I've never cargo culted this particular view. In fact I think it's completely misguided. I always work in at-will states, it's trivially easy to let someone go. I also personally have no problem doing it.
I generally will hire based on conversation alone (no coding tests). If you ask someone detailed questions about work a candidate has done you can get a really good idea if they know what they're talking about. I know people say that they've interviewed people that can talk a good game but can't code a for loop once in the door, but I've interviewed hundreds of people and I can't say this is often the case.
Easy in, easy out. You know what though? There's very rarely ever the out part. If I can look at your Github, like what I see and you can back that up in a conversation, you're hired. That has worked out really well for me and reduces a lot of friction and wasted time (mine and other engineers') during the hiring process.
The moral of my story is that just because Google or some other tech giant espouses a theory like "false positives are way more costly than false negatives", it doesn't mean it works for all organizations or that it's even true at all.