If you want to reason about code, why not give them the solution and ask them how they would implement it - discussing with them about how they would implement the solution would be more enlightening. When you are being interviewed, the first hurdle is 'solving' the problem - coming up with a solution. Evaluating a developer on 'how they solve' a problem in highly stressful situation seems somewhat unreasonable - after all, what is more important in their day-to-day job is the ability to write maintainable, easy-to-understand code. In real life, problems are often solved via brainstorming with the team, going through iterations of getting/clarifying requirements