This is an opinion based question. Here's my take:
Open source is good. Candidates who've made contributions to prominent open source projects like Apache, Mono, etc., must definitely write good code. Those organizations have a good code review process. Even if the projects aren't popular, you get a chance to do a code review on your own before you invite the person.
Ice breaker before Interview
I can tell you on my recent interview with Google I had a breakdown. Serious adrenaline rush, and it impaired my thought process. The interviewer started with a coding question, and I couldn't think straight. Phone interviews are bad, in general. Try to have a small warm up of some sort, just talk in general to get the candidate comfortable. Be nice.
Having at least one behavioral face-to-face interview is very important. You get to know the person's attitude towards things, and how they handle different situations, etc.
Although people might disagree with this, I kind of like Google's academic approach to interviews. Give them a problem to solve, and see what kind of thought process they have, how they approach the problem. As a computer engineer, that is important. It's fine if they don't get the right solution.
In addition, you probably want to ask questions specific to the job. Like if the job involves SQL, you can ask things like database architecture, normalization, indexes, parallel queries, improving query based on query plan.
You want to make sure that they know their field. You wouldn't want to hire an incompetent architect to build your house, would you?
Good, clean code
I'd like to know that their code is clean and readable. They are able to recognize bad design and fix it. They know DRY and some of SOLID. A few design patterns, and basic OOP.
Basic Algorithms and Scalability
Recognize where solutions can and need to be improved for scalability. For instance, on Mobile development, I wouldn't want them to query a thousand items and bubble sort them.