A way test people and find out if people are going to fit with your team is to involve the candidate in the real process that you have with your team instead of inventing scenarios just for the interview or coming up with trick questions that supposedly tests the knowledge that they have. This makes for a better team interview, because unless your team interviews people often it turns out they are probably ill-prepared and very bad at interviewing people! Afterall, do you sit around with your team on a regular basis, singling out one person to ask them random technical trivia questions? So, make it real...
During the later stages of the interview process treat them as if you hired them as a consultant to work on a specific problem for part of a day. At the later stages of the interview process both you and they should be willing to commit a good 2- to 4-hour (or more!) chunk of time to the interview process. That should be sufficient time to involve them in a real meeting with the team members they would be working with to discuss and begin working on an actual problem your team is trying to solve. Yes, that takes quite a bit more preparation and planning on your side, but it will tell you a lot more about how someone thinks and works along side others than any number of interview questions you might ask.
The hard part of this is carving out a well-defined problem that is solvable, at least in part, in a reasonable amount of time, that is deep enough to touch on multiple technical areas, and that requires enough interaction with multiple members of your team to get a sense of how they approach problems and work with others to solve them.
Working along side others is much better than isolating them in a room with a problem to solve since their communication skills and ability to work with your team is often more valuable than any domain specific knowledge they may bring with them-- not that the latter isn't important, but it's not worth hiring the smartest person in the world if they're gonna act like a jerk and can't work with everyone else.
Something that makes this process easier is if you already use pairing stations with your current team, as is popular these days in some work places. Note I said pairing station rather than pair programming station, because a pair doesn't have to be limited to just writing code-- other office disciplines can benefit from that kind of setup, as well. I don't recommend using a pairing station just for the interview, though! If you don't already use them in your workplace with your team, then it will be another artificial part of the interview. For the team that I manage we don't use pairing stations for everything, but it is part of our office setup and I make sure that we make use of them when it is effective to use them, so in our environment it makes sense to use it as part of the interview process.