I've had a different experience on the hiring side of the table. The coding exercise that we provide as part of the interview has been very successful in surfacing the skill and talent of the programmer. By using that screening device, we have assembled a team of very sharp programmers. It's totally worth filtering out people who choose not to spend the time. Even though we end up losing some potential candidates, it's worth it for a 0% chance of a mishire for technical reasons.
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.
We're currently hiring and for the first time, we should have started doing this years ago, given a simple coding exercise.
I estimate it would/should take any programmer/problem solver no more than 15, maybe 20, minutes to come up with the solution if they have experience in the language we request they solve it in. The exercise doesn't require specific domain knowledge but should quickly assess whether a programmer, particularly with experience in a different language, is able to learn and apply the syntax and semantics of another language. If they are completely unfamiliar with the language then maybe an hour. They can use whatever references they want. We will check for complete copy/pasted code and alter the requirements and/or test data over time.
The other great benefit is we get to see what/if/how they ask questions to clarify the problem and solution.
EDIT: This exercise is geared towards fresh graduates or developers that don't have experience in the language we use. Can it be gamed? Yes. Might some people not bother? Yes. Are we okay with that? Yes.
See a simple one like that where if I need to spend time researching the question will only take up to an hour is one thing.
But the last one I got from one of the video game engine companies required building a full crud app with live db, documented api, and multiple feature sets. all for a front end job. Some places just take it too far and sour the idea.
Our exercise can't be cheated on because we discuss it with the candidate during the in-person interview and even ask them to change the code in a simple way.
Also, the exercise is designed to be original and so a solution can't be Googled.
We're talking only about the "in their own time" take-home types of tests. The type of cheating I'm talking about is outsourcing the problem or even just having a friend do it for them.
