I agree completely, and it applies equally to software engineering. It's how I interview. Now, if it becomes clear that there are gaps in their knowledge, I wil

I agree completely, and it applies equally to software engineering. It's how I interview. Now, if it becomes clear that there are gaps in their knowledge, I will spend some time on those areas so I (or the relevant hiring manager) can make a decision regarding if the trade-offs are something I (or they) can live with. For engineers, that can sometimes mean an algorithm problem--but something they haven't likely seen before. The key here being that I don't want to see someone regurgitate a solution, but to understand how they think. If they can't solve a problem fully but can come up with a list of 10 extremely pertinent questions I intentionally failed to mention, that is good information to have.