AI Exposed What Your Interview Process Already Missed
The interview process has been broken for a long time. AI exposed it.
The industry is having a full-on panic attack about what AI means for hiring engineers.
Do we still test for coding skills? Do we need different technical screens? Is the traditional interview dead?
Here’s the uncomfortable answer: if your hiring process is in trouble right now, AI didn’t break it. It was already broken.
The Engineer’s Job Is Shifting
Let me tell you what I’m actually watching happen on engineering teams.
The daily work is changing fast. Engineers are spending less time writing code from scratch and more time doing something harder: writing clear requirements, describing intent, reviewing what AI produces, and figuring out when the output is wrong.
That last part matters more than people realize. AI is confident. It will produce something plausible-looking whether it understood the problem or not. The engineer sitting in the loop has to know enough about the big picture to catch it when the output is technically correct but completely wrong for the use case.
The engineers thriving in this environment aren’t the ones who can recall the right algorithm under pressure. They’re the ones who can look at a problem from the user’s perspective, articulate what needs to happen, and hand that off in a way that produces something useful. They understand what they’re building and why before they start.
That’s product thinking. It’s always been the highest-leverage skill in software engineering. AI just made it impossible to fake.
Product Thinking Is the Skill That’s Rising to the Top
To use AI well, an engineer has to understand the big picture.
If you don’t know what problem you’re solving or why it matters, you can’t write a good prompt, you can’t review the output critically, and you can’t catch it when something’s gone sideways. You also can’t push back when the requirements are unclear or the scope is wrong. You’re just a relay for bad instructions.
This is what separates engineers who make AI a force multiplier from engineers who use it to produce faster garbage.
The engineers who asked “why are we building this?” before writing a single line of code are the ones who are dangerous in the best way right now. They always were. They’re the engineers who feel ownership over the product, not just the ticket. AI just made that quality more visible, and more valuable, than it’s ever been before.
If your team is full of people who wait to be told what to build, AI is going to accelerate your problems, not solve them. If your team is full of people who understand the users and the outcomes, AI is going to make them three times as productive.
So how has this changed how we hire engineers?
We Stopped Coding Challenges Years Ago
At Full Scale, we receive hundreds of job applications a month for software engineers. That makes it nearly impossible to give each person multiple rounds of interviews.
So like many companies, we used to rely on multiple choice and online coding tests to help weed out applicants so we could focus on the best ones.
Then we realized we were making a few major mistakes.
The best software engineers aren’t going to do your stupid test.
Those tests are super easy to cheat on with AI.
They don’t even test what really matters.
They tell you almost nothing about how someone actually thinks. How they handle ambiguity. Whether they ask good questions before diving in. Whether they understand what they’re building and why it matters.
The companies that designed their entire hiring process around coding challenges were never finding the best engineers. They were finding the engineers who were best at coding challenges. Those are not the same people.
Interview for How People Think
Instead, we interview for judgment and curiosity.
We give candidates a real problem with context and constraints and some missing pieces. Not a whiteboard algorithm. Not a timed code screen. A genuine, open-ended problem that requires them to think.
Then we watch what they do with it.
Do they ask clarifying questions before they start, or do they just charge in? Can they explain their reasoning to someone non-technical? When they hit an edge case, do they flag it or paper over it? Do they have opinions about what matters most, or are they waiting to be told?
Those conversations tell you everything. You can see in one honest discussion whether someone thinks like an owner or like a ticket-taker. And it’s fast. You don’t need four rounds of technical screens to find out if someone has good judgment. You need one real conversation.
This approach also scales. Junior engineers can show you how they approach a new problem even before they have years of experience. Senior engineers can show you how they think about tradeoffs, not just solutions. The format works at every level in a way that algorithm screens simply don’t.
You can ask the same question to a junior engineer, senior engineer, or CTO and their clarifying questions and concerns show you the level they are at!
The Best Skills Were Never on the Coding Test Anyway
Here’s the thing nobody talks about in the “AI is forcing us to rethink hiring” conversation.
The skills that make a great senior engineer, a great tech lead, a great architect, were never tested by coding challenges in the first place.
And now? When AI is writing 90% of the code, testing someone’s ability to recall a sorting algorithm under a time limit isn’t just unhelpful. It’s almost completely irrelevant.
Engineers still need to recognize good and bad patterns in the code that comes out. That matters. But the real bottleneck isn’t coding speed anymore. It’s the quality of the requirements going in. If you can’t describe what you need with precision and context, it doesn’t matter how fast you can write code. You’re going to build the wrong thing quickly.
That takes product thinking. And you can’t test for it with a LeetCode problem.
The skills that actually separate good engineers from great ones at scale: software architecture, security, managing a team under pressure, build-vs-buy calls with incomplete information, knowing when to slow down and when to ship, communicating risk to a non-technical executive, knowing what good looks like and having the courage to say when it isn’t.
When people say AI is forcing them to rethink their interview process, what I actually hear is: they were hiring for engineers who could turn requirements into code.
That was always a low bar. Now you need engineers who can turn business problems into requirements and then into code. That’s a different job. And you can’t screen for it with an algorithm test.
You have to interview for product thinking.
If you want to build a team that actually thinks this way, I wrote the playbook for it. Product Driven is about exactly this problem: how to close the gap between engineers who execute tickets and engineers who understand the product well enough to own outcomes. That’s what makes a team AI-ready. Not the tools they use. The way they think.
Even more exciting, my book is now available for free. Head to fullscale.io/product-driven
to get your digital copy or audiobook
Good hiring was never about finding someone who could write the code. It was always about finding someone who understood the problem well enough to know what code to write.
AI just made that distinction impossible to ignore.