Many good candidates could be put off by such test. More importantly, even if they agree to your test and send you some code, you need an engineer's time to evaluate the code sample, and if you're going to invest engineer's time you might as well do a full phone screen. The recruiters are by and large non-technical people. They would love to be able to ask some technical questions which could help them predict whether a candidate would pass the interviews or not. I've been actually asked by a recruiter friend of mine how to do it. But, if you think about it, this is not so easy if you're not a programmer yourself.

You are absolutely right that it would be madness to hire a programmer without having seen him code. The companies are well aware of it and they will surely ask you to write a lot of code during the interviews. But that comes at a much later stage, as it costs them much more money than checking on your resume whether you have a degree or not.

I'm not saying that I like the way things are, but that's just life. If that's of any consolation, in most other industries the requirement of having a degree is much more strict than in case of Software Engineers.

I disagree, any candidate worth having would enjoy such a test. Any programmer who is put off by being asked to program needs to find another profession, period. You should not ask someone to program during an interview, you should review the code they've submitted and make them explain it, all if it, their design choices, their idioms, naming conventions, etc. If they can't discuss code they just wrote prior to the interview, you don't want them, but many good people don't perform well under the pressure of an interview so you won't get an accurate feel for them if they program at the interview.

No one but a programmer is qualified to evaluate another programmer, HR and recruiters have no place here and they'll just waste time and effort pretending to be useful, they aren't.

By doing the test you've already filtered out the wanna be's so you don't need phone interviews, the submitted samples should go strait to a qualified programmer, it'll take him only a few minutes to toss out any bad submissions and he'll quickly know who's worth actually interviewing and who's not.

Code is the only resume a good programmer needs.

One issue to be aware of is that it's not just the corporation interviewing multiple candidates. It's also the candidate interviewing multiple companies. Putting a large burden on each candidate may not scale if every company does it. I agree that it's important to assess actual coding ability but I don't know if a programming test is the best way to go about it.

Any programmer who considers such a trivial test a large burden, you don't want. There's no other way to assess programming ability than programming, it's really that simple. If you hire an unknown programmer without making him submit a code sample, then you deserve what you get because you're gambling and likely to lose. The whole point is to find good programmers, and good programmers enjoy programming, they'll happily write a trivial program to prove it, happily. Anyone who balks at such a test is not someone you want to hire, period.

Dont be the kind of employer that asks for a week long project as a resume. That's just irritating.

I didn't say that, I'm talking an hour or two long project here.

That may work better than a resume.

Can you imagine a test for the ability to work on larger programs?

Good code is good code, I don't agree that it takes a vastly different skill set to work on different sized programs. During the interview you can simply ask questions such as "How would you provide the ability to configure various strategies for different users interfaces for this slot machine? Say a web UI, a command line UI, and a native app UI?". "How might you make the randomizer for spinning the slots configurable?". The discussions these open up will tell you a lot about their knowledge of making flexible software.

Again, the test is just to weed out the bad candidates and allow you to only interview worthy people, everything else you'll find out in the actual interview. Interviews will be rare, few people will submit code you'll find acceptable at all. The vast majority of people applying for programming jobs, can't program, it's sad, but true.

There is a set of skills and body of experience that applies to working on large bodies of code. In fact, there are different skill sets for working on bodies of bad code and good code.

You'll note I said vastly different, I didn't say there was no difference.

The language syntax may be the same, but programming approaches might be very different. I've seen parts of a Smalltalk program where it was coded like spaghetti copy-paste Fortran, and it's actually hopeless to try and fully understand the semantics and still meet your deadline. But I was able to use a few tricks to prove that certain modifications wouldn't alter other functionality so I could get my work done. In the same program, there was well factored code with a nice object model, where it would behoove you to understand the part you're working on in a more conventional way.

On reflection, I think you may be right that good code is good code. Size of the system matters most when the code is bad.