Most interviewers don't ask enough technical questions to have any idea what a candidate knows or doesn't know. If their one or two questions happen to be something the candidate knows well, they'll call them a genius. If they happen to not know, they'll label them an idiot.
You can learn a lot more from 20+ rapid fire questions than forcing a candidate to eek out an answer to something they're not familiar with. And once you establish the areas they're familiar with, you can ask them truly useful questions.
The key is to look for people who have strengths and not worry at all about gaps in their knowledge. Anyone who has earned genuine expertise in one area will be able to do so in other areas.
Along these lines, I start out with very broad questions. Something like, "tell me how you'd troubleshoot a web service that's suddenly not accepting connections / suddenly performing badly." Different candidates will focus on different aspects of that problem depending on their background: low-level networking, cloud environments, application-level problems, databases etc. Based on their resume, I like to see if their expertise matches up with their experience. I like to see that they don't consider ONLY things within their expertise. I like to see if they can make reasonable guesses outside of their expertise without BS'ing me. I like to see if they have a good approach to exploring areas they're unfamiliar with and general problem-solving. I like to see if they recognize how valuable it is to have diagnostic / monitoring / change control tools in place and to have done pro-active testing. This can be tough to do with coding problems, but I still try give problems that should be familiar to experienced low-level C developers as well as high-level Python web devs and tailor my expectations to their experience. I'm more concerned with how well they've learned based on what they've done than if they've already learned what I'd like them to do.
At my favorite tech interview we debugged a real prod issue they had a few months before. The interviewer spent a few minutes sketching the basic architecture of the system on the whiteboard and then started with the customer complaint:
From there I went explained my debug steps and he acted as an oracle when I took an action
Me: "Have messages been lost or does a page refresh always fix it?"
"Messages haven't been lost"
Me: "I'd check our logs for anything obvious errors"
"Nope, everything appears normal"
...
Me: "What sort of logging do we have with the websocket vendor?"
"They have a live console but don't provide any persistent logs"
Me: "Can we scrape that to get logs we can correlate to the errors?"
"We did that, didn't find any errors around the time a user had an issue"
....
Me: "Can we try X Y Z to reproduce?"
"When we did that we discovered that the disconnect only happens after a user has opened a navbar menu."
...
"As it turns out there was a click handler on all navbar buttons that disconnected from the websocket. The buttons used to directly link to different pages, now some of them had submenus and opening that submenu caused chat to hang."
That's fair - I wouldn't be a good judge of this if I didn't have really good breadth myself. Often a candidate in his own are of expertise will go beyond what I can fairly judge and I end up having to do a bit of reading afterwards to confirm and / or assume they were correct.
I have a similar question to this that I like to use - "Tell me how software gets delivered where you work now (or a place you've seen it done well). Idea to Customer."
Where the candidate starts, stops and goes into detail are usually quite interesting.
You can learn a lot more from 20+ rapid fire questions than forcing a candidate to eek out an answer to something they're not familiar with. And once you establish the areas they're familiar with, you can ask them truly useful questions.
The key is to look for people who have strengths and not worry at all about gaps in their knowledge. Anyone who has earned genuine expertise in one area will be able to do so in other areas.
The other big mistake most interviews make is forgetting about the "Curse of knowledge" https://en.wikipedia.org/wiki/Curse_of_knowledge
I've seen people research the answer to a question before an interview and then expect candidates to be equally informed without that advantage.