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."
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 care about the people I hire as humans and don't want to put them in a bad situation.
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.
As a manager, it's my responsibility to do what's best for the business.
Most managers are not as cold-blooded as you are claiming to be.
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.
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.
> when you expect your teams to satisfy multiple stakeholders or to grow beyond initial job requirements
This honestly sounds like bad management.
I can't figure out if your devs just don't do that, or if you think you can speak for everyone's standards after one conversation with a candidate.
>> If I can look at your Github, like what I see and you can back that up in a conversation, you're hired.
Wish more hiring managers followed this line of thinking
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.