The most important thing I look for is ability to reason about correctness, because I believe that this is a skill that every software engineer should have in order to be productive and not a burden on their team.

• The best candidates proactively write their code in a style that makes it easy to avoid mistakes, perhaps by considering multiple different approaches to the problem and selecting the one that is most straightforward to implement correctly. (PM me if you want an example.) These candidates will write code on the job that is a pleasure to read and review.
• Strong candidates are attentive to correctness. They may or may not be able to write a correct solution on the first try, but if they make a mistake, they understand how to reason about the code in order to correct it. They can often prove their code correct using inductive arguments. See Brian Bi's answer to How do I reverse elements of a linked list in groups of 'n' at a time, where n is less than equal to size of the linked list? Can anyone suggest an algorithm for doing this in generic way using minimum number of variable. Refrain from using STLs. for an example of how a strong candidate should think about a problem.
• Good candidates can write test cases for their code, walk through it, discover errors, and fix them within the time allotted for the interview, with minimal prompting from me.
• Poor candidates don’t test their code, have poor test coverage, believe their code works even when it doesn’t, or practice “shotgun debugging”—making incremental changes without a big picture view of correctness, often failing to ever find a correct solution within the time allotted for the interview. I frequently have to prompt them (for example, by suggesting a test case on which their code produces the wrong result).

I believe that these are skills that every software engineer should develop during their career. If you fail the “correctness” part of my assessment and you blame it on companies quizzing candidates on ACM-ICPC style problems, then I think you just don’t understand how to be a good software engineer.

There are a few other considerations, which are also important, but less so:

• Complexity: You should understand how to determine the big-O complexity of your solution’s time and memory requirements. This often requires understanding the complexity of common library algorithms (e.g., sorting) and operations on the data structures you use. You might be surprised to hear this, but at Google I had a candidate who thought we could find an element in an unsorted array in O(log n) time.
• Coding style: Do you use appropriate idioms for your programming language, or is your style awkward, revealing limited knowledge of language constructs? Do you use appropriate library facilities? Do you give variables appropriate names? If you’ve split up your code into multiple functions, have you done so along clean interface boundaries? Is your code “self-documenting”, or does it only make sense with lots of comments?
• Communication: If your code is good enough (see above), I may not make any significant notes about your verbal communication skills. If your code is not that clear, I expect you to be able to explain how it works. If you don’t arrive at a correct solution, I expect you to be able to explain your thought process well enough so that I can get an idea of how far along you are. Also, if your code relies on any assumptions, I expect that you’ve confirmed with me beforehand that those assumptions are safe to make.