If and when you do that, always give the candidate a collection of language reference-texts or free-access to a web equivalent. Be sure to emphasize to them that they are free to use any of those sources entirely without penalty. If they feel that they can't do the exercise and instead want to explain to you the approach that they would take, let them do it ... without penalty nor prejudice.

A good coder is fine, but a good conceptual designer who can present his or her thoughts and ideas to you in a cohesive and understandable way is infinitely better.

Another approach is to present a candidate with a block of code and ask them to explain, in their own words, what it's doing and perhaps what its data-structures look like. Ask them if they might have any comments or suggestions about the code. The code that you select for such a purpose should be the clearest, least-obscure code that you can find.

During all the community-college courses I have ever taught, students were allowed to have a hand-prepared “cheat sheet” with them during the exams. They turned-in a copy of those cheat-sheets with the exam. You could see their depth-of-understanding from the way in which they prepared that material, and I notice that the very best sheets were rarely used during the test.

Another important courtesy that I suggest, in these days of e-mail, is to send the candidate a detailed description of exactly what you intend for them to do during the interview. Consider sending them a preliminary e-mailed interview, not from Brain-whoeveritis, asking them to return their responses via reply. I'd have no problem at all telling anyone generally “what they are,” since each ‘exam’ when I actually sent it out would be unique. I'm not trying to test a candidate's ability to react to surprises, and I don't want to re-create grammar school with all of its anxieties.