I’ve interviewed many candidates and been interviewed plenty of times myself

Most technical interviews still work like a lottery: an interviewer turns the conversation into an exam, quizzing a candidate on specs to guess how they’ll perform on the job. I leaned on the same methods when I started interviewing. Only after running interviews in person did I notice that real conversation and a direct read on the person mattered more than any quiz score. Knowing how a hash map resolves collisions or how a specific framework handles state doesn’t tell you how a developer works on a team, debugs a production issue, or finishes a project under a deadline. Algorithm knowledge and framework details are worth discussing, but treating them as a pass/fail test misses the actual job. Ask about projects the candidate has shipped: what they built, what broke, how they fixed it, what they’d change next time. Work history predicts performance better than a quiz on syntax. AI tools have made the old approach worse. A language model today can answer most framework trivia faster and more precisely than the average developer. Testing someone on facts any AI assistant already knows measures the wrong thing, and plenty of candidates now run those same assistants during take-home tasks or even live interviews. Some companies respond by writing harder, trickier questions to catch candidates using AI help. That solves the wrong problem. The exam format failed before AI entered the picture. When I started hiring people through conversation and in-person presence instead of tests, those candidates stayed at the company far longer than the ones who passed a spec exam. Judge developers by what they’ve built and how they reason through problems. Memorized specs don’t predict that.