This approach screens out people who have the potential to accomplish but haven't yet - I would never try to interview people like this for a development role, since past experience doesn't necessarily tell me if they can do what is needed well.
That's what I try to do when interviewing programmers. I never make anyone write code, I want to know how they think, what did they pay attention to, and what did they learn from projects they did.
This is a good strategy and it's one I've employed, but what I've found a lot of the time is that you get nothing from the candidate.<p>Basically you ask them questions and they give you short, often vague answers. They don't really go into detail or talk at length.<p>I've found this about a lot of people in general. You can ask them three questions and they will sorta answer one, but never illuminate anything.<p>I don't know if this is a sign of dim intelligence, or nervousness or not paying attention or what.<p>But people who are on the ball and great communicators will do much better in this kind of interview than people who are terribly shy-- even though the latter might be a better employee. (spending less time around the water cooler for one.)
The most important thing to focus on is yourself so you know exactly what you want when you interview people. Too many times I have been dragged in as an interviewer just to make up the numbers (bureaucratic game you have to play within universities) where the real interviewers (the people who actually are doing the hiring) had no idea what they were looking for. Most of the time it seemed to be a pointless exercise; we would chat to everyone and then the real interviewers would just choose the "nicest” appearing candidate.