AI Changed How Engineers Code. Why Are We Still Interviewing Them the Same Way?

There is a conversation happening inside hiring teams right now that probably sounds familiar. A candidate solves the coding problem cleanly, explains their reasoning, and passes the technical screen. Weeks later, on the job, that same person struggles to debug a failing test without an AI assistant walking them through it.

The immediate conclusion might be that the candidate cheated.

But there is a more uncomfortable possibility: the interview may no longer be measuring what we think it is.

A September 2026 analysis found that 38.5% of candidates showed signs of AI cheating in technical interviews between July 2025 and January 2026. That number rose to 48% in purely technical roles, and 61% of the candidates flagged for cheating still passed.

Those numbers come from detection signals rather than confirmed admissions, so they deserve some skepticism. But they point toward a problem engineering leaders can no longer dismiss as a few candidates secretly opening an AI tool during a coding screen.

AI has changed how engineers research problems, write code, debug systems, test implementations, and explore unfamiliar codebases.

So why are we still interviewing engineers as though none of that has happened?

The Skills Changed. The Test Mostly Did Not.

LeetCode style interviews became popular because they were a reasonable proxy for something useful. Give an engineer an unfamiliar problem, remove most of their usual tools, and see whether they can reason their way toward a solution under pressure.

For years, that correlated well enough with engineering ability to justify the format. The problem is that the environment around the test has changed.

Today, 63% of professional developers actively use AI in their day to day development process. Engineers increasingly work alongside tools that can generate implementations, explain unfamiliar code, suggest tests, identify bugs, and propose architectural approaches in seconds.

That does not make engineering knowledge irrelevant. It changes where that knowledge becomes visible.

Consider two candidates. One can solve an algorithm problem from memory without AI. The other regularly uses AI, but knows when the model is wrong, can identify a bad assumption, understands the architecture well enough to reject a poor suggestion, and can explain every decision that ultimately reaches production.

Which engineer would you rather have responsible for your system?

An interview that bans AI and primarily rewards unaided recall may be testing engineers under conditions that no longer resemble how they actually work. At the same time, simply allowing AI without changing what gets evaluated does not solve the problem either.

Any engineer would recognize the underlying issue: a test environment that no longer resembles production will eventually start passing the wrong things and failing the right ones.

AI Did Not Create the Interview Problem

Software engineers have joked about the disconnect between interviewing and actual engineering work for years.

An experienced developer might spend their days diagnosing production failures, reviewing code, reasoning about distributed systems, and making architectural tradeoffs. Then they start looking for a new job and spend weeks practicing algorithm puzzles they rarely encounter in their actual work.

AI did not create that disconnect, it made it much harder to ignore.

A typical coding problem has a known structure, clear constraints, and a solution that likely already exists somewhere in a model’s training data. Give that problem to a capable AI tool and a working answer can appear in seconds. Karat, a coding interview vendor, has estimated that roughly 80% of candidates use an LLM during coding tests even when AI use is explicitly prohibited.

Companies can respond with more monitoring, locked browsers, stricter proctoring, and better detection. But once a test becomes cheap to pass without demonstrating the skill it was designed to measure, making the environment more restrictive does not necessarily restore the signal.

The better question is not simply, “How do we stop candidates from using AI?”

It is, “What are we actually trying to learn about this engineer?”

From Producing the Answer to Owning It

Some companies are experimenting with a different approach: let candidates use AI, then change what gets evaluated.

Can they give the model useful context? Do they recognize when it makes an incorrect assumption? Can they explain why the generated solution works? Can they identify what they would change before putting it into production? Most importantly, can they tell when the AI is wrong?

A candidate who blindly accepts a plausible answer may still arrive at the correct solution. But once an experienced engineer starts asking why a decision was made, what happens under different constraints, or where the solution is likely to fail, shallow understanding becomes much harder to hide.

The interview stops asking:

Can you produce a correct answer?

And starts asking:

Can you be trusted to own one?

That distinction matters because AI has made producing code easier. It has not made taking responsibility for software easier.

Someone still has to recognize the security problem, the concurrency issue, the unnecessary dependency, or the assumption that will fail when production behaves differently than expected.

AI can generate an artifact. Engineering judgment determines whether that artifact should ship.

Make the Interview Look More Like Engineering

If companies want to measure that judgment, the interview probably needs to look a little more like the job.

Real engineering problems rarely arrive as neatly packaged prompts. They arrive as failing tests, incomplete requirements, strange production behavior, unfamiliar code, conflicting priorities, and systems carrying years of decisions.

That messiness can be useful.

Give a candidate a small repository with a failing test and ask them to investigate it. Use a take home exercise, then challenge the decisions during a live review. Let them use AI during a system design discussion, change a requirement halfway through, and see how they adapt.

There is also a simple exercise hiring teams can run today: take one of your current interview questions and give it to the AI tool your engineers use.

If the model produces a strong answer in seconds, ask what successfully completing that exercise actually proves.

Then give the candidate the tool. Introduce a bad assumption. Challenge an architectural decision. Ask what they distrust about the generated solution, what they would test before shipping it, and what happens when one of the original assumptions changes.

The AI output becomes less important than what the candidate does with it.

This does not mean every company should abandon algorithmic questions or make every interview AI assisted. Foundational knowledge still matters. But every hiring team should be able to answer one question clearly:

What does passing this interview tell us about how this person will perform on the job?

If that answer has become difficult to articulate, the problem is probably bigger than cheating.

Engineering Judgment Is Becoming the Signal

The exact statistics around AI use and cheating will continue to move. Detection methods are imperfect, AI tools will keep improving, and interview practices will adapt alongside them.

But the larger shift is already here.

AI has not made engineering judgment less important. It has made judgment harder to observe and more important to verify.

The strongest engineer may no longer be the person who can produce code fastest without assistance. It may be the person who knows what should be built, knows how to use the tools available to build it, recognizes when those tools are wrong, and takes responsibility for what ultimately reaches production.

That is also close to how we think about vetting engineers for Staff Augmentation engagements at Ardan Labs.

When we place a senior engineer with a client, the evaluation is not limited to whether someone can pass an isolated technical screen. Engineers are evaluated for technical capability, alignment with the client’s expectations and working style, and compliance requirements, with background checks run as standard practice.

The technical evaluation is conducted by engineers who have spent years building and maintaining production systems. They can challenge assumptions, follow technical reasoning, and distinguish between someone who can describe a tradeoff and someone who understands why that tradeoff matters inside a real system.

There is no interview format that makes hiring immune to the changes AI is creating. The goal is not to find one. The goal is to make engineering judgment visible.

Whether an engineer writes every line manually, works alongside an AI agent, or operates somewhere in between, the responsibility at the end is the same: understand the system, make good decisions, and know what you are willing to put into production.

AI has simply made it harder to mistake producing code for doing engineering.

If your hiring pipeline is struggling to distinguish real engineering judgment from fluent AI assisted answers, Staff Augmentation gives you access to engineers who have already been through that technical vetting process. You can also read more about how we approach evaluation and integration in How Ardan Labs Integrates Senior Engineers through Staff Augmentation.

Explore Staff Augmentation

Sources

AI cheating and interview data

• BirJob, “AI Cheating Broke Coding Interviews: Cluely, Onsites, and What FAANG Switched To in 2026” (September 2026)
• Connecting People, “38% of Tech Candidates Cheat With AI in Interviews”
• Engineering Playbook, “Coding Interviews in 2026 Are Harder Than Ever. Here’s What Changed”

Ardan Labs

• How Ardan Labs Integrates Senior Engineers through Staff Augmentation
• Staff Augmentation vs Outsourcing vs Hiring
• Ardan Labs Staff Augmentation