The problem is that you don't actually have a clear measure of who you're rejecting. Every company uses a similar argument to support their (very different in every case) interview process. The fact that it allowed you to build a great team does not mean that you could not have built a better team by giving other options as well.
True, I see your point, but you also can't just hand-wave away our results. I've been on many development teams that did not have a strong technical screen like this, and those teams suffered from having some technically weak members (people would would always be breaking the build, would write unmaintainable code, or would just plod along and always need help). Our team of six has none of those problems: every one of us is a strong and disciplined programmer.
The other benefit of the coding exercise is that it might filter out a certain level of impatience. We don't have coders who can't be bothered to follow [insert team process convention here].
Yeah, I can see that. I did not mean to be disrespectful. I actually generally like take-home coding exercises (and used them at my previous company). I'm just arguing testing a bunch of approaches.
