Yesterday I told a candidate "Using AI in our coding interview is encouraged" and his eyes sparkled. This was an experienced dude tired of leetcode bullshit.
Maybe AI will replace engineers, I don't know. Self-driving cars were just around the corner for 50 years. Now they exist in small pockets. Self-driving software engineers started ~2 years ago and my bet says AI will replace us some time in 2075. Until then we've got shit to do and engineers to hire.
Why you need great engineers
You need great engineers because knowledge expands fractally. Demos are easy, production is hard. AI generates lots of plausible code, but a person, you, has to sign their phone number and pager duty on the system. Do you trust what your AI wrote? Enough to own the system? ๐
My policy for merging pull requests is simple:
โ Swizec Teller (@Swizec) February 3, 2026
we have your phone number
when you write code with AI, it's still your phone number
People pay for a reliable service, not a pile of code and some homework. The future is SRE โย great software engineers own the systems they build. Accountability and all.
So, how do you hire engineers that get shit done, sometimes with AI? Here's what I've found.
Interviews aren't perfect
With good interview design, you can get a ~70% correlation with on-the-job performance. And you'll never find out about the false negatives.
Best you can do is a repeatable process with low noise. Prepare criteria ahead of time and evaluate by multiple interviewers to reduce day-to-day variation.
The whole process is probabilistic.
Look for knowledge expanding fractally
My favorite screening question is "Tell me about a past project โย what was it, what did you build, how did it go and then we'll take it from there". Then I keep asking followup questions.
The more you worked on something, the more detail you'll know. You find fractal knowledge when you dig in. Ok the foobinator talked to the bazingulation, but how? What happened?
Oh you released to customers and it didn't work. But how did you know? What did you learn? How did you fix it? How did you even know this was something to work on in the first place?
My favorite candidates could keep going for hours. Every answer uncovers 5 more details we could talk about.
You quickly notice what they didn't work on. Candidates talk around those details. Never quite diving in. The more you ask, the more pussyfooting you get.
System design interviews
The next opportunity to look for fractal details is a system design interview. This is where you design a toy system, draw boxes and arrows on a whiteboard, see how candidates think through a problem, and what questions they ask.
Candidate questions are important.
We need you to get us over the water, not build us a bridge. If we could think of everything, we'd ask AI to write the code. How you push back, question assumptions, clarify details, and think of operational concerns is important.
System design interviews are great for leveling. They tell you where the candidate has hands-on experience and what they've only read about. Reading (and managing or vibe coding) gives broad high level understanding. Doing the work gives you fractal details.
You're looking for the illusion of explanatory depth โ we think we understand things because they're familiar. But when you try to explain, you find the edges of your understanding.
Like Phil Knight said in Shoe Dog โย "I asked every sales leader how they teach sales. They gave vague answers. But the guy I hired said holy shit dude we don't have the time and pulled out a 300 page binder".
Give them all the tools and see how they do
The coding interview is where you answer "Can the candidate take all this understanding and ship?".
Leetcode in my opinion does not answer this. The problems are too chewed up and clean. We don't have a PM to chew the steak for you. You'll need to understand the business domain, talk to people, and figure it out.
If we could write a clear enough spec, we'd just ask AI to code it up. We hire engineers for their brains not their typing skills.
So here's the setup:
- Stubbed out codebase. Models, database, bit of code, a few tests.
- Clear business problem
- API documentation
- Auth credentials for the API
You get to use AI, Google, talk to the interviewer, pair on the problem and figure shit out. By the end you'll have a working script that talks to a database, reads and writes a 3rd party API, maybe even a test or two. It's a backend script so tests are important.
While we work on the script, we can talk about operational concerns. How do you keep it reliable? What do errors look like? Can you build a self-healing system? What needs to change in 18 months when we're a completely different company with more scale and 3 people now working on this script?
It's a fun interview. Even more high signal than I thought when designing the question. My favorite is that you read the question and go "Oh that's it?" and then the details come out as you build.
You learn a lot about how a candidate navigates unknown codebases, asks business questions, reads documentation, iterates towards a solution, structures code, and yes leverages AI to ship fast but not slop.
That is to say: Using AI raises the bar. We can build more interesting things in 1 hour.
Cheers,
~Swizec
PS: it's early days. I don't know yet how this interview performs over time. One point of friction are subtle differences between AI systems. Looks like how you speak to Claude vs Cursor vs Copilot may matter and throw off some candidates.
Continue reading about Software engineer interviews for the age of AI
Semantically similar articles hand-picked by GPT-4
- re: The Industrialization of IT
- What if tech interviews aren't bullshit
- Coaching AI to write your code
- Yes, AI will "take" your job. No, you won't mind
- Why a coding AI like Github Copilot won't take your job
Scaling Fast book free preview
Enter your email to receive a sample chapter of Scaling Fast: Software Engineering Through the Hockeystick and learn how to navigate hypergrowth without burning out your team.
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help ๐ swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers ๐ ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are โค๏ธ

