I agree, and yet i've never seen an interview that asks questions about a block of realistic code (not some bullshit minified, uncommented function). Partly be

I agree, and yet i've never seen an interview that asks questions about a block of realistic code (not some bullshit minified, uncommented function). Partly because it's not exactly easy to get enough context and understanding about a codebase in an interview to be able to accurately debug something, but also because again it comes back to what you are familiar with. 6 years ago I would be damn good at debugging and optimizing MySQL queries, today I'd probably struggle to get a moderately complicated one to work without a lot of looking things up and trial/error (I mostly work in postgresql now!). That's why I like to ask about their past experience. Tell me your war stories, tell me what you did to figure out that bug that was causing the elusive crash, tell me about your struggles getting webpack setup, talk about how you initially planned to do X but then after issue Y decided to pivot to Z because it was simpler/easier/faster/whatever, explain how you accidentally put a quadratic-complex function into the hot-path of your application that one time and when you found out it was a problem. Just talking about stuff like that can often show where a developer is in their career, what they are good at, how they go about solving problems, etc... And it's almost impossible to cheat/fake it.