This question pretty much told me if there was any point in asking further questions or not, because if someone had trouble with that question, they typically had trouble with all other SQL questions I had for them.
Your original strategy is undershooting with the question. You ask the simplest question first, and when they fail to answer that, you know that there's no point in asking any harder questions. If they do answer it, you follow up with additional questions to further refine your read on their skill level.
So my question is, how should I approach the technical portion when testing these candidates as opposed to less experiences engineers?
However, in this case, you are already under the assumption that the applicant is on the high end of the spectrum and that starting from the easiest question is going to take a long and uninteresting amount of time.
So do the opposite. Overshoot. Ask your hardest question first. If they manage to answer that to your satisfaction, you know that there's no point to spend time asking any simpler questions. If, however, they don't fully answer it, that's your cue to start asking additional (simpler) questions to further refine your read on their skill level.
The principle is the same as before, you're just starting from the other end.
Secondly, I suggest just listening to their own confidence when talking about work experience. This is not an ironclad tactic (confident idiots do exist), but more often than not you're able to identify if someone is experienced based on how comfortable they are explaining a complex story.
Ask them to talk about their favorite project, or the hardest bug they've ever had to deal with, or anything that gets them to talk you through a work process they went through.
Even if you are not as experienced as them, you'll most likely notice whether they are experienced or not. To paraphrase Steve Hofstetter:
I've never flown a helicopter. But if I saw one in a tree, I'd still say "That pilot f***ed up". He's not supposed to be up there. That is pilot error.
Try to make sure the topic is about something they're very familiar with, rather than something you're familiar with, because this will negatively impact your reading of their confidence if they're talking on a subject that is not as familiar to them.
I just want to stress here that this by itself is not sufficient, as you could stumble onto a confident idiot who sounds very reassured but in reality misses the mark completely.
This is why you can't just skip the technical questions entirely. But it is reasonable to skip the easy questions for an (alleged) experienced applicant, and simply rely on their ability to answer the difficult questions.
Do I just ask more difficult programmatical questions? Do I focus on design?
That wholly depends on the specific role, but that shouldn't come as a suprise. Any questions you ask of any applicant should be relevant to the role you're interviewing for.
Is it still useful to ask them basic questions?
There's a difference between outright asking a basic question, or noticing that while talking about something else, the applicant made a basic error or lacks basic knowledge.
The former is arguably pointless with experienced candidates, but you should still be on the lookout for the latter, and when encountered, drill into it, even if that means asking a simple question.
That being said, it's not impossible for you to ask all of your questions, both simple and complex, of any applicant. It may not be as time efficient, and it may stifle the conversation, but if that is what your company deems necessary to vet an applicant, then that's how your company has chosen to run its interviews.