We don't use coding in interviews partly for this reason -- but more importantly, it sounds to me like the problem here was partly that flub, but possibly more

We don't use coding in interviews partly for this reason -- but more importantly, it sounds to me like the problem here was partly that flub, but possibly more an issue with your communication skills. One of the principal things I look for in candidates is ability to speak comfortably about their thought processes & confidence level -- because it's so much more valuable to have a developer say "well, I can think of two ways to solve this, but I'll have a much more solid answer if I can take 10 minutes to refresh my memory on a project I did 5 years ago" than one who says "there are 2 options". This shows up in interviews (and I look for it); if you give a wrong answer to a question, but you seem to be confident, that's bad. If you give the same wrong answer, but you mention that you don't use the construct (and thus aren't fully confident on your response), that can even be better than giving the right answer. An interview that only saw correct answers can easily be less informative than one that ran into areas of uncertainty -- because it's crucial to see how they handle that. Do they realize they're guessing? If not: don't hire. Are they comfortable revealing uncertainty or missing knowledge? If not, don't hire. Ideally they should know how roughly how confident they should be, and also know how to get to a better answer quickly. Real development isn't at all like a closed-book test, and interviews that operate like a closed-book test aren't useful for that reason.