Are 'Coding Tests' Effective in Developer Recruitment?

My experience:<p>If done in a multiple-choice test fashion, coding tests are worse than useless. The questions usually hinge on minutia of syntax, like operator precedence. Also, they're usually done in Word, so auto-capitalization can cause problems. For instance, in Java, "boolean" and "Boolean" act differently. Word, in its infinite auto-capitalization wisdom, can make test-writers look like boobs to test-takers.<p>Coding tests when done with experience programmers watching via a collaboration tool, could be illuminating to the watchers. Seeing little things happen could tell a lot about the test-taker.<p>Unfortunately, the point of a coding test seems to be to allow some kind of administrative filtering on candidates before the interview-with-a-programmer, so they're often multiple choice and a hindrance to finding the right people.<p>I'll take multiple-choice coding tests, but only for their humor value. I would have a distinct bias against a potential employer that used them, and a larger bias against a potential employer that put any faith in coding tests.

We use a coding test as a part of the interview process for new developers and it works quite nicely. Note it is just one part of the process, though it can help sway a decision when we are on the fence (I have personally seen it push the decision both in favor of and against a candidate). Also the test is a solved problem, we don't ask candidates to do our work for us :) Lastly we put a 2 hour limit on the test. Depending on what language the solution is submitted in this may result in an incomplete submission which is fine. We don't want candidates to spend tons of time on it (it is pretty easy to tell when someone has disregarded the time limit) since two hours of work is enough material to gauge metrics that we care about.