I'll just come right out and say it: Asking a programmer to code during an interview is a bad idea.
I've seen many interviews in which the interviewer - usually one of the programmers on the team the interviewee is hoping to join - asks the interviewee to write some code, either on a piece of paper or on a whiteboard or sometimes on a computer ... though rarely. I'll even admin to being guilty of doing this when I was younger. I've watched my staff ask candidates to write code, I've watched my teams debate over what they should have a candidate code during the interview. Eventually I'll intervene and put a stop to it. Here is what I tell them.
Asking someone to write code during an interview does nothing to give you insight into their programming ability.
A) No one writes code on paper or a white board ... not ever.
B) Modern programming tools are full of features such as auto-complete, immediate error checking, beautification, etc. None of which are available on a white board.
C) Programmers have always relied on looking up syntax, code snippets, and how-to's on the internet. If you aren't willing to let your candidate do the same during the interview, then you shouldn't be asking them to code.
D) Programmers will remember syntax, features, functions, and algorithms they use often, and will not remember syntax, features, functions and algorithms they use infrequently or not at all. Will you know in which of these categories your programming tasks fall?
I can hear the push-back now. "But if we stick to basic coding, they should be able do that."
To which I answer - if your coding task is that basic, it doesn't tell you anything
Again, I can hear the push-back. "It will help us weed out people that can't code."
To which I answer ... if a candidate for a programming position has made it to a face-to-face interview and they can't code then your candidate selection process leaves much to be desired. Perhaps fix that first.
There are other questions you can ask that will tell you about their programming capabilities, but it is important to let them draw from their own experience. Interviewing a programmer should be a discussion and if you ask the right questions, they can lead to meaningful discussions that will tell you more about your candidate than any coding assignment you throw at them.
Tell us about a particularly frustrating programming challenge you faced. A question like this allows the candidate to tell you about a real problem from their own experience, so it takes out any bias you introduce by choosing a problem for them to work on. It will open the door for you to ask how they solved the problem, to understand the nature of a challenge the candidate might struggle with, and dig into how creative they get when solving a problem.
What is the worst coding error you've ever seen? I haven't met programmer yet that hasn't seen some really bad code that is burned into their scull. The ability to explain the code and why it is particularly bad will tell you a lot about their own skills as a programmer. If they can't recall any bad code there is a good chance they aren't good enough to recognize bad code when they see it ... and in all likely hood are producing bad code.
What development environment (IDE) do you use? What is one thing that frustrates you about it. First, if they can't discuss their own development environment then they are a novice at best. Second, anyone that spends quality time hunkered down writing code will have something that frustrates them about that environment. Being able to articulate that will tell you a lot about their abilities and should lead to a discussion about programming topics and practices that the candidate is particularly passionate about.
Tell us about some coding conventions you or your team has. Again, anyone that doesn't know what a coding convention is probably doesn't have enough experience for you. This question shouldn't be used to judge the conventions themselves (programmers love to judge each other and each others teams, but now is not the time). The range of answers you get back will be huge. Anything from using Pascal case for variables to database access conventions to code performance analysis practices. Regardless of the complexity of the convention, the response should open the door for you to have further discussions such as the benefits or drawbacks of the convention, and offer opportunities for the candidate to demonstrate their knowledge and experience.
Questions such as these foster a dialog between the candidate and the interviewer(s). That dialog is where you will get an understanding of their experience and abilities. Giving them a programming task is usually more of a test of their ability to memorize than anything else and memorization ability most definitely does not equate to programming skill.