I always have applicants write code on a whiteboard. I usually pick a simple coding problem, like something that'd be an intro computer science problem or code kata. (I tried using psykotic's Left Factoring Regular Expressions problem off programming Reddit once, but it was wildly inappropriate for the caliber of applicants we were getting.) If you're hiring for a database design position, I might have you design a database schema instead. I'm looking for:

1.) I don't care about syntax errors. It's trivially easy to forget a semicolon or parentheses on a whiteboard and doesn't reflect poorly on you if you do (usually I'll just write them in at the end).

2.) I do care about how fast you can remember language keywords and commonly used library functions. This is usually a good proxy for experience with the language, because after any significant development these tend to get "burned in" and you can write them out instinctively. Someone who doesn't remember the syntax for a foreach loop in PHP probably hasn't programmed PHP in a while.

3.) You can make all the mistakes you want, but I'm looking at how quickly you realize they are mistakes. It's a very bad habit to write something out, look at it, realize it's wrong, and then rewrite the whole thing. (Okay, that's basically what I've been doing with my startup for the last month, but at least it's wrong on an architectural level, in ways that we couldn't have foreseen a month ago.) It's a good habit to write things down and immediately correct them if they're wrong.

4.) If you come up with the textbook algorithm immediately, it shows me that you've had this problem in class and actually remember what you learned there (I may have you do another problem then). If you come up with the textbook algorithm eventually, it shows me that you're good at thinking things through and analyzing a problem. This is probably the best situation hiring-wise. If you come up with a completely out-of-the-box solution that works and doesn't have any obvious fencepost or performance problems, it shows you're a creative thinker. This is also speaks well about you as a candidate. If you struggle and come up with something completely wrong, I'll probably prod you with questions about its behavior; this is not a good situation, but I'll look more favorably upon someone who finishes and gets the correct answer eventually than someone who gives up and says "I don't know."

5.) I like it when people use library functions rather than reinventing the wheel (particularly if they are library functions I don't know myself; though I will check and learn them myself after the interview to make sure you aren't bullshitting me ;-)). If I ask someone to write a sorting algorithm and they put down "sort()", they get points for their cheekiness, though I'll have them do another problem or add some specific requirement that makes the library useless.

6.) It's good to talk through what you're doing, for the same reasons teachers ask you to show your work. It lets you get partial credit for right-thinking but wrong-writing. And if your thinking is off but you say it aloud, I'm more likely to ask prodding questions to make you rethink; I look at this more favorably than if you got to the end, pronounced it done, and it was wrong. You're also more likely to catch the error yourself, and correcting yourself is actually a net positive.