To give an alternative approach - I found that in general, I could get a pretty good idea about a candidate using either the verbal interaction or written test.

To give an alternative approach - I found that in general, I could get a pretty good idea about a candidate using either the verbal interaction or written test. The idea was to give questions which are almost a polar opposite of the strange trivia style questions you see in certification exams. Instead of the candidate having to remember which overload of an API returns a byte[], we'd instead talk about things like how they prefer to structure a project, and how this feeds into maintainability, etc. If the person was into object orientation, we'd talk about that, if they were into a more functional style, same angle, but I want them to have thought about it from a software engineering side. It sounds wishy-washy, but with just a few pointed questions, you can detect both BS answers, as well as someone who hasn't really thought about it. I tend to find that this quality in an individual is a very important predictor of performance, as it indicates deep care and interest about their craft. With good candidates, you can get really deep into a discussion and know within 5 minutes that they are quality. Along the way, you'd also get a pretty good picture of the persons strengths and stylistic preferences, which you can use to determine how and where they would fit in with the team(s) you had in mind. The only downsides are that I wasn't always available for these interviews, and the written equivalent intimidating and could take long. Also, various people swore that they either can't perform well in written or verbal conditions, so perhaps letting the candidate choose between the two might be beneficial.