Depends on the experience level of the interviewee. If they are fresh out of school I expect them to know algorithms and data structures and maybe some specific topic they studied at an advanced level (like compilers, db, graphics, etc). If they are 5-10 years into a career, they should have a lot of knowledge about whatever it is they've been doing. If someone says they have 5 years of Android programming, I'm going to ask them a lot of Android API questions as well as Java.

In either case, there are questions that have multiple difficulties of responses. The more experienced/capable they are, the more nuanced and complete their answers will be. For example, ask a Java person how GC actually works. Most people have very little idea, but the best talent knows a good bit more.

But there are other variables. I've known perfectly intelligent and productive coders who took months to build a really complex well architected system that didn't solve the business problem and hence were a bad hire.

Exactly. So the arbitrary line drawn by leetcode interviews filters in one particular way and benefits people closer to colleges age where these kinds of problems are fresher in the mind. As you get older the number of leetcode style problems you actually encounter in real engineering is pretty low.

Have a chat, discuss experience and see how well they actually understand the things they have put on their resume. Dig as deep as you can and see if they actually understand what they say they have done. Also, references are at least as important as the interview.

I can only speak for myself, but hires on my team are usually based on my recommendation and I mainly try to tease out whether the candidate has enthusiasm and strong opinions about the languages and frameworks we work with. If I ask what their favorite stack is, or how they prefer to organize a project, and they just mumble their way through the answer, I think they are probably not a good fit.