Lessons from Conducting 50+ Technical Interviews
May 24, 2026 · 6 min read
Two years and fifty-plus interviews later, I think about technical hiring in a completely different way. The evolution wasn't planned — it came from watching patterns repeat, making mistakes, and slowly realising that what I was measuring in the early days wasn't what actually mattered.
I didn't expect interviewing other engineers to teach me as much about myself as it did about them.
When I started conducting technical interviews, I approached it the way most engineers do — prepare a list of questions, assess the answers, make a decision. It seemed straightforward. Two years and fifty-plus interviews later, I think about technical hiring in a completely different way. The evolution wasn't planned. It came from watching patterns repeat, making mistakes, and slowly realising that what I was measuring in the early days wasn't what actually mattered.
How I used to run interviews — and why it didn't work
My early interviews were interrogations, not conversations. I'd ask direct technical questions — syntax-heavy, language-specific, the kind where there's a right answer and a wrong one. "What's the difference between X and Y?" "How does Z work?" I'd evaluate based on how close the answer was to what I had in my head.
Looking back, I wasn't assessing engineering ability. I was testing memorisation.
There were also moments where I didn't explain a question well enough, and the candidate visibly struggled to understand what I was even asking. I had to reiterate. I thought it was their problem. It wasn't — it was mine. A poorly framed question doesn't reveal anything useful about the candidate. It just creates noise.
The shift: from interrogation to conversation
At some point I started noticing that the candidates who gave the cleanest, most technically precise answers weren't always the ones who performed well once they joined. And some candidates who stumbled on specific questions turned out to be excellent engineers.
That made me question what I was actually trying to learn in an interview.
So I changed the format. Instead of firing questions, I started making interviews feel more like engineering discussions — talking through problems together, asking candidates to walk me through their thinking, leaving space for them to ask questions back. The goal shifted from "does this person know the right answers" to "how does this person think through problems they haven't solved before."
The difference in signal was immediate.
Three patterns that changed how I think about hiring
The impressive CV that fell apart in production. I've interviewed candidates with strong CVs who froze completely when I asked: "How would you debug this issue in production?" Not a trick question. A realistic scenario. But they couldn't think through it step by step — couldn't articulate what they'd look at first, what signals they'd use to narrow the problem, how they'd reason under uncertainty. The CV said one thing. The conversation said another.
The modest CV that showed exactly the right instincts. The opposite happened too. A candidate who struggled with a specific technical question paused and said something like: "I don't know this off the top of my head, but here's how I'd go about finding out." Then walked me through their reasoning clearly and confidently. That candidate got the role. The ability to navigate the unknown matters more than having the known already loaded in memory.
Textbook answers with no ownership behind them. Some candidates can answer every question correctly and still leave you with nothing. The tell is when you ask them about a decision they made on their own project — something they built, a tradeoff they navigated — and they can't explain why they made the choices they did. They know the theory. They haven't actually wrestled with the problem. That gap shows up quickly when the work gets hard.
The internship candidate observation
One of the more counterintuitive things I've noticed: some internship candidates would comfortably outperform engineers with one or two years of experience.
It's not about knowledge. Junior engineers often have more accumulated syntax and framework familiarity than final-year students. The difference is hunger and curiosity. The best internship candidates approach problems with a kind of open energy — genuinely interested in emerging technologies, actively trying to stay relevant in a field that's changing fast. They haven't yet learned to be defensive about what they don't know.
That quality is harder to find than technical ability and harder to teach. When I see it in a candidate at any level, I pay attention.
What this means in a world where AI writes the code
I've stopped caring whether a candidate can remember syntax. In a technical interview today, if someone forgets the exact method signature for something, I tell them to look it up — just don't look up the solution to the problem we're working through together.
The reason is simple: raw coding ability is increasingly assisted by AI tools. The question of whether someone can independently produce syntactically correct code is less relevant than it was three years ago. What's not assisted — at least not yet, not reliably — is judgment. Knowing what to build and why. Knowing what's actually wrong when production behaves unexpectedly. Knowing when a technically correct solution is still the wrong choice for the team or the business.
That's what I'm trying to understand in an interview now.
What conducting interviews taught me about myself
The shift in how I run interviews forced me to be more honest about what I actually value in engineering — and in myself.
When I started asking candidates to explain the reasoning behind their own decisions, I became more conscious of whether I could do the same. It's easy to make decisions by instinct and call it experience. Being in a room where you're asking someone else to articulate their thinking makes you examine your own more carefully.
It also made me a better communicator. Realising that a poorly framed question was my problem, not the candidate's, translated directly into how I write requirements, how I run standups, and how I give feedback. Clarity is a skill. It doesn't come automatically with seniority.
If you're walking into a technical interview tomorrow
Don't spend the night memorising syntax.
Spend it thinking about the hardest problem you've worked through recently — what made it hard, how you approached it, what you'd do differently. Think about a time you didn't know the answer and what you did about it. Think about a decision you made and why you made it.
The most valuable thing you can demonstrate in a technical interview isn't what you know. It's how you think when you don't know — and whether you have the curiosity to keep figuring things out in a field that will keep changing faster than any of us can fully keep up with.
That's what I'm looking for on the other side of the table. And honestly, it's what I'm still trying to build in myself.
If this resonated, I'd be curious to hear how you approach technical interviews — whether you're the one running them or the one sitting across the table.