How I Interview Software Engineers, Post AI Code Gen.
How to interview in a post code gen world
For years, I’ve heard how companies struggle to design and run effective interviews for software engineers. In turn, candidates grow frustrated with whiteboard exercises or, worse still, grinding through LeetCode-style questions. The reason? These methods often fail to reflect real-world performance. They reward memorization over a core strength every programmer should bring: the ability to break down complex problems into clear, actionable tasks , a skill applicable to both building or debugging.
On top of that, most interview practices haven’t adapted to the way engineers actually work today. GenAI and coding assistants are now commonly used developer tools meaning syntax recall is less important, in fact the skill most relevant of all now, is architectural and more about the fundamentals. Coding assistants improved at a blistering pace in 2025, but without a human overseeing the output, structure, best practise and maintainability fly out of the window - so understanding what good software looks like, is a more prized asset then ever.
Over time, I’ve developed my own approach, shaped by experience and feedback from both interviewers and candidates which works just as well in todays AI enhanced world. It’s simple, effective, and flexible—and it reveals far more than raw coding ability. I’m sharing it here in the hope that it might help others rethink their process and perhaps be useful.
The Setup
The preparation is minimal. You have a senior engineer create a lightweight technical design document that outlines a self-contained application. This document specifies the required features, core stack components (mostly the language, frameworks etc), and describes what the end result should look like.
A particularly effective example I often use is a simple client-server architecture - e.g. a client sends information to a server. This scenario works well because it demonstrates whether someone has decent grounding in the fundamentals; HTTP handlers, Proper use of headers, the request / response pattern, error code handling etc . If domain expertise is needed, you just mix that in. I have typically interviewed for security engineering roles, so quite often a payload is encrypted, keys need to be generated and exchanged security etc.
The Interview
The interview is 2 hours, this might seem long, but it should be kept in mind several screening interviews would already have taken place. If the tech interview is reached, both company and candidate more certain on the hire.
The execution is straightforward: candidates share their screen over hangouts/zoom etc, use their preferred tools, and start coding. AI is allowed, but should only really be for bash style autocomplete and anything generated by AI should be explainable by the Engineer (so they are effectively reviewing the AI generated code). They are free to Google and use ChatGPT etc to ask questions (as you would during a normal working scenario).
We don't expect someone to recall arcane syntax or function signatures.
If they don’t complete the exercise in time, it’s not a failure - they can verbally walk the interviewers through what they would do next. Quite often interviewees express that they would like to finish it and send it over, but that is entirely up to them.
The interviewers should remain friendly and approachable, you want the candidate to do well, there is no need for poker face, catching someone out, but at the same time you don’t write it for them. Just offer friendly nudges and prompts when (if) they get stuck..this is important as you will see later.
What You Actually Learn with this approach.
Architecture Awareness – The first few minutes often reveal how a candidate approaches complexity. Experienced engineers typically start by mapping out the solution: sketching stub structures or functions, defining the overall architecture, and breaking the problem into logical chunks. This approach not only clarifies their plan but also helps them estimate the rough time needed for each task.
By contrast, less experienced candidates often dive straight into the weeds - spending twenty minutes on CLI argument setup or debugging a single component before they’ve grasped the broader problem. As a result, they burn half the interview on minutiae, while pressure continues to build.
Handling Knowledge Gaps - This is where the red flags often surface. The truth is , the longer you have been in tech, the clearer it becomes that nobody knows everything. So what matters is how someone responds when encountering unfamiliar concepts.
A good sign is the candidates say something like "I haven't used this library before, let me check the documentation" or "I'm not sure about the syntax, mind if I Google it?" They're comfortable revealing they don't know something.
Red flags emerge when instead they become defensive. They rationalize, deflect, or create elaborate justifications for why they don’t know something.
This defensiveness often translates directly to how they handle code reviews or peer feedback.
Receiving Guidance When candidates hit a roadblock and you offer a friendly nudge, their reaction can often be quite telling. Good signals might be "ah, that makes sense! Thanks I did not know about that" and they incorporate feedback and move on. Others become defensive, as if accepting help diminishes their expertise.
This moment predicts how they'll handle collaborative peer review and mentoring relationships. Your team also gets a view as to what the person will be like to work with.
Response to Different Voices One of the most revealing aspects involves having different team members participate, which is where I prefer both diversity in the interviewing team. How does a candidate respond when a senior female developer offers a correction compared to a male colleague?
The subtle differences can reveal unconscious biases that can seriously impact team dynamics, which is something you should protect fiercely. Some candidates are equally receptive regardless of who's speaking. Others show clear patterns of dismissiveness based on the speaker's gender, age, race or perceived seniority. That is your toxic signal that states absolutely do not hire if you want a high performing team with psychological safety.
Why This Works So Well
Traditional technical interviews optimize for the wrong things. They test algorithmic memorization, and performance under artificial pressure. But day-to-day development work is collaborative, iterative, and involves constant learning and is much more than just coding.
To make this approach work effectively:
Choose relevant problems - Use scenarios your team actually encounters
Create psychological safety - Make it clear you're not trip them up or catch them out.
Include diverse interviewers - Have different team members participate
Focus on process over perfection - You're evaluating approach, not flawless execution
Take notes on interactions - Document how they respond to different types of feedback
Technical skills are necessary, but they’re only part of the whole, and that’s becoming even more true as we enter the new era of AI-driven tools. The developers who thrive long-term tend to combine competence with humility, curiosity, and the willingness to learn from others. In my 20+ years, from a junior engineer to a distinguished engineer and CTO, I’ve seen a clear pattern: the best engineers are the ones who stay humble, remain hungry to learn, and continually adapt their craft as the landscape evolves.
The goal of interviews isn’t to identify a “coding machine.” or the 10x bullshit notion that was bounced around for far too long. We already now have those built into our tools with AI. We also don’t need someone who learns by rote - neural networks are pretty good at that too. What we truly need are people we want to collaborate with every day: engineers who can tackle complex, ambiguous problems in unique ways, while elevating those around them.
Ultimately, great interviews should surface not just technical competence, but also adaptability, creativity, and the human qualities that make someone a trusted teammate. That’s what sets apart the people who don’t just write code, but who build systems, teams, and futures worth being part of.