It would be impossible for us to know what it was that you need the developers to do. Although it would be ideal to hire people who specifically know more than you do, you may be able to find other people in your company with better ability in the specific skill areas that you desire for the person to have. (you do have to make sure that you know the personalities of the people that you bring in on an interview -- they may feel threatened by the person they're interviewing, and try to find nit-picking details so they don't lose their reputation as the 'best' in the organization. You also have to understand that there are times when someone's skill is so far beyond yours that what they say will be right, but you just can't understand it as being right).

I would recommend that in any interview, as the person to explain the answers they give. There are those people who can do things, but have no idea why they're doing it, and there are those who can explain why they choose every last line of code. (it's one thing to use strict;, it's another thing to know why it's important). Those people who can explain what they're doing tend to have a better understanding of what they've done, and may be useful should you need them to mentor other programmers.

Note -- This scenario is part of my reasoning for supporting voluntary licensing in the Trained Perl professional or self-taught hack? discussion.

Anyway, as I've gotten off-message -- you may not need (or even want) someone who knows too much, as they may become bored in an environment that doesn't use their skills well. Unless you're under a tight development schedule, it may be better to have someone with a good reputation (references, whatever), and a personality that fits well with the people they'd be working with, even if it's necessary to send them to training on the skills they'd need. A test to determine a good employee for one company may not find the best employee for another company.