I take a bit of a different approach. I want to know how they think. Pose a problem and collaboratively work through it on a white board. No code. Just state diagrams, flow charts, whatever.

Not looking for a solution. Looking for the thought process.

Then put up a piece of code. Ask the candidate to explain it and critique the code. How would you improve it? I'd expect them to ask questions like 'How do you define "improve"?'

I tend to be skeptical of the top 100 programming puzzles because I have no way of knowing if they spent the last two weeks training for just that or not.

You can even take the approach of posing a problem that has, on first inspection, nothing whatsoever to do with their job description. A seat-of-the-pants example would be to ask someone being hired for back-end web development work how they would go about designing a small multi-tasking OS for an small 8 bit micro-controller.

Crazy? Maybe. If the candidate launches into a description without prompt you know that this guy (or gal) either has experience outside of the web realm or is inquisitive enough to read and get into other stuff. If they do not, then you get to see how they go about stepping into something they know nothing about. Do they ask you questions or do they cave?

I don't think there's a single answer to this problem. If you need to hire programmers by the hundreds then, by all means, puzzles are almost a must. If you are after a few uniques, I am not sure they are worth it.