Interviewing and Hiring Software Engineers in an AI-Assisted Era

The engineering job market did not collapse in 2026; it split. Demand concentrated at the senior and specialist end, thinned out badly for entry-level roles, and left a narrow, fought-over band of mid-career talent caught in between. The shortage driving hiring decisions this year is a shortage of engineers whose judgment can be trusted to direct AI output, check it, and take responsibility for what it produces.

AI sped up the typing. It did not speed up the judgment. That distinction explains why demand concentrated so heavily around engineers who can direct AI tools rather than be replaced by them, and it explains the barbell shape the market has taken: heavy hiring for AI, security, and staff-level roles, soft hiring for entry-level positions because AI now performs much of the work a junior engineer used to do, and a thin band of senior talent stuck in the middle, pulled at from both directions. The engineers losing ground in this market are the ones whose job was to read a ticket, write the code, and hand it back, with no stake in the requirements behind the ticket or the architecture around it. AI tools now do that kind of work cheaply and fast.

The role itself has moved upstream. Engineers now spend more of their time clarifying ambiguous requirements, setting constraints before any code gets written, and reviewing output for logic errors, security gaps, and architectural fit. They spend less time on first-draft generation, because that part of the job has been largely absorbed by the tools. One staffing firm, Full Scale, illustrates this with its own hiring practice: it stopped giving coding tests and moved the practical evaluation into live conversation, on the premise that watching how someone reasons about a problem reveals more than watching how fast they can produce syntax. That change is a preview of the argument the rest of this piece makes. If the job has moved upstream, the interview has to move with it.

What the traditional technical interview was selecting for

The standard technical interview, built around whiteboard problems, timed coding screens, and take-home assignments with predictable answers, was never really testing for engineering judgment. It was testing for speed and accuracy at pattern matching under artificial time pressure. That was a reasonable proxy for production competence, because fast, accurate code production was the scarce resource a hiring team needed to find back then. It is a much weaker proxy now, because AI models routinely outperform humans at exactly that task: fast, accurate pattern matching against well-defined problems.

The format has a specific blind spot. It never asks whether a candidate can catch a subtle logic flaw buried in a block of AI-generated code, or whether they know which categories of problems a language model is likely to get wrong, or whether they can take a vague, underspecified request and turn it into a concrete, well-bounded engineering task before a single line of code gets written. None of that appears in a 45-minute algorithm screen, while all of it appears on the job, every day, for engineers now working alongside AI tools.

Some hiring teams will object that coding tests exist to establish a baseline, and that removing them risks letting in candidates who cannot actually code. That objection misreads the argument. The case here is for relocating where the competence baseline gets measured, not for dropping it. Timed pattern matching under pressure made sense as a proxy when code production itself was the bottleneck. In an AI-assisted environment, the bottleneck has moved, and the baseline has to move with it.

How AI-assisted cheating made a broken format untenable

Whatever residual signal the traditional interview format still carried has been undermined by the same AI capability reshaping the job itself. A new class of overlay tools now feeds candidates real-time answers during live video interviews and coding rounds, running invisibly on the candidate's own machine in a way that standard screen-share and proctoring tools cannot detect. Bloomberg reported on this problem, describing a landscape where the most common signal a technical interview tries to collect, can this candidate solve this problem under time pressure, has become the easiest signal in the entire process to fake.

Banning the tools outright does not solve the problem. Cheating rates in software and data engineering interviews have reached very high levels even at companies with explicit prohibitions in place, and the more capable overlay tools are specifically built to evade the kind of detection a standard proctoring setup relies on. A format whose central test can be gamed invisibly, at scale, and without technical sophistication on the candidate's part has stopped producing a usable signal.

The cheating crisis matters here for what it exposes about the format's design, not simply because it makes life harder for recruiters. A test built to measure whether someone can solve a problem alone, under pressure, in real time, was always a crude proxy for whether that person can do the job well. AI-assisted cheating just made the gap between what the test measures and what the job requires too wide to paper over. The interview did not just get harder to trust. It stopped measuring much of anything.

The security gap that redefines what "good code" means for hiring

AI models have gotten remarkably good at producing code that runs. But they have not gotten correspondingly better at producing code that runs safely. Across at least two measurement cycles, the rate of security flaws in AI-generated code has stayed flat, even as syntax correctness has climbed toward near-perfect. That gap, between code that compiles and code that is safe to ship, is the gap a 2026 hiring process needs to be built around, because it is the gap that now defines what "good code" actually means.

There is a second effect compounding the first. As AI raises how much code a single developer can produce, less of that output gets reviewed per unit of time. Even if the rate of flaws per line of code held perfectly constant, more flawed code would still reach production, because review capacity has not scaled the way output has.

A Stanford study led by Perry and colleagues on AI-assisted development found something sharper still: developers who used AI coding assistants wrote measurably less secure code than a control group working without them, and rated their own output as more secure than the control group rated theirs. That mismatch, a false sense of security sitting directly on top of a real decline in security, is the exact failure mode an interview process now has to be built to catch. An engineer who trusts flawed AI output more than a less-assisted peer trusts correct output is a liability precisely because the confidence feels earned.

Full Scale frames the most valuable engineer of 2026 as someone who owns the entire software development lifecycle personally: reviewing what the AI produces, writing the tests rather than waiting for QA to catch problems downstream, and watching the analytics after launch to see how the system actually behaves. AI acts as a force multiplier inside that workflow, not a replacement for it. If an interview never asks a candidate to critique or correct a piece of code, AI-generated or otherwise, it misses the one skill that an AI-assisted team needs to ship something safe.

What companies that redesigned their interviews changed

A handful of companies have already rebuilt their technical interviews around this logic, and the pattern across them is consistent: move away from testing whether a candidate can produce code alone under pressure, and toward testing whether a candidate can direct, evaluate, and improve AI-generated code in something closer to a real working environment.

Google is piloting AI-assisted coding interviews in which candidates use Gemini directly during the assessment. Interviewers evaluate AI fluency as its own category, looking at prompt engineering, how carefully the candidate validates the model's output, and how they debug when that output turns out to be wrong. Google describes the format internally as "human-led, AI-assisted," a label that puts the human's judgment, not the model's output, at the center of what gets scored.

Canva has gone further on the tooling side: backend, ML, and frontend candidates are now expected to use tools like Copilot, Cursor, and Claude during their technical interviews. Canva redesigned its interview questions to be more complex, more ambiguous, and closer to what a real production problem looks like, because the old format, run without AI tools in the room, had stopped producing any signal about the skills that actually matter once a candidate is hired.

Coinbase rebuilt its process in three sequential phases. A frontend pilot ran in the second half of 2025. That expanded into repo-based backend exercises, candidates working inside an existing codebase. By March 2026, Coinbase had rolled out a company-wide "AI Fluency" signal, built around three dimensions: Usage, Application, and Understanding Limits. That three-part framework is the clearest public articulation anywhere of what AI fluency means as a hiring criterion, and it gives the rest of this argument its shape.

The three things a redesigned interview needs to assess

Coinbase's three dimensions, Usage, Application, and Understanding Limits, map onto a general model any hiring team can build from, whether or not they adopt Coinbase's exact process.

Usage asks whether a candidate can prompt a model with purpose: specifying constraints clearly, iterating on an answer that comes back wrong, and debugging when the model produces something that looks plausible but is not, a skill that can be taught and observed directly. It appears in a session where candidates work a realistic problem with AI tools available, with the interviewer watching how the candidate works the tool, not just grading the final output.

Application asks something harder: can the candidate take what the AI produces and judge whether it is architecturally sound, correctly scoped, and workable against the real constraints of the system it needs to live in? This is the judgment the market is currently paying a premium for. Code-review exercises built on AI-generated output are the most direct way to test it. Hand a candidate a plausible but flawed piece of generated code and ask them to critique it. The quality of that critique, what they catch, what they miss, how they reason about the tradeoffs, is the signal. It is the same principle behind Full Scale's decision to move its practical check into live conversation: watching how someone reasons about code in real time says more than watching whether they can recall a pattern under pressure.

Understanding Limits asks whether the candidate knows where AI output tends to fail: security, edge cases, domain-specific correctness, regulatory constraints particular to the system they would be working on. The Stanford finding on false confidence is what makes this dimension urgent, not academic. A direct question can surface it quickly: here is a piece of AI-generated code for a payments endpoint, what would you check before merging it and why? A candidate who has never thought carefully about where models fail tends to reveal that within a minute or two of being asked.

What the interviewer's own skill gap means for implementation

None of this works if the people running the interviews are still applying the instincts they built for the old format: judging confidence, fluency, and speed, rather than judging the quality of someone's reasoning about AI output. An interviewer who has never personally watched a skilled engineer work with AI tools in real time will not reliably know what good looks like when it is sitting across from them. Left without that reference point, interviewers default to the proxies that are easiest to notice, polish and confidence, even when those proxies have little to do with the judgment the new format is trying to measure.

Full Scale's reading of the 2025 DORA research offers a framing that applies directly here: AI amplifies whatever is already present in a process. A strong interviewer gets a sharper signal out of a redesigned, AI-assisted format. A weak interviewer just runs the new process without understanding what it is supposed to measure, and gets noise dressed up as signal. Redesigning the questions and the format solves only half the problem if the evaluators have not been brought along with it.

The practical fix is calibration. Interviewers need to watch recordings of strong and weak candidates working through AI-assisted problems side by side, the way engineering teams calibrate judgment during code review, instead of relying on an abstract scoring sheet alone. That kind of calibration also addresses a harder problem: hiring managers already suspect high rates of AI-assisted cheating under the current format, and a new format that explicitly permits AI tools in the room will force interviewers to judge whether a candidate is using AI well or hiding behind it. It takes a clear rubric and interviewers who have practiced applying it before it becomes a judgment call they can make reliably, under time pressure, with a real candidate sitting in front of them.