48% of Software Interviews Are AI-Cheated. The Filter Moves Left.

Fabric analyzed 19,368 AI-powered interviews between July 2025 and January 2026. Across all roles, 38.5% of candidates were flagged for AI cheating. In software engineering the number is 48%, and 61% of those cheaters scored above the passing threshold anyway. If you still treat the interview as the filter, you are calibrating on noise.

The interesting question is not "how do we catch them." The interesting question is what a hiring funnel looks like when the interview is provably corrupted and detection tools are provably losing. The answer moves the quality gate one step earlier, to sourcing signals that a Cluely overlay cannot fake.

The headline number: 48% of software interviews are flagged, and it tripled in two months

Fabric's dataset is the largest public sample of AI interview cheating to date, and the trend inside it is worse than the headline. The flag rate for software engineering roles hit 48%, four times the 12% rate for sales. The rate tripled from 9% in July 2025 to 45% by September 2025, then held.

48%

The interviewing.io survey of 63 Big Tech and New Big Tech interviewers, published first by Gergely Orosz at The Pragmatic Engineer, tells the same story from the other side of the table: 81% suspect AI cheating and 31% have personally caught someone. Karat's co-founder puts LLM use on code tests, even when explicitly prohibited, at roughly 80% of candidates. Three independent methodologies, three different populations, one direction.

Here is the full picture, side by side:

The 4x gap between SWE and sales is the tell. Sales interviews test communication in a way that is genuinely hard to script through an overlay. Coding interviews test a task an LLM was trained to do. That mismatch will not resolve itself.

Why detection is architecturally losing, not tactically losing

Detection is not failing because the tools are immature. It is failing because of how GPU compositing works. Cluely, Interview Coder, Final Round AI, Parakeet AI, and the open-source Aura project all render their answer overlays through DirectX on Windows or Metal on macOS. The interviewer's screen share never receives those pixels, because the OS never hands them up the capture chain. Fabric reports that 45% of flagged cheating cases involved exactly this class of tool.

That is why only 11% of FAANG-tier companies bother running detection software at all, and adoption is essentially just Meta. The companies closest to the problem have already concluded that detection is a losing arms race. Consider the asymmetry:

• Cluely alone has raised $20.3M, including a $15M Series A from a16z. Cheating is now a venture-backed category.
• Gartner projects that by 2028, 1 in 4 candidate profiles will be entirely synthetic (text, voice, and deepfake video combined).
• Truffle's July 2026 update explicitly names deepfakes, audio coaching, and smart-glasses cheating as the next surface area, and their framing has already shifted from "detect the answer" to "remove the right answer."

When the interviewer's screen share never receives the cheating pixels, no proctoring plugin can save you.

The market is bifurcating. Meta, Shopify, and Canva are moving to allow AI in interviews with enhanced scrutiny, betting that the format has to change. Everyone else is quietly watching their historical calibration ("we hire above a 7.0") drift into meaninglessness, because 61% of the people scoring above that threshold in Fabric's sample were cheating.

The 61% problem: your historical scores are already corrupted

If you have hired against a fixed interview rubric for the last two years, the past six months of that data is contaminated. Sixty-one percent of flagged cheaters in the Fabric sample scored above the passing threshold, meaning they would have advanced with no detection at all. Three concrete consequences:

1. Loop calibration is broken. The "strong hire" bar was set against a distribution that no longer exists. Interviewers benchmarking against last year's candidates are inflating their own signal.
2. The bad-hire cost compounds. A bad engineering hire costs 30% to 150% of first-year salary. For a $150K engineer, that is a $45K to $225K direct cost, before you count the bugs, security holes, and rework they leave behind.
3. Junior loops are hit twice as hard. Fabric shows candidates with 0 to 5 years of experience are flagged at roughly 2x the rate of seniors, and attributes it to a saturated entry-level market and unrealistic knowledge bars, not character.

The junior finding matters for how you source. If entry-level interview scores are the noisiest, the only trustworthy pre-interview signal for a junior is an artifact they can defend in a conversation: a first PR merged into a real repo, an issue thread where they argued through a design choice, a package they published and maintain. LeetCode scores stop being evidence. Authored work becomes evidence.

The scarcity moat: verifiable GitHub signal is a <1% pond

The population you can source on verifiable authorship is tiny, and that is what makes it useful. Refolk's index of US software engineer, senior, and staff profiles contains roughly 554,914 people. Of those, only about 16,634 (≈3.0%) list "GitHub" as a skill or profile keyword. Only about 518 (≈0.09%) explicitly surface "Open Source" as a skill.

0.09%

That is the sourcing implication of the 48% cheat rate spelled out in one ratio. The top of the funnel is enormous. Almost none of it carries any external, verifiable signal of authorship. The population you can source on behavior (commits, issues, package downloads, conference talks) is not just smaller than the applicant pool. It is a different pond entirely, and the AI-assisted applicants are almost never in it.

This is where the filter actually lives now. When you describe a candidate to Refolk in plain English ("senior backend engineer in the US who has merged PRs into a top-500 Rust crate in the last 18 months"), the returned shortlist is drawn from that <1% pond by construction. It is not a search over LinkedIn titles. It is a search over things a Cluely overlay cannot produce: a public commit graph, an issue you argued in three years ago, a talk you gave at RustConf.

What "sourcing as the filter" looks like in practice

Sourcing as the filter means the first artifact you evaluate is public, dated, and authored, and the interview only exists to confirm what the artifact already told you. If a candidate's public work already proves they can do the job, an AI-piped coding round does not add signal, it only adds noise you now have to subtract.

Concretely, the pre-interview workflow that survives 2026:

• Anchor on authored artifacts, not skills lists. A merged PR into a project with >5,000 stars beats any self-declared "expert in distributed systems." Sort by the artifact, not the resume line.
• Read the issue thread, not just the diff. LLMs can generate patches. They cannot retroactively insert you into a 40-comment argument about API design from 2022. Issue archaeology is one of the highest-signal, lowest-cost checks available.
• Weight package maintainership disproportionately. A candidate who ships and responds to bug reports on an npm or PyPI package with real download volume has demonstrated production ownership under real users. That is exactly what the coding interview was trying (and failing) to measure.
• Use conference speaker rosters and CNCF working-group membership. KubeCon, PyCon, RustConf, and the Kubernetes SIG lists are small, public, and effectively impossible to spoof.
• Cross-check against HN "Who's Hiring" respondents. People who post their own email in those threads tend to have portfolios worth reading.

None of this is new advice. What is new is the cost of not doing it. When 48% of the interview loop is contaminated, sourcing candidates on GitHub signals stops being a "nice premium filter" and starts being the only reliable one you have.

What to change on Monday

Stop treating detection as the fix. It is not going to catch up, and the FAANG companies closest to the problem have already stopped pretending it will. Move budget and time from interview infrastructure to sourcing infrastructure.

Three concrete moves:

1. Cut one interview round and add one artifact review. For every candidate, spend 20 minutes reading their public work before the loop starts. If there is nothing to read, that is itself a signal, especially against the 48% baseline.
2. Re-rank your current pipeline by verifiable authorship. Take the last 50 applicants for your open role and re-sort them by whether they have public artifacts that match the job. The order will change materially.
3. Source into the <1% pond directly. Instead of posting and praying, describe the engineer you actually want to Refolk, pull the people who match on real signal, and reach them directly. You will run a smaller loop and hire from a higher-trust pool.

The interview will still exist in 2027. It just will not be where the decision gets made. The decision moves left, into sourcing, where the evidence is dated, public, and immune to overlay rendering.

FAQ

Is AI interview cheating really this widespread, or is Fabric's sample biased?

Fabric's 48% number comes from 19,368 interviews across their customer base, which skews toward companies already worried enough to instrument detection. But the interviewing.io FAANG-interviewer survey (81% suspect cheating, 31% have caught someone) and Karat's ~80% LLM-use figure on prohibited code tests come from very different populations and land in the same range. Multiple independent methodologies pointing at the same number is the strongest confirmation you get in hiring data.

Can we just ban AI in the interview and enforce with proctoring software?

You can ban it. You cannot enforce it. Overlay tools like Cluely, Interview Coder, and Aura render through DirectX or Metal below the OS screen-capture layer, which means the interviewer's video feed literally never contains the cheating pixels. Only 11% of FAANG companies bother running detection software, and the ones that do (essentially just Meta) treat it as one signal among many, not a solution.

What is the single highest-signal pre-interview check for engineers right now?

Read one issue thread the candidate participated in on a public repo, ideally one older than 18 months. A merged PR shows they can produce code. A multi-comment argument about a design tradeoff, dated years ago, is nearly impossible to fabricate and tells you how they think under disagreement. If they have no such thread, that is not disqualifying, but it moves the burden of proof back onto the interview, which is the loop you no longer trust.

How do I find candidates with real GitHub signal without spending my week on manual search?

Describe the engineer in plain English (stack, seniority, geography, specific projects or ecosystems) and let a sourcing tool built on the open web do the pattern match. Refolk indexes GitHub, LinkedIn, and the open web together, so a query like "senior Go engineer who has contributed to CNCF projects in the last year and is not at a FAANG" returns a shortlist ranked on actual commit and issue authorship, not self-declared skills. That is the <1% pond, made searchable.