I wonder if just asking for a one or two page design doc on something would be a much better signal, since that's probably what you'll need to do on the job anyways.
In fact, someone who is clear and sound in writing might get bogged down when writing code. Good writers are (obviously) not necessarily good coders.
I do think there is potential around the design doc. Design is a big part of a lot of roles. In addition, in a lot of these roles, having the "best" design isn't better than having a design that the rest of the team can understand. Still, I wouldn't do it for the purpose of identifying good "thinking". I would do it because I expect the people I hire to be good (or have potential) at what they will be expected to do.
I agree that this would be a great question to answer, but I doubt it would be possible to answer at scale. I don’t trust people to give a thumbs up or down on how someone else thinks. It’s also so open to interpretation and that leaves lots of room for implicit bias. He was quickly considering all the variables. She was scatterbrained.
One alternative, focusing entirely on the code written during the interview, is much more concrete. It’s open to preparation (here’s what good and bad solutions look like) and group discussion after the fact. And it’s actually in the professional skill set (judging code) versus doing an amateur job of judging other people’s thoughts.