I don't know, I've been part of a few technical interviews and it's hard trying to pick the right candidates - it's easy to pretend and say so roughly the right things, but very hard to tell who's really got the knack for it and not. Particularly things like "will you figure stuff out on your own or do you need lots of documentation telling you how to do it?" because you never get the right answer if you ask them.
I used to think that, but then my company sent me to a "how to interview" training session. That has been the single most useful training that any company has ever given me and it totally opened by eyes. The reason it was hard was that I didn't know how to interview.
Now that I know how to ask the right questions, it is a piece of cake. So if it is important that people be able to learn on their own, then you ask them for an example where they did that. And then you ask follow up after follow up to sniff out whether they are feeding you a line. Things like, "Why was that problem a challenge?", "What were the alternatives?", "Why didn't you just do ?", etc. Really good candidates know tons about the projects they worked on, understand the architecture and design, and can talk about the strengths and weaknesses. When you do this, good candidates really stand out. Bad candidates give you vague answers and try not to get pinned down on anything. If you come out of the interview unsure, then you shouldn't hire them.
Having been the interviewee many times, I can state that most engineers are terrible at interviewing. They don't know it, but I recognize it because I can see that they are asking the wrong questions. They just ask a bunch of trivia questions to see if I know about prepared statements or polymorphism or valgrind without ever digging into what problems I have solved and how I pick up new skills.