You ask them about a previous project they've worked on, or a problem you currently have and take it from there. You are bound to hit interesting problems where you can ask them what they would do, if they've had similar issues, how they solved it, what tech they used and why, would you do it differently now, etc.

If you care about performance and data structures you can dig in, you can ask what bottlenecks they had, what structures they used. I've had a lot of success just asking in the middle something like "why not use a list or vector?" (in C++), the discussion that follows tells me already if this person knows how memory works, how algorithms scale, etc and this are things I really care about in my industry, not just random trivia.

All of this is done as a conversation, I want to minimize their nerves as that just obfuscates the real person I'd be working with.

I get none of that info asking someone to invert a binary tree on a whiteboard.

"Can you tell me about a hard problem you've solved?" is usually enough to kick off a good dialogue. It gives you a little peek into their approach to solving problems, but also tells you what they think is hard. If you ask good follow up questions, you'll very quickly have a solid understanding of their current experience levels and a rough gauge of their aptitude. A lot of it comes from intuition and experience interviewing and hiring.

Building out a great team is more art than science, and you won't ever hone that craft by throwing coding challenges at your applicants - you just end up with a group of people who are a bit more likely to be very good at jumping through arbitrary hoops.