This seemed like horrible advice to me. The gist of the article is, "... put them into your team for a day and watch them work. After the day is over get your team together and let them tell you if you should hire this person or not."

I won't even bother listing all the possible shortcomings - it's a great water cooler idea but it won't fly in the real world.

* Person comes in, doesn't work out, and then goes to work for a competitor and can now (a) talk about your processes, (b) tell them who the key people are to target

* Person comes in and tells technical recruiters who your top talent is

* Person comes in, explains (good/bad) reasons that this code sucks and whoever wrote it was wrong, and makes everyone feel like a fool for working there

* Developers A, B, and C love the guy yet manager hates him (or vice versa)

Interesting idea in practice but I seriously doubt any company does this instead of the traditional techniques he mentions. The "traditional" techniques have evolved over 100 years of working with and interviewing engineers and software folks - there's a reason those techniques are still used in 2009.