Interesting article.
For a while, we had a non-typical interview strategy: A take-home project. We would give the candidate a week or so to work on a smallish project, the requirements of which we would specify. After they completed the project, we would do a group walkthrough with them.
We've hired five engineers over the last three years. For the first two, we did the take-home project. But, then I started to wonder a bit about if it was reasonable to ask programmers to work a weekend on a project. There were a bunch of persuasive comments in HN threads on the subject saying it was unfair -- a job seeker would have to spend an incredible amount of time on each application. And one candidate that I really liked aborted the interview process once I told him about the take-home test.
So I changed the process to something much more typical, with live, in-person coding exercises. We hired three more engineers under this system.
So, how did they compare? Well, the engineers hired when we were doing take home projects have worked out INCREDIBLY well. They are independent and very resourceful. They are excellent.
The engineers hired under the more typical system have not done well at all. We had to let go of two of them, after months of coaching, and the third isn't doing that well.
Random chance plays a huge role here, I'm sure. Maybe we just got lucky with the take-home project engineers. But personally, I think it makes a lot more sense to have the interview process match the work. /shrug