[michaelt]

>The problem is that the people you'd most like to hire probably have little interest in taking a programming test. So you're just filtering them out and left with the dregs. For this to work you need one of the following:

That may be the case if you're trying to headhunt experienced developers who are currently in good jobs.

But if you're an unemployed programmer, or an employed programmer actively looking for a different job, why wouldn't you take a programming test? Programming tests and technical interviews where you have to code are normal and expected for coding jobs, at least in my experience.

[jsnell]

There's a big difference between a programming assignment used as a filter to decide whom to interview vs an interview question.

The hiring process is very expensive. But it's expensive in a fairly symmetric way. It's in the interest of both parties to stop the process if there isn't mutual interest.

Both the company and the candidate will spend a lot of time in interviews, so it's in everyone's best interests to make sure that time isn't wasted if there no (or almost no) chance of the person being hired / accepting a job.

There might be earlier steps in the process, but those are also symmetric. It'll take a few minutes of your time to send a resume to a company, but somebody there will be tossing away 80% of them after reading through them once. There might be a phone screen or two in advance, to decide whether there's any point in having someone come in for an interview, but that is likewise costly to both parties.

But a programming test as the very first step of an interview is totally different. Now the costs are asymmetric. The company has an up-front cost (potentially substantial) but spends little time on each candidate. The candidate spends the time up-front, and only later finds out whether the company is at all interested.

The candidate isn't invested in the process yet. So why would he spend an hour, when he has no idea of whether the company is interested? Maybe it's a really fun problem to solve. Or maybe he really, really wants to work at that particular company. Or maybe he is indeed unemployed like you suggested.

But someone currently employed is likely to have a different priorities from a student or someone who is unemployed, even if they are actively looking for a new job. How large a percentage of them are you willing to weed out completely just by making it harder for them to even enter the hiring funnel? 90%? 50%?

[michaelt]

When there are 630 resumes in the pile, the read/filter will be done by a junior HR person who probably couldn't tell XML from SQL.

I'd rather be filtered by a programming test, where my programming abilities put me ahead of the pack!

With that said, most of the programming tests I've been given in the past have been fairly interesting so perhaps that biases my opinion. I'm certainly no fan of jobs where they send you a huge MS Word application form.

[jsnell]

And I'd rather not work at a place where my resume alone doesn't warrant at least a phone interview :-) Either I really wasn't a good fit for the job, or they have a broken hiring process. If it's the latter, chances are that a company with that bad a HR department is also dysfunctional other ways.

Programming tests can indeed be interesting. Anyone feeling bored could do worse than to attempt solving something from ITA's hiring puzzle archives. But unless you're extremely certain that your tests hit the sweet spot, it seems really dangerous to make them a mandatory first filter. A test once both parties are at least a little bit invested in the process, sure. Or if resume screening really is a problem, allow someone to "skip the queue" by sending a test solution along with the application.