When I interview people, I ask them about their experience and give them opportunities to let me know their strengths and weaknesses. If someone says language X is their go-to language for solving simple day-to-day problems and they're an expert, a short demonstration tells me much more than they ever could. I will never ask someone to use a language they haven't already said is one of their strongest or do anything to make the problem difficult or obscure.
I tried the fizzbuzz exercise mentioned in another post and it took me 1 minute, 40 seconds from creating a scratch directory to running the completed, working program. Having never seen or thought about the requirements before, I consider that a confirmation that this isn't a bad interview question.
The programming examples I ask for are more complicated, but ones that I can do from scratch in under 3 minutes, so giving someone 45 minutes, ability to ask any questions or clarifications they need and full access to google and man pages seems perfectly reasonable. Even if the person is nervous and not good at interviewing, they should be able to complete the exercise. I want programmers who are good at collecting requirements and communicating with the computer by means of code. This is an opportunity to shine if their interviewing or communication skills are not as strong as their programming. The exercise is pass/fail and I never compare their time to complete the exercise to my own.
When I look at the code, there are several places where style and experience show. For example, if I have them run their code against 20 records, will it take exponentially longer if I later run with 200 or 20000 records? That's not part of the stated requirements, but if their code runs in linear instead of exponential time, they pass with a solid thumbs up. If their runtime would be exponential, it's an opportunity to pose that back to them and see what they would do differently given that as a new (after the fact) requirement. Understanding the difference and knowing how to fix it is also perfectly acceptable. Requirements change all the time and that's a good opportunity to understand their thought process.
I've never hired a programmer without making them write code and never would. I'm also cautious of places that would hire me without putting me in front of a computer, even though I interview well. I've interviewed far too many people who may talk the talk or hide behind English as a second language, but are actually just incompetent. Likewise, producing elegant code on the fly speaks for itself.