The more I interview the less I tend to give weight to the technical part and the more I focus on evaluating how well I get along with the person, how easily and naturally we can
discuss programming topics, and do we happen to converge on building a rapport.
People can learn technical stuff and people can grow professionally but the chemistry is harder to fix. And, unlike some programmers might see it, even code is communication and, a bit surprisingly, is subject to chemistry. You can talk to some people via code. Not all people.
I consider the technical part merely as a way to filter out people who seem to be missing something blatantly obvious. I'm fully aware that my system will sometimes generate false negatives but there's no such thing as a fully objective interview.
I have a few technical things or topics that I usually ask about and I expect every candidate to know at least a few of them but certainly not all. I generally go forward topic by topic until the candidate has at least N things s/he knows about. Of those that the candidate does know about, I ask more and more details until I run out of questions or the candidate runs out of answers. If I'm getting strong signals early that the candidate is likely to be ok, I'll just try to finish up the technical part quickly.
Then I proceed to the most important and revealing part which seems to be asking about a project that the candidate is really proud of, work or hobby. In the best case I get a lecture down to details on something the candidate built that s/he's still excited to explain to someone, on the coolest things s/he could build into that project. A good programmer pours so much passion into some, possibly minuscule, part of what s/he's building that you surely should be able to ooze some of that out back.
Another important part is asking about hobby projects: if one particular candidate doesn't program on his/her spare time, I'll probably go with any other candidate who does unless s/he's exceptionally strong otherwise.
I try to remove pressure from the interview by acknowledging that given some rough preliminary filtering, I could go wrong either way. Maybe I reject a good candidate because I don't know as much myself. Maybe I accept someone who's really nice and who seems to know about things, passing my filters, but turns out s/he just can't produce much code hands down. All that will happen some day.
The trial period is there so that both parties can revert an obviously wrong decision. We haven't needed that yet but I greatly prefer to postpone some responsibility for later and relaxing the actual interviews as much as possible. People don't like to be grilled and I don't like to grill people, not only because it's very consuming but because it doesn't seem to be a particularly effective indicator.
There will never be a silver bullet to interviewing because there will never be a silver bullet to meeting people the right way, but if I were to suggest one thing it might be to listen more and ask fewer questions. By listening, I don't mean letting a babbling candidate take over the interview. By listening, I mean to figure out who is this person, where s/he's coming from and where s/he seems to be going.
Being the fastest and most accurate shooter isn't much of a value unless you know what you want to shoot, what needs to be shot, and why.