Do yourself and your candidates a favor. Just ask questions designed with "bullcrap detector" in mind. That should be your main goal as a technical interviewer.
If a person claims that they know a certain subject or framework, ask a couple questions that any person with that experience would know. Not should know, would know. Ask leading questions starting with "Tell me about a time when..." and "if a client wanted you to make a site that did _____, how would you approach it".
The problem with most technical interviews is that they turn into "gotcha" sessions where the interviewer presents a series of questions that expose their own biases, hoping to catch the candidate (or that if the candidate isn't caught, impresses the interviewer).
The fact is that there's no way a technical interview can tell you how well a person is going to work out for you so you need to use it as a screening tool. Have the person talk about experiences, approaches and then use some basic "BS Detector" questions. You're smart, I'm sure. You can tell whether a person is full of crap or not by the answers to general questions. Leave the hyper-specific questions and the "gotcha" questions, and things which any sane person would just look up to the certification tests.
Screen them, don't test them. And as I said, the more open-ended the better. Get them to talk about the technology though. Just because a question is open-ended doesn't mean you should let them be vague. Ask something open-ended and then, when possible, ask why. There is where people won't be able to BS you as easily. Or "why not use ____ instead?" My point is that the more people talk (and are required to talk about the technology, not just general approaches in vague ways), the more you'll be able to tell about their actual knowledge.