Yes, you're right. It's a bit awkward. I certainly wouldn't want to do my regular work by whiteboard + dictation. And if I were designing my company's interview approach I might allow candidates to bring in a laptop to work on a toy problem in their chosen IDE.

But my point is that I don't think debugging skills are completely impossible to test in this way, and the forced interaction allows you to learn what piece of information they're looking for and why. If this is how you have to interview, you might as well find the best aspects of it and use them.

I think a lot of the key of getting useful signal from an interview is to ask a simpler problem. If you ask someone to write and debug really complex code in 45 minutes, you'll just find out if they can write code under pressure really fast. That's a great skill, but I care more about communication: being able to ask good requirements questions, describe the data structure/algorithm so that teammates will understand it, teach people how to work through problems, etc. I think overly complex coding takes away the time I spend examining those things. Likewise, there are a few criteria besides "coding" and "communication" which I also want time to focus on.

When I look through the notes from the full interview panel, my questions often seem to be simpler than others. My feedback appears to correlate more strongly with actual hiring than average, so I think it's persuasive. Of course, I don't know if it correlates well with how people would actually perform if we hired them. I don't even know if the people we did hire are performing well, because I work at a big company and the people I hire generally don't end up on my team.