I like to think of the higher level as creative problem solving. Are they (me in this case) going down rabbit holes? Are they painting a clear picture? Are the

I like to think of the higher level as creative problem solving. Are they (me in this case) going down rabbit holes? Are they painting a clear picture? Are they communicating that picture? Are they suggesting edge cases? Are they minimizing bloat? Is it too complicated? What are the most important aspects of the design in their eyes? Can they argue for them? Do they understand where a piece fits and if not, do they understand that something has to go there? Can you both step back and definitely outline a logical flow? There's not always one solution, but the approach counts. Lower level is logical problem solving. Can they reason the problem space? Do they start naively? Can they iterate? Can they optimize? Can they explain each of these steps for future iteration? Do you understand what they're writing? Would you work on that code yourself? There's not always one solution here either, but 90% is getting a naive solution that can be optimized by taking a second look. I feel that the naive should be found in 5-15 minutes and you can spend the rest of the time talking about how to optimize. I know I'm rehashing what you probably already know, but at a certain point interviewers are just playing games. If you've found someone you want to work with who can also reason about problems in a timeframe you see fit, well... that to me looks like gold. I like these questions because that's how real systems are going to be built. Take-homes are great, but there is just so much effort wasted in the process if the product can't be understood.