Yeah that's fair. Im just frustrated with how low-bandwidth those things are. I definitely get a bit of a sense of how a person thinks by watching them do those CS 201-style problems, which isn't nothing.
If the CS 201-style problems annoy you, then... stop doing them?
I don't ask algorithm questions, and I wouldn't even dream of asking brain teasers. I ask questions like "Here's a pile of text that claims to be CSV, let's explore how you'd generate an HTML report out of it", and branch out from there depending on how the interview goes. I've got all sorts of directions I can go from there, from screwing up the input in various real-world ways, discussing HTML security and injection attacks, algorithmic complexity of the report, how to build a service out of this, how we're going to handle reporting errors, there's just an endless number of ways you can take the interview from there.
This specific question is new to me but I like it a lot. I have found that the most useful interview questions are technical but more conversational than a white board, more about how to approach and solve a realistic problem. I think your method is a good high-signal approach.
A little late but I wanna be clear that I don't ask them! I ask questions similar to you. My comments here largely come from my experience doing the interview problems. But yeah, i've tried to "be the change," so to speak.
