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.
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.
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)
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.
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?