I always hated when interviewers did this. My chain of thought is often backwards, very abstract, or otherwise wildly different from how it seems most others think, and it's very difficult if not impossible for me to articulate my thinking on the spot. In school for writing assignments I would have to spend alot of time reversing or reordering how I arrived at a conclusion before even writing my first sentence. And even just arriving at a conclusion involves taking many dead-ends; the process can be seemingly instantaneous in places, or require laboriously following rabbit holes (often with throwaway code) that I know are dead ends but nonetheless help me to explore context. I need to have the entire problem in my head and able to explore it to at least some extent before even starting to formulate a linear chain of thought, let alone commit something comprehensible to code.

IOW, I can't explain in real-time how I'm working things out. I have to work them out to completion first, quietly, or at least have a good idea about what the full path looks, end-to-end, in detail and only after the fact could I ever hope to explain my thinking. Asking me to explain my thinking while I'm thinking is easily the most stressful and impossible task anyone could ask of me. I'd rather you break my fingers as part of the interview process.

I understand as an interviewer that makes for quite a dilemma. And I suppose if you find this approach reasonable then you may not like working closely with someone like me (though if you're just a manager, then it's a bias to be aware of).

Similarly, practices like pair coding just don't work for me. I'm not not a team player. I like and benefit from design and ad hoc technical discussions, just don't ask me to sit down and write code with someone else, or even with someone looking over my shoulder. All parties involved, including myself, will just end up pulling their hair out. Though I do work best with people who think similar to me. We instinctively know when and how to set our boundaries and expectations.

To interview someone like me it's probably best to focus on having the interviewee identify waypoints (both abstract and concrete) to confirm they have the experience and understanding to navigate difficult problems. Just don't ask them to actually navigate on the spot. If you want to see how they ultimately connect the dots in practice, look at code they've already written. Unlike in most other fields, software developers often have a corpus of work that is easy to share and often already published.