We've just recently started asking candidates to do a code review with the existing team/group members. It can be on any piece of code from their past -- I tell them to choose something that they're passionate about, and that demonstrates the skills that are relevant to our job posting. It works great. Covers everything from coding style to communication skills to documentation to programming ability. I highly recommend this approach...
I mostly deal with finding PhD students for my lab and here's my general procedure:
I ask the "How does BLAST work?" question ... And I make sure they actually answer with something involving suffix-trees. I also ask them to answer the "FizzBuzz" test. I ask these in an e-mail interview ... if they can't answer these (or they're clearly copy-pasted from Wikipedia) then I don't even bother inviting them in.
In a sit down interview: I'll test communication their skills by sending them a handful of papers before our sit-down interview. I'll then have them to give me a "back-of-the-envelope" explanation of any of the papers that I sent.
In the interview I'll point them to the Matlab contest on protein-folding here. I leave the office and ask them to think about another "back-of-the-envelope" algorithm for solving it. I then give them a weekend to come up with an algorithm that will beat ~half of the entries. I also require them to write the same algorithm in both Matlab and Python. There are hundreds of example submissions that they can look at for inspiration. This will tell me how well they can look at previous work and come up with something novel. It also tells me how well they deal with the temptation to copy.
Hope that helps,
Since most people seem to think that this is a little "over-the-top". I'll add a few of my caveats. Out of the dozen or so people I've interviewed only 1 has ever completed the whole thing but I've hired everyone who could pass the FizzBuzz test and make a working Matlab and Python answer. I make my decision based on their enthusiasm and how well they TRY as opposed to just giving up and saying "Its tooo haaaaard"
I think the best thing we've done recently is a review of code from a previous project. Admittedly we've mainly been interviewing for PhD positions recently, but casting an eye over the organisation of (for example) a final year project in terms of code, and how problems have been solved is quite a good mechanism.
I've interviewed more senior positions, and well, it's unlikely you would set people like that code tests, the publication record is more of a key..
For communication, just leave them with the rest of your team for a while. As long as you're going to get proper unbiased opinions back, trust some other people to make a call on the things it's harder to assess in a formal interview.
I ask people to show me something related to the area that they work in, that they did, not for work, and not as part of any class.
Any decent programmer will have dozens of large programs that they wrote on their own time, neither for class nor for work. Any decent writer will have lots of manuscripts they wrote for practice or fun. Anyone who is absorbed by what they do will sometimes do something like it in their free time.