Well, none. We haven't had any false positives since I started (and this is my first full-time job).
Depending on how quickly you catch the mistake, I would stand by my statement or call it an exaggeration. If they're still in training when you catch it, they've probably produced nothing. If it takes longer than that, then they've probably produced something (although if they're contributing enough bugs, it is entirely possible for them to have negative net productivity). But even at best, they're producing less than their salary (why else are you firing them?), so you've lost something.
> This, I feel, is highly dependent on company and codebase.
No arguments here.
> I would like to know what the issues are for a smaller company
From a US perspective, most of the cost is lawyers. It is very easy to say something wrong and end up with a wrongful termination suit, so you end up being very careful, which is expensive in both money and time.
> It seems like the employers and managers here speak of the difficulty in actually getting rid of people, while most of the individual contributors I know are worried about losing their jobs at the drop of a hat.
My experience is that people are worried about being laid off, not fired. Maybe I'm out of the loop, in which case I don't really have an answer to this one.
> if your company is also one of those that complains about how hard it is to find "qualified" people
We're not. We're pretty happy with our current growth rate (recently it's a bit high, if anything).
Maybe this reverses if you're having trouble finding as many people as you want to hire. I would understand accepting more false positives if that's your situation.
> cost of time they're not producing but drawing a salary
How many false positives do you know of who didn't produce anything? What is the actual chance that someone is going to be a net drag if they don't work out? Of course it can happen, but I get the impression from the more paranoid that it is likely or expected. I don't see that.
> eating dev time for training, etc.
This, I feel, is highly dependent on company and codebase. At my previous employer, I worked on real-time radar signal processing code which was very complicated and math-heavy. Someone who did not know what they were doing in that code could have easily cratered the productivity of one or more software or systems engineers. Simpler codebases would not be as bad.
> + cost of firing
Depending on your local laws and corporate structure, I can understand this issue. It takes an act of Congress to get fired from a defense contractor, though they have enough small layoffs to prune the dead wood once in awhile without a full-blown firing. I would like to know what the issues are for a smaller company though, since I really don't know the process. I get mixed signals as well. It seems like the employers and managers here speak of the difficulty in actually getting rid of people, while most of the individual contributors I know are worried about losing their jobs at the drop of a hat.
> Maybe this is from the perspective of a company that has no shortage of applications, but rejecting an applicant that would've been good costs basically nothing (dev time + travel if they got through phone screens).
If your company is finding the people it needs more or less when it needs them, then I understand this view. However, if your company is also one of those that complains about how hard it is to find "qualified" people and how understaffed you are, then your false positives are costing your business far more than that, though the true cost is very difficult to quantify (as is the true cost of a false positive).