> So why not give a simple coding test? Talk through peoples thought processes
What do you mean? That's pretty much what leetcode-style problems are during interviews. You get a problem with some theme, like "here is a list of airplane flights in an array composed of tuples, with the first member being origin, and the second being destination. Write code that would create full-blown routes out of those flight entries."
You ask questions, clarify constraints, come up with a few approaches, discuss with the interviewer pros and cons of each, decide to go with one, implement it while walking the interviewer through your thought process. And then you discuss limitations and edge cases, scalability concerns, how you would test it if it was a problem you were solving at an actual workplace, etc.
Leetcode-style interviewing doesn't typically refer to "we just pulled a random problem from leetcode, go ahead and solve it while I am standing over your shoulder, and we will check how correct the solution is afterwards." In fact, interviewers care way more about the thought process and your approach, as opposed to caring about your solution matching theirs. In fact, there were many cases where people ended up not solving the problem and passed the interview anyway, as well as cases where people solved the problem and ended up not passing. Because the process of arriving at the solution and the reasoning you took to get there matters way more when hiring (even if you didn't get there all the way to the correct solution), as opposed to just getting the correct answer. The fastest way to fail a leetcode-style interview is to sit down and write down the correct solution as fast as possible, without explaining your reasoning process or even anything at all.