I understand the appeal of having candidates write code as part of the application process, but in my view it's useless and worse, it will drive off some of the best potential candidates you could get.
First, why is it useless? Because it is an artificial and contrived exercise and not real work. Even if you design your requirements to mimic your real work environment, there's something key missing; the candidate has no knowledge of your team and your environment. How I would write code for my current team vs. how I would write code at any other job I've been at is different. You're basically asking the candidate to take a guess at what kind of paradigms your code reviewers like and what they don't like and hope it works out. One team might find use of closures smart and great, and another might find it unintuitive and adding unnecessary complexity. Your applicants have no way of knowing and just have to hope they write code your team likes.
On top of that, one contrived exercise is not a good way to get an idea of a persons' actual skill and knowledge. I'd much rather have a 30-90 minute conversation with someone where nobody writes any code than to review a contrived example. I get the appeal of the programming task, it can be done asynchronously and thus doesn't require any developer time until you go to do the review. But is it really saving you much time? Anyone who's code doesn't pass unit tests or any other automated level of screening wouldn't probably make it very far into a conversation either.
If I have an applicant spend 1-4 hours writing a code example I've had them use at least as much and probably more of their time for far less benefit than if I had simply called them up on Skype and talked to them about programming. The conversation will reveal not only a lot more to me about their actual skill set, but also their personality and how they might fit into my team. Now I realize teams doing exercises aren't skipping the conversation step, but I'm advocating for skipping the programming task step and going right to the conversation if someone's resume is solid and they can intelligently answer some basic questions (a handful of questions that should take no more than a couple minutes to answer, not an essay.)
Second, why would I say it drives off good candidates? Because I know a lot of really good developers (including myself) who skip any job posting that requires writing code as part of the application process. Why do I do that? Because it tells me the team behind this application is immature. They haven't yet gotten to the point in their careers where they realize these exercises are a waste of everyone's time. That means there's probably going to be a lot of other young dude bullshit in the team that I'm not interested in dealing with.
First, why is it useless? Because it is an artificial and contrived exercise and not real work. Even if you design your requirements to mimic your real work environment, there's something key missing; the candidate has no knowledge of your team and your environment. How I would write code for my current team vs. how I would write code at any other job I've been at is different. You're basically asking the candidate to take a guess at what kind of paradigms your code reviewers like and what they don't like and hope it works out. One team might find use of closures smart and great, and another might find it unintuitive and adding unnecessary complexity. Your applicants have no way of knowing and just have to hope they write code your team likes.
On top of that, one contrived exercise is not a good way to get an idea of a persons' actual skill and knowledge. I'd much rather have a 30-90 minute conversation with someone where nobody writes any code than to review a contrived example. I get the appeal of the programming task, it can be done asynchronously and thus doesn't require any developer time until you go to do the review. But is it really saving you much time? Anyone who's code doesn't pass unit tests or any other automated level of screening wouldn't probably make it very far into a conversation either.
If I have an applicant spend 1-4 hours writing a code example I've had them use at least as much and probably more of their time for far less benefit than if I had simply called them up on Skype and talked to them about programming. The conversation will reveal not only a lot more to me about their actual skill set, but also their personality and how they might fit into my team. Now I realize teams doing exercises aren't skipping the conversation step, but I'm advocating for skipping the programming task step and going right to the conversation if someone's resume is solid and they can intelligently answer some basic questions (a handful of questions that should take no more than a couple minutes to answer, not an essay.)
Second, why would I say it drives off good candidates? Because I know a lot of really good developers (including myself) who skip any job posting that requires writing code as part of the application process. Why do I do that? Because it tells me the team behind this application is immature. They haven't yet gotten to the point in their careers where they realize these exercises are a waste of everyone's time. That means there's probably going to be a lot of other young dude bullshit in the team that I'm not interested in dealing with.