Just give each person a few programming tasks that should take ten minutes or so.
Yeah, but actually no. Each skill set is different. I could write you a PCB router in under an hour, or whip up an image processing mechanism, layered image editing, signal processing, write an FFT from scratch. I can do assembly coding as fast as I can type while higher up, I favor c and Python for their various and highly disjoint abilities. I'm good at documentation, and I can manage effectively -- without getting the team to hate me. But fizzbuzz? Sort of boggles me. I solve it very slowly. Perhaps because there's no point to it and I don't really give a flying crap. :) But perhaps also because it's just not my thing. I despise puzzles-for-the-sake-of-puzzles, and avoid them like the plague.
Bottom line, any type of interview question or test will sit poorly with some high quality programmer. Some don't know a language, some have an unusual process, some aren't great communicators, some don't function well with someone staring at them or under immediate pressure... there is no perfect interview method, and surely no way to determine programmer competence outside of their actual accomplishments -- which, even when you can pull it off, is not the same thing as measuring their skills against others, placing them in an objective relationship to the skills of others, either.
Personally -- and this is strictly anecdotal, but reflects many decades of experience -- I've had a lot better luck asking many-possible-answer questions about techniques and areas of knowledge in a friendly, low-pressure atmosphere where the interviewee is made to feel they are welcome and respected the moment they walk in the door.