For most of the last two decades, the live coding interview held a privileged place in software hiring because it was, in theory, the closest thing recruiting had to watching someone actually do the job. That trust was not entirely misplaced. Decades of hiring research have consistently found that structured interviews and work-sample tests are among the stronger tools for predicting job performance, which is one reason technical interviews became so deeply embedded in engineering recruitment. Schmidt and Hunter's 1998 review of personnel-selection research put the average validity of structured interviews at about .51 and work-sample tests at about .54.
The resemblance to real work was the whole point.
AI has now complicated that resemblance. Between July 2025 and January 2026, Fabric says it analyzed 19,368 interviews on its platform and found that 38.5% triggered cheating flags. In technical roles, the figure was 48%. Those numbers come from a commercial platform with an obvious interest in interview integrity, so they should be treated as platform-specific findings rather than an industry-wide prevalence rate. Still, the direction of the problem is hard to ignore. The tools candidates use while writing software do not suddenly become irrelevant because a recruiter has opened a video call.
The more important question is no longer simply whether candidates are using AI. It is whether the interview format still measures what employers think it measures.
How widespread is this, really?
Fabric's data suggests AI-assisted behavior in interviews is far from a fringe issue, but the figures describe detection flags, not independently verified acts of cheating. Its analysis of 19,368 interviews found that 38.5% triggered cheating flags overall, while technical roles reached 48%. Fabric also reported that the rate rose from 9% in July 2025 to 45% by September and remained elevated through January. Fabric's published analysis provides the underlying methodology and limitations.
That distinction matters. A detection system can identify unusual behavior without proving why it happened. Someone who looks away from the camera, pauses in a particular pattern, or gives an unusually polished response may be using an AI assistant. They may also simply have a different interview style. Treating a platform-generated flag as a verdict would replace one measurement problem with another.
There is, however, a broader reason to take the shift seriously. The tools developers already use in their day-to-day work are increasingly mainstream. Stack Overflow's 2025 Developer Survey found that 84% of respondents were using or planning to use AI tools in their development process, while 51% of professional developers said they use AI tools daily.
That changes the context of the interview. AI assistance is no longer a strange exception to normal engineering practice. For a large proportion of developers, it is part of the normal workflow.
Why junior candidates may absorb more of the damage
Fabric reports that candidates with zero to five years of experience were flagged at nearly twice the rate of senior candidates. That does not establish that junior engineers are less honest. It points to a more uncomfortable possibility: they have less independent evidence available to employers.
An engineer with eight years of production experience has a body of work that can be examined in depth. There may be shipped products, architecture decisions, incidents handled, systems maintained and teams managed. A junior candidate often has a much smaller professional record, which makes a single technical assessment carry more weight.
That matters because the technical interview was valuable precisely as a form of work sample. Schmidt and Hunter's research showed why employers became so reliant on structured interviews and work-sample testing. The methods offered something more informative than a resume or an informal conversation. But an assessment only works if the behavior being observed is actually the behavior the employer intended to measure.
The latest employment outlook also makes the problem harder to ignore. The U.S. Bureau of Labor Statistics currently projects 10% employment growth for software developers, quality assurance analysts and testers from 2025 to 2035, considerably faster than the 3% average projected across all occupations. In other words, the demand for technical talent is not disappearing. The challenge is becoming more specific: employers still need skilled developers, but some of the traditional signals used to identify them are becoming harder to interpret.
That is particularly important for early-career hiring, where there is less work history available to balance a questionable interview result.
The detection arms race does not have an obvious winner
The tools involved have become more sophisticated. Fabric describes a broader detection approach that looks at signals such as response timing, gaze patterns, browser activity, voice characteristics and language behavior rather than relying only on obvious tab switching.
That makes detection more difficult, but it does not make the underlying measurement problem disappear.
Fabric says 61% of candidates it flagged still scored above its passing threshold. That finding is worth paying attention to because it separates two questions that hiring teams often treat as one: whether a candidate received unauthorized assistance and whether the candidate is technically capable.
Those are not always the same question.
A developer may use AI during an interview and still have strong technical judgment. Another candidate may follow every rule and perform poorly under pressure despite being excellent at the actual job. A detection system can help identify a suspicious interview, but it cannot by itself determine whether the person would succeed after being hired.
There is also a fairness question. Behavioral signals are not neutral by default. Nervousness, language differences, interview anxiety and other normal variations in communication can affect timing, eye contact and speaking patterns. That does not mean detection systems are inherently unreliable. It does mean a flag should be treated as evidence to review rather than an automatic rejection.
The same principle applies to the rules themselves. AI assistance can be prohibited in one company's technical round, explicitly permitted in another and partially allowed in a third. In that environment, the distinction between legitimate tool use and misconduct depends partly on the policy the employer chose before the interview began.
Some hiring teams are changing the interview instead
The most interesting response is not to build a better lie detector. It is to change what the interview is supposed to measure.
Canva provides one of the clearest public examples. In a June 2025 engineering post, the company said it now expects backend, machine-learning and frontend engineering candidates to use AI tools such as Copilot, Cursor or Claude during technical interviews.
The logic is straightforward. Canva says almost half of its frontend and backend engineers were already daily users of AI-assisted coding tools. Testing candidates without those tools, in the company's view, would assess a workflow that many engineers no longer use in their real jobs.
The format therefore changed. Candidates use their preferred AI tools while being evaluated on what they do with the output: how they direct the system, identify mistakes, reason through trade-offs and explain technical decisions.
That is a meaningful shift because it moves the assessment away from "Can you produce this code without assistance?" toward "Can you use the tools available to a modern engineer without losing technical judgment?"
It does not eliminate disagreement. Some engineers remain skeptical of AI-assisted interviews because allowing a model into the process can make it harder to distinguish genuine fundamentals from strong prompting. But that is a productive disagreement. At least the interview is openly asking a question that resembles modern engineering work.
What technical hiring needs to measure now
The answer is not to abandon technical interviews. It is to make them harder to fake for the right reasons.
The first adjustment is to use more evidence before the interview starts. A portfolio, contribution history, previous projects or a detailed walkthrough of shipped work can provide context that a 45-minute coding session cannot.
The second is to make follow-up depth more important than first-answer polish.
A DevOps candidate can produce a confident explanation of infrastructure as code. That tells an interviewer something, but not enough. Ask what happened the last time a deployment stalled. Ask how rollback decisions were made. Ask which metric exposed the problem first. Ask what they changed afterward. Those follow-ups force a candidate to connect the abstract answer to actual experience.
The same applies to software development and AI engineering. A candidate may know the terminology surrounding model evaluation, agents or retrieval systems. The stronger test is whether they can explain a trade-off they actually encountered, defend a design decision, diagnose a failure or change their approach when a new constraint appears.
The third adjustment is simple but often overlooked: define the AI policy before the interview begins.
Candidates should know whether AI assistance is forbidden, permitted or expected. That makes the process fairer for everyone and removes the ambiguity that turns normal tool use into a compliance issue.
This is also where specialist technical screening can become more valuable. A recruiter who understands the difference between a familiar technical phrase and genuine hands-on experience can ask better questions before the hiring manager ever enters the process. Firms such as prod ready recruitment have built their positioning around technical recruitment across areas including AI, DevOps and software engineering, with consultants who bring substantial hands-on industry experience to candidate screening.
The point is not that every recruiter needs to be a former engineer. It is that technical recruitment increasingly rewards people who can recognize the difference between someone who understands a system and someone who can merely describe it convincingly.
A better way to think about technical interviews
Three changes stand out.
First, no single interview should carry the entire hiring decision. Use the interview as one piece of evidence alongside previous work, technical discussions, references and realistic work samples.
Second, measure reasoning rather than typing speed. The strongest engineers rarely succeed because they can write every line from memory. They succeed because they can decompose problems, recognize bad assumptions, debug unfamiliar systems and make sensible decisions when the obvious answer stops working.
Third, test candidates in conditions that resemble the job. If engineers are expected to use AI coding assistants, ignoring those tools during an interview may no longer measure the right capability. If AI use is prohibited for a particular role or stage, that policy should be explicit and consistently applied.
The objective is not to make interviews harder for candidates. It is to make them more representative of the work employers are actually hiring people to do.
The real question is not whether using AI in an interview counts as cheating
That debate is easy to get stuck in. It produces arguments about fairness, ethics and detection while leaving the deeper problem untouched.
Technical hiring built much of its credibility on the assumption that a candidate was solving a problem alone, in real time, under observation. That assumption is becoming less reliable.
The answer does not have to be better surveillance. It may be better measurement.
The best hiring processes are likely to become less interested in whether someone can produce an answer unaided for 30 minutes and more interested in whether they can understand a problem, use the tools available to them, challenge an incorrect result and explain why their final decision makes sense.
That is a harder standard to fake, but more importantly, it is a more useful standard to hire against.
The organizations adapting fastest will not necessarily be the ones that catch the most candidates using AI. They will be the ones that worked out what they actually need an interview to prove, then redesigned the process around that answer.
