10 years ago and for a different company (in the computer game industry), we used a two question test (in C):
1. Write hex2int (without using any stdlib functions, such as strtoul(s,null, 16) for example. :) )
2. Delete a node from a singly-linked list.
Personally, I found a VERY strong correlation between what we wanted in a game developer and their answer to #1. #2 I didn't find all that valuable, other than to weed out people who'd never taken any algorithm/data structure coursework.
For that company, and those roles, it worked very well, because there's a correlation between bit twiddling, pointer operations, and knowing whether someone "gets" pointers and their job performance. That's not the case in most jobs, nor in most modern languages. (Who cares if you "get" pointers if your language doesn't have them?)
My current company asks on from a set of some fairly basic questions on the phone screen, and we pretty much grade the whole phone screen "pass/fail" (interview/thank you for your time). I can't say they work quite as well, but we're also looking significantly "up market" from what the game company needed.
My idealized criteria:
For professional hires: keep it short, but not so basic as to be insulting.
For college hires: keep it short, and probably basic.
For all in-person/whiteboard exercises: ignore error checking, exceptional conditions, etc. It's just too much effort to go through in that format.
Best coding test I ever took was for Accolade, who sent a zip file of source code for a very simple game (fly an airplane across a 2D map with mountains) and asked you to write "AI" (in the game sense, not the compsci sense) for the player. You had an evening and mailed them back a zip file with your code included. That was fun to do, and I suspect gave them fairly fine-grained insight into how good a coder you were, as there's "working", "optimal" and "elegant" dimensions into which various solutions bucket themselves.