AI changed how we write code. Why are we still interviewing developers like nothing happened?
Developers use AI to write code, debug, understand unfamiliar projects, and even design applications. Candidates use AI to prepare for interviews, recruiters use it to filter resumes, and interviewers can use it to generate questions and evaluate answers.
So, if everyone is using AI, what exactly are we testing anymore?
We’re adapting to a new way of working, but somehow, when it’s time to hire someone, we go back to the old rules.
You have 45 minutes. Here’s a problem. No AI, sometimes no documentation, and depending on the interview, you might not even be allowed to search for something.
But why?
I’m not saying developers shouldn’t know how to code without AI. Of course they should. But I think we’re missing something important about what makes someone a good developer today.
The Job Has Changed, but the Interview Hasn’t
Let’s say you’re working on an existing application and something breaks.
What do you do?
You investigate. You check logs, follow the data, read code someone else wrote years ago, search for documentation, maybe ask a coworker, and probably ask AI to help you understand what’s happening.
Then you try something. Maybe it works. Maybe it doesn’t. Maybe you discover that the problem wasn’t even where you thought it was. That’s development.
I’ve worked on problems where making a change was the easy part. The difficult part was figuring out which layer was actually causing the issue, especially when the behavior only happened in production.
You can spend hours investigating, make what looks like a perfectly reasonable fix, deploy it, and discover that the problem is still there.
AI can help you investigate, sure. But it doesn’t automatically understand every dependency, configuration, or decision someone made years ago.
Now compare that with an interview where you’re asked to solve an algorithm problem on a blank screen.
Algorithms, data structures, and fundamentals are important. But does solving that problem in 30 minutes really tell us how good someone will be at maintaining a complex application?
Maybe it tells us something. But is it enough?
Using AI Doesn’t Mean You Know What You’re Doing
Just because someone can generate working code with AI doesn’t mean they’re a good developer.
AI can give you a solution that looks perfect. The code is clean, the explanation makes sense, and everything seems fine. Until you deploy it.
Now something else is broken, a cache isn’t invalidating correctly, or you discover that the solution ignored an important dependency. And what happens next? You ask AI to fix it again? Maybe that works. But at some point, someone needs to actually understand what’s going on.
I don’t care if someone uses AI to write 90% of their code, as long as they understand what they’re building, recognize when something is wrong, and know how to verify the result.
Actually, if someone can deliver reliable solutions faster using AI, why would I consider that a disadvantage?
The problem isn’t using AI. The problem is depending on something you don’t understand.
But how do we distinguish someone who genuinely understands their work from someone who’s simply good at getting convincing answers from AI?
Are We Still Measuring the Right Skills?
Imagine two developers.
One knows algorithms, syntax, and framework details extremely well. They perform exceptionally well during technical interviews.
The other looks up syntax, uses AI frequently, and might struggle with a timed coding challenge. But give them a complicated production issue, and they might be the one who identifies the root cause and delivers a reliable solution.
Which one is the better engineer? It depends, right? Writing code, understanding architecture, investigating bugs, and making decisions under uncertainty aren’t necessarily the same abilities.
Now imagine both candidates complete the same assessment.
One writes everything manually. The other uses AI, reviews the generated code, catches a potential issue, and finishes in half the time.
Who performed better? And what if the second candidate didn’t understand the code at all, but happened to get the right answer? The final result could look identical.
Prohibit AI, and you’re removing a tool developers may use every day. Allow it, and you need to figure out how much of the result belongs to the candidate.
Are we measuring engineering ability, or how well someone performs under a particular set of artificial restrictions?
And What About the Interviewers?
A candidate uses AI to write their resume. A recruiter uses AI to screen it. An interviewer uses AI to generate questions, and the candidate uses AI to prepare answers.
At what point do we end up with AI systems evaluating content produced by other AI systems? And where does human judgment actually happen?
I’m not against using AI in recruitment. But if we expect developers to verify AI-generated code, shouldn’t we expect companies to verify AI assisted hiring decisions? If someone passes every technical interview and struggles with the actual job, was the interview effective? If someone fails a coding challenge but has years of experience solving complex production problems, did we identify a weak candidate or measure the wrong skills? How do we know our interviews are actually predicting who will succeed?
Maybe We’re Asking the Wrong Questions
I don’t think technical interviews are useless, and I definitely don’t think AI makes programming knowledge irrelevant. But software engineering is changing. The tools, the workflow, and even the skills we rely on are evolving. And AI isn’t going to stop improving.
So what happens when the tools become even better at writing code, debugging, and understanding entire systems? What will make someone a good developer then? And how will we recognize that person during an interview?
If we’re no longer developing software the same way we did ten years ago, why are we so confident that we should keep hiring developers the same way?
