Interestingly, the simplest conclusion would be that everyone is good, most of the time. So if we throw hiring out the windows and pick employee randomly, we might still get to the same result.
Which actually isn't too outrageous, since if we have 10% unemployment, wouldn't it mean 90% of people (or more, actually) have to be value added?
You might be right that randomly picking candidates might be just as efficient, but I can't imagine anyone taking that risk.
The test seemingly has to be 0.1% effective, to pay for itself. The thing that's hard to imagine is that the test is even less than 0.1% effective, because it's a scam. This is also how things are sold like a $5 extended warranty for a flash drive.
Do you know what's even more expensive than a bad hire? It's letting an extraordinary hire go away because your snake-oil test did not work. But that loss won't make onto a spreadsheet, then, who cares?
Could you actually quantify these costs a good agency will ofter refunds if a candidate is let go shortly after hiring.
Could the on boarding process be more akin to a mentor-apprentice relationship and utilize open source as the avenue, with the burden of work placed on the apprentice. Your company has both closed and open source projects that many of your engineer's contribute to and manage. An apprentice level candidate works on and applies a patch with the feedback from the mentor level engineers. At some sufficient level of acceptance based on performance the apprentice is brought in for a culture fit type interview and potentially offered a position.
From the view of the apprentice this may seem like MORE work then writing resumes and prepping for technical interviews. But from my point of view as an apprentice I'd be learning skills that seem more useful than gaming resumes, screening and technical interviews, and adding to my portfolio that may never get glanced at. Skills like communication and coordination with a team, Real world coding experience and pushing to production. From the viewpoint of the mentor, I see candidates that have already been introduced to the internal workflow and show the communication necessary to work with my engineering team.
That's a load of highly-enriched equine fertilizer. I have had this discussion here before. I asked for information. I didn't get much. Some worst-case hypotheticals that, to my knowledge, have never happened anywhere. A buttload of management failures surrounding bad hires where management was responsible for the vast majority of the costs, not the hire. A couple legitimate bad hires where the costs were significant, but not in the same ballpark as people like you parrot.
Also ignored in this conversation: what is the cost of keeping your req open? How much money are you losing, directly or indirectly, by not having someone in that role? Why do you think someone can't grow into the role?
The bottom line is that "slow to hire and fast to fire" as difficult as it is, is very sound advice!
Without knowing you and jumping to a conclusion based on your comment, I assume you don't appreciate that employee boss relationships are adversarial by nature and there is often considerations management makes that might seem bad but are really a product of their understanding of whats possible and realistic within limiting circumstances...
I used to complain with my friends about all the things we would change in our boss and the company we worked for and now after many years I realize that at the time I had no flipping clue about anything.
It is hard to pull wool over someone's eyes for 3 months especially in a results oriented field like programming.