This is the thought process. I use something very similar and have done well in interviews.

I found I did better in interviews when I showed my thinking less, or adapted it to the interviewer. Stating the things I'm not doing is useful, but too risky. Just hearing the words "linked list" in a problem that can't be solved with linked lists (even in the sentence "linked list doesn't seem to be right") startles some interviewers. A high enough percentage I don't want to roll that die six times during a round.

The silliest example is I like to work on problems by writing code. Yes, even if I don't understand the problem perfectly. Seeing some code helps clarify my thinking and I throw most of it away.

Freaks. People. Out.

Writing down some wrong line of code may as well be blasphemy. Strangely, not the case with comments. So my technique in interviews was to write comments that were as equivalent as possible to code and then convert it to regular code when I felt things were close enough. The biggest challenge in Python is not making it so similar that it becomes obvious what you're doing.

lol yeah having been through these loops and training to do these loops it really seems like most people say they want to see “thought process”, but what they’re really looking for are the usual cues you see in all the prep info online.

E.g. ask some clarifying questions before coding, write or suggest a brute force, and then write an optimized algo.

Without clarifying questions, often you assume something about the problem that's not actually the case. And a brute force solution is often very useful to learn more about the problem domain. Personally I really like doing a bad solution before a better one. Especially in the setting where it's not completely whiteboard, so I have the ability to run and test my code, then having a brute force solution around to debug the problem is useful.

I find writing and even sometimes describing the brute force to be hazardous. Seems better to wave in its general direction.