I like this approach. We did something similar, but for a position as support engineer, where coding ability was one of the requirements, though not the only one.<p>They were given a piece of code on a toy, easy to read, english-like pseudo-language, and were asked to examine it and explain what the output to a specific input would be.<p>They were told that we would answer any question, except what the answer was or what the code was doing, and encouraged them to explain their reasoning as they went ahead.<p>We wanted to asses the candidates ability to problem solve, communicate, how would they react under preassure, and how they approached the issue.<p>We were not necessarily looking for perfect answers, we rather rated the candidates willingness to ask for help when stuck, how well they communicated while doing the task, whether they tried different approaches, their ability to grasp what an unknown piece of code was doing and so on... all important properties for a role supporting mission critical solutions with near to zero down-time requirements.<p>Our reasoning was that technical knowledge is easy to acquire over time, but problem solving skills, how candidates tackle difficult and unknown challanges were more important for the role.<p>In my current role I try to design interview questions like that, looking both for the candidates current skills as well as their future potential.<p>Not easy, but IMHO more rewarding for us and them in the long run.