During an interview I've always found it hard to get all the facts I want about a candidate. Several years ago I gave up on technical details. More important is to see if the candidate is interested in learning new things and how good they are at accepting help solving a problem (if they can't solve it them selfs). And I want to find quitters who give up early when they face a difficult problem.
The typical Microsoft interview for developers typically involves solving a number of problems using a white board (tale from interview). And I think people passing that test is generally people who can deal with stress and perform under pressure. And also have the ability to communicate well with others. But I think this method also rejects some great developers that are great assets but who don't really like performing in front of others. Depending on what kind of person you're looking for there might be other ways of finding the best candidate(s) I think.
A while ago I read somewhere about someone who used pair programming as an interview method. I think this is a good method even if you don't use pair programming daily because it is more relaxed taking some pressure off the candidate. It also makes it easier to see how the candidate works with the development tools and you get some insight in how the candidate thinks but it might not give you any interesting designs (that depends on time available and task at hand I guess).
Another interesting approach is extreme interviewing. I like how that method focuses on finding good team members. But it is not a silver bullet for all kinds of situations. For example I once worked as a contractor in a project where one of the other contractors was almost impossible to work with. One time when I reported a bug in his code and suggested a simple fix, he spent four hours rewriting the code (it was a SQL trigger) so that the bug was fixed but with less code. The new solution was so complex that I did no longer understand the logic. I later talked to the project manager about this guy and got the response: "Yeah, he's almost impossible to work with, but he's too good not to have on a project". And I kind of agree because he was really good at what he did. But he didn't leave a trace of code that was easy maintainable so I guess it might not be true it was worth it because I know he's no longer on the project...