I will have to disagree with this part: > Not only are you putting the candidate under pressure, where thinking is difficult, now you expect them to walk you t

I will have to disagree with this part: > Not only are you putting the candidate under pressure, where thinking is difficult, now you expect them to walk you through their thought process and narrate what they're thinking, disrupting the thought process. I expect a capable developer to be able to explain to themselves why they are choosing (or avoiding) an approach. If they cannot to that, would I trust them to be able to explain their methods or WIP problems to other developers? When I do interviews, I care less about the solution the candidate comes up with, and a lot more how they ended up with the particular solution they used. The process of iteration and dead-end elimination is fascinating. This means that the best questions have N+1 different solutions. Some will be less optimal, but that's life. I also find discussing the effects of different solutions fruitful, on the less common occasions when the candidate ends up tossing one approach and settling on something altogether different. And by the way, I really dislike the idea that you're supposed to do an interview in less than 1h. For anything remotely realistic, that doesn't even let you scratch the surface.