|There's more than one way to do things|
I'm a hiring manager, though I don't get to play one on TV. (That's probably a Good Thing :-)
One of the challenges in interviewing is to plan out a set of questions that gets at
"Closed-ended" questions ("what do the symbols $ @ % and * mean...") will tell you how well a candidate knows the mechanics of Perl, but if you limit yourself to them, you're liable to hire a complete doofus who happens to know some facts about Perl.
"Open-ended" questions can get at how a candidate thinks ("tell me about a gnarly problem you solved with Perl") and what their values are ("what are the characteristics of a project that is well suited to Perl"). You want a few "values" questions thrown into the mix to help judge how the candidate will fit in with the culture. But, if you limit yourself to open-ended questions, you risk hiring a thinker who can't produce.
To complicate this, imagine that you have a 30 minute interview slot.
What to do?
A technique I picked up from a good manager a while back, and have since refined, is to pose a "vague problem with no right answer1" and ask the candidate how they would approach it. The value of being vague is that you'll quickly see whether the candidate will stop and ask questions. (A candidate who jumps right in without taking the time to determine whether they're solving the right problem is not someone I want on my team.) I'll often throw a few hints to a candidate who gets stuck. (Would you want someone on your team who would rather stay stuck or plunge headlong down a blind alley rather than take a hint?)
The vague problem typically involves some simple elements of OO modeling (simple enough to tell me within a few minutes whether the candidate "gets" objects). After getting them to do a sketch on the whiteboard (which tells something about how the candidate will communicate in design meetings -- doubly important here since many of the folks I work with aren't native English speakers). I ask them to sketch out a class definition in whatever language they're most comfortable with, and pseudo-code one or two methods. (This tells me whether they can implement with objects.) As necessary, I'll toss in a few close-ended questions.
Finally, if we've gotten this far and have some time left, I'll ask them to discuss the strengths and weakness of their approach. (Can this candidate reflect on their work? Are they self-critical?) The candidate who asks how I would solve the problem gets extra points (for showing that they can seek new viewpoints, not for stroking my mighty ego).
With a little practice using this approach, here's what you can find out in 30 minutes:
It's been my experience that a candidate who nails these is the one you want, unless you have really narrow technical requirements that they can't satisfy within your time window.
* * *
1 I ask the candidate how they would model and implement the inner workings of Minesweeper (avoiding UI details unless I'm hiring a UI developer). There are several approaches to Minesweeper that "work", and several wrong approaches. A few candidates have demonstrated that there are also seriously wrong approaches. I've had candidates use C++, Java, and Perl. (The few who've tried straight C tended to flunk badly.)