My fave approach as a hiring manager is to do the reverse on a take-home test for candidates from e.g. a career fair:
I write code that does something (generally a few different examples in various languages) and don't comment the code at all and have FIXME-type identifiers (function names like FIXME_name_this_function() ). Their job is to figure out what the code does (compile/run it, take it apart, etc) and then comment it and change the identifiers to something useful. They can use any non-human resources they can find (compilers, debuggers, web searches, docs, etc).
I think this is a better approach because:
* When you're starting at a new job, you're probably fixing broken code at first anyway, so this is a better simulation of that.
* I can process many more candidates, since I already know what the code does and don't have to decipher their handwriting on a board, and
* It shows their ability to get code maintainable, which is much better in the long run.
So stop having your candidates write crappy code; have them comment your crappy code instead!