I have an interview process that's both easy and hard. It's kind of a "choose your own adventure" style interview. I explain upfront what the process will be,

I have an interview process that's both easy and hard. It's kind of a "choose your own adventure" style interview. I explain upfront what the process will be, that during the interview "I don't know" is a preferred answer than BS. Then I start with this question: "Your task is to take some data in from a user, store it, and then present it back to the user. How do you do it?" Based on their answer and follow up questions, I follow them down the path of their preferred stack. This is rare, but I love it when prior to answering, a candidate asks me clarifing questions, like "how many concurrent users will the system need to support? What sort of performance is necessary?" Etc... Many just assume that I'm asking about web development, so if they go down that path I challenge their assumptions, and follow up asking about their reasoning. If they pick a framework, I ask what the advantages and disadvantages there are to that framework and how it compares to others. Same with databases, etc.. It becomes pretty clear quickly what sort of level they're at. Many times the answer on a framework question is "that's what I used at my last job". That's not necessarily a poor answer, but it is informative. I try hard to make it a casual conversation, like the sort you'd have with a technical stranger at a bar or something, though I understand that's impossible given the power dynamics and stakes involved. Still, I try. So far, it seems to work pretty well for me. I have the luxury of keeping my team small, so I don't have to come up with a scalable "one size fits all" process, I'm able to keep it personal and relevant to the candidate and their experience.