Same material, on video. The article below is the written version.
Most hiring managers come into an interview with a set of scripted questions. The rationale is simple and sound. They want consistency and to guard against their own biases. When all the interviews are done, they can make easy one-to-one comparisons and pick the best candidate. I'm not against this. There is merit to this kind of "level playing field", but unfortunately, it fails to answer a very basic question. Does the person match their resume? It's easy to pad one's qualifications with every skill under the sun, to inflate one's role at a previous job, to claim one has experience they do not actually have.
Let's face it, we're all recycling the same questions over and over again, and there's a good chance we grabbed them from the same list of common questions on the internet and tweaked them just a tad to add our own personal touch. Well, the candidate has probably done the same thing, looking at the same websites you did to figure out what they'll be asked. If they're diligent, which I guess is positive in its own right, they will have prepared well-crafted answers to these common questions. They will make a great first impression, but it will tell you almost nothing about the true depth of their knowledge, their ability to think on their feet, or how successful they'll be at helping your team drive toward its goals.
So, what's the solution to this? Make sure to ask them resume-specific questions. What I mean by this is, if they say they worked on a particular project, ask them about that project. It's so simple that I almost feel silly saying it, yet I see so few hiring managers actually doing this.
Don't stop with just a cursory question. Let one question lead to the next, digging deeper and deeper into the details. Don't let them get away with vague answers. A truly knowledgeable candidate will often pull you deeper into the conversation, asking clarifying questions and volunteering adjacent details. This works best for technical roles, but it probably works nearly as well with anything requiring extensive domain knowledge. I employ this in every interview, and it's stunning how well it works. You'd be amazed, or perhaps you wouldn't, at how many people claim experience they either don't really have or were only marginally involved in. I've seen people get very flustered when I start down this path, and it's not uncommon to get an initial response like, "Well, another team was responsible for that part," or "I just helped with a small part of that."
I tend to go three or four questions deep on any given project, and I will usually highlight two or three projects to ask about. When you find someone that can follow you that deep, you know you've found a real gem. The formula I like to follow is this. After you've gone through the introductory formalities of the interview, immediately dive into these project-specific questions. If they flounder or it's clear they've lied on their resume (let's be blunt, that's what they did) then you can cut the interview short. If, however, you like what you hear, now you can jump into some of those more generic technical and behavioral questions.
I have a lot more to say about interviews and hiring for small teams, but I think if you take this one small suggestion to heart, you will dramatically increase your chances of hiring talented people.