When interviewing, I'm interested in seeing the process a candidate takes to get a result, not just the result. I like looking at code samples to get a feel for code quality and software engineering practices (everything from variable naming and program structure to Git commit messages)
Real-time coding during the interview shows me how good a candidate is at collaborating when solving a problem. One good indicator is asking follow-up questions to make sure requirements are clear. Other things to look for are, e.g. TDD, which can help solve a problem with predictable correctness and pace. I have interviewed quite a few candidates who throw a bunch of code into the editor and start pseudo-randomly tweaking the code to try to make it work -- this is not a recipe for successful problem solving. Some aspects of code quality can be evaluated during the interview as well, which probably explains why many interviewers don't bother looking at code samples.
It's important to ask for a solution that can be easily deduced -- trick questions are bad for both parties, because the candidate is often stumped, and the interviewer thinks they are bad because knowing the trick makes the question simple. Many classical algorithmic questions are "tricky" in this way.
The questions also have to be "real world". Like you mentioned, you can be a successful engineer and not know the specifics of inverting a tree. If you can correctly recognize the need for the algorithm and implement it from pseudocode, you have solved your problem, which is what engineers are paid to do.