False positives are way worse for most companies than false negatives. Interviews processes are generally designed around this principle.
One point that no one seems to consider is that frustrating interview processes are a big contributor to smaller applicant pools; that is, a would-be good employee has applied a couple places, been filtered out by false negatives, and is thus disincentivized from even continuing to look for a better programming job.
Personally, I don't like my current job but am growing frustrated with job hunting. I'm very close to just looking for a bartending job to go along with the part-time valet work that I picked up between jobs, and then maybe doing hobby programming in my spare time for pleasure and profit. I'm serious here: ridiculous interview processes are making the quality of the programmer pool worse by nudging programmers out of it altogether.
Why is it so unreasonable to bring people in on an intern-like trial basis?
We do that, in addition to an interview process biased towards false negatives. We still find it expensive to make hiring mistakes, enough that we are still circumspect about candidates.
Not only does it take a lot to build up someone new, it's emotionally costly to tell them at the end of the evaluation period that they didn't make the grade -- and still give them full support and a real chance the whole way, in case they can turn it around. It does happen; sometimes it just takes time for ambient culture values and priorities to sink in before people "get" what's important to succeed.
It's much harder to do this trial period with option to buy, than for interns who are going back to school, where the expectations and time frame are clear. It also seems that the most capable candidates aren't as interested in being hired on a trial basis, since they have other options willing to commit more fully to them.
These are a few reasons it doesn't work as well as you might hope.
(* note, not talking about google here)
As for why not to try people before you hire them, a lot of experienced people already have jobs. They aren't going to want to accept a "maybe yes, maybe no" position without a really strong incentive.
That said, a number of companies do have policies of liking to hire contractors, then make some of them permanent. This kind of works. But the best contractors they'll find generally are contractors from choice, and so aren't likely to want to make the transition.
I'd rather have the flexibility to move anywhere, the stimulation of constantly meeting new people, and some leftover desire for personal projects when I get home than to have a programming job I don't like.
Our interview process mostly consists of asking you questions you should know the answer to. If your answers make sense and you seem pleasant, welcome to the team. Oh, did I mention you'll probably make twice as much here than at Google?
Incidentally, more people want to work at Google than want to work at Bank of America, even though there is plenty of interesting code to write at the Bank, and plenty of boring paperwork to do at Google. It doesn't make sense to me.
I mostly use Haskell and Perl. The rest of the department is mostly Perl. Sometimes I do C. Other groups are Python-heavy. There is a big Java and C# presence, and of course a lot of people that think C++ is the only real programming language.
There is some initiative to standardize on C++ and Python, but I doubt that is ever actually going to happen.
If you were to get 100 applicants, and you were only interested in hiring the top 5% (5 people), and 3 of the good people decided to accept decent jobs they could get without giving blood samples and their first born, and 20 of the less capable people decided not to bother (Incompetents don't know they are in competent and have less choices), then now you have 2 good people out of 77.
Now what if one of those two is a false negative?
Google is attractive enough that good people go through all the trouble anyway, but is this always true? Since we are able to fire people easily in this country, is a bad hire really so ruinous?
I don't actually know the answer to the question, but I am skeptical of your statement. Maybe the assumptions in my numbers are wrong (they almost certainly are), but what are the real numbers?
I'm sure they knowingly turn away bright & competent engineers simply due to the large size of the applicant pool.
Smaller companies would be wise to heed your advise though.
They understand that their process generates false negatives but they don't want any "crud."
But quizzing on random trivia is irrelevant to the process of eliminating crud. It's quite likely that a cruddy performer will be able to rattle off all known sorting algorithms or all the option flags for GNU grep -- that has absolutely no bearing on true intelligence or any of the other qualities that Google professes to be interested in.
Having some insider's knowledge of Google: the process does not appear to be working. There is a lot of crud in there now, and the crud only seems intent on hiring more crud. Lots of power struggles and posturing; less and less innovative thinking.
This is not just flags to give to a process to make it do something, this is system internals. When I mentioned that I knew FreeBSD fairly well I was asked questions specifically about UFS and the likes.
I never did get asked about flags to grep and other UNIX tools.
Precisely what I mean by unix trivia. What's the difference between /dev/mem and /dev/kmem? I think it's memory vs kernel reserved memory, but in my 16 years as a unix admin I have never once needed to know that. If I did, I'd go look it up. That is why I consider those questions trivial: they're not fundamental, although you can make them sound like they must be.
They've also said that their high false negative rate is why they clear out their records every couple of years. If you got rejected a couple years ago you can apply again and they won't be looking at your previous attempt's performance.
It kind of goes against Google's entire corporate culture to ever delete information like this. Sometimes I wondered if their interview process isn't designed more as a data mining process to find out what interesting things technology leaders are working on.
What Google should do if they want to hire really good candidates is to go with a contract to hire approach. Find good candidates, do one phone interview and a second in-person interview in the space of a few days (not 4 or 5, stretched out over months). If they pass your initial 2 interviews, hire them as a 6 month contractor.
See how much they accomplish in 6 months. If they are contributing and integrating effectively, hire them full time. If not, just wish them the best and don't renew their contract.
This is the way it works in most effective large companies. The cream that rises to the top gets offered a full time job within a 6 month to 2 year timeframe. My current job is like that. I've worked there for 4 years and started as a contractor. It became so expensive to pay my hourly rate that they were begging me to become full time after a while. I was doing a valuable job for them and was very effective at it, so I got the full time offer.