Giving software engineers a small coding challenge prior to actual interview?

What do you think about giving engineers a small software assignment that they complete at home and send over before scheduling an interview. This would really help an employer save both their and the candidates time by ruling them out if their coding skills aren't good.

Would software engineers be willing to do this? Or would it turn away most candidates?

I've used this practice with success. It's not that uncommon and most software engineers are willing to do it. To get the most out of a take-some software assignment, consider making it:

• Related to the kind of work the engineer will be doing in this job. If you need a Ruby on Rails developer, don't make the exercise about Python, for example.
• Cover a range of code and functionality that the job will entail (you don't need to use an actual feature and code from product, you just need this exercise to be somewhat comprehensive).
• Limited in scope. Don't make it a month-long task. Something inside of a day will work.
• Open-ended enough that a range of solutions will work. This can assess the creativity and problem-solving skills of the engineer.
• Fit within certain specifications, such as technical, business, and design requirements. Give the engineer some boundaries. If the code includes HTML, CSS and JavaScript, provide a browser baseline.

The goal of this software assignment is:

• To weed out obviously poor candidates.
• To assess the engineer's ability to complete a task.
• To offer interviewers a way to assess the code for general understanding and practices. Since every candidate is given the same assignment, this can offer a baseline from which to assess all candidates.
• To offer interviewers a starting point for questions. Have the candidate do a code review and explain their development rationale. This can tell you a lot about how the engineer works.

Short tests (1-2 hours) are a nice way to test junior positions not senior levels. They usually tend to be unrealistic to the true potential of someone for more advanced roles and it is hard to get an idea on how someone performs in the long-term.

Short tests will not tell you how developers abstract, how they build with scalability and modularity in mind, how they organize and distribute 10 thousand lines of code... Basically, how your software is going to look in 6 months, which is what you should be concerned about.

On the other hand you don't want to give jobseekers a very long test because they will run away, so how do you test their long-term performance?

• Their personal website and projects
  It has a lot of chances to be 100% their creation. Furthermore, personal websites are not constrained by management, specs, timelines or budgets which mean engineers have been able to work on them with freedom. Also, you can tell the code is made by them and not a mix of several people pushing changes over time
  
• Previous code they've written or had to maintain for other companies
  They will usually have a portfolio where you can see which companies they worked for and what they did. Or just ask them for some projects they've worked on.
• Their Github projects and commits
  If they have an active Github profile I always prefer to look here first since you can appreciate a lot of details: how they code, how they think, what kind of projects they like to work on, etc.

If you can't get enough information from those places then focus the test not on coding but on advanced questions. Examples: software design patterns, advanced gotchas of a programming language (closures, inheritance, specificity, scope, casting...), how would they scale X, how would they organize their folders and files for that project, etc.

Excerpts taken from the full article which you might find helpful: How to Hire a Web Developer