I've long since abandoned trying to do programming tests when interviewing coders. Instead, I work through a problem with them in a sort of socratic method; I play devil's advocate to them while they flesh out how they'd approach the problem.
It's far more illuminating, and a far better reflection of their worth as a candidate, than their ability to go off into a room somewhere and work through a problem alone. I'm much more interested in someone who thinks well than who codes well (since the latter can easily be trained).
This is the same approach we've taken with candidates. We start with a phone screen and then a simple coding problem submitted via email. When we bring them in for an interview they spend time with with a few developers working collaboratively on a problem. If possible, it's a bit of work from the current iteration. Working together on real-world code has been surprisingly effective. I was skeptical at first, but it has been very helpful in weeding out candidates who had good cv's and probably could have coded a really great algorithm to traverse a binary tree but weren't great with solving real world problems.
It's far more illuminating, and a far better reflection of their worth as a candidate, than their ability to go off into a room somewhere and work through a problem alone. I'm much more interested in someone who thinks well than who codes well (since the latter can easily be trained).