In my experience, asking candidates to read and explain someone else's code is a much better indicator than letting them do some whiteboard programming.
Similarly I've found that talking through some deliberately broken code, and what improvements could be made to it, gives a good idea of what a candidate would be like to work with on real problems. It's more about the discussion than the code changes they come up with!
Agree 100% especially since that's most of the daily job is fixing up old code that was written in a hurry or for a different circumstance.
The ability to see what some code was trying to do and how to fix it and make it extendable and or understandable for future generations is invaluable.
This is a great point. Most programming jobs I've seen are about 10% writing new code and 90% maintaining / fixing / extending old code. I'd rather know that you can jump into a codebase you've never seen and get productive quickly than know that you can invert a binary tree on a whiteboard.
