Cheating in Coding Interviews: Why Portfolios Beat Puzzle Tests

Aug 18

A quiet arm’s race that’s gone viral

Technical interviews used to be about logic, problem-solving, and raw coding talent under pressure—a fair measure, or so we thought. But in 2025, cheating in coding interviews isn’t just opportunistic—it’s industrial. Tools like Interview Coder, developed by Columbia student Roy Lee, are enabling real-time assistance during live interviews. This tool runs in the background, listening to questions and generating code answers instantly—meaning the person on the other side could be a ghost, even if their résumé looks solid. This isn’t underground slang anymore—it’s news, and it’s affecting how recruiters assess "technical honesty." YouTube

Cheating rates are spiking—and recruiters are catching on

It’s not just a few code monkeys at Silicon Valley playgrounds. According to Business Insider, when interviewing 1,270 candidates earlier this year, the firm Fonzi flagged 23% as likely to be using external tools—up from around 2% just a couple of years ago. Interview evaluation tools were detecting extended pauses, behavior mismatches, and phrasing patterns consistent with AI-generated answers. A company that used to see cheating in one out of every fifty interviews is now seeing one out of five. That shift changes the game. Business Insider

Why traditional puzzle tests betray you

The problem lies in what you’re measuring. Puzzle-based assessments were never meant to show contextual capacity or meaning-making ability—that requires bullying through OpenAI-generated code. If a candidate returns perfect solutions under time pressure, we assume it’s skill. If their explanations are polished, we assume they understand. But the truth may be AI hard-coded responses. To paraphrase a recent analysis from David Haney’s blog: real candidate assessment requires real-time, collaborative exploration—not rehearsed answers from an LLM. davidhaney.io+1

The real cost of a “successful” cheat

Hiring someone who can ace your coding test but has no substance can be more damaging than hiring someone who’s just below the cutoff. That person might churn out buggy features, require constant support, or leak IP through careless code. And let’s be brutally honest—if this is a coordinated infiltration, it could be a supply-chain risk or even a nation-state operation. A ghost coder wins your trust, then compromises your systems. The downside is deeper than performance failure—it’s a potential breach with plausible deniability.

KYD’s alternative: real track records, not test-day magic

KYD offers immunity against this sort of trickery by elevating what matters: actual, verifiable technical stories. Instead of watching for flashes of brilliance on demand, KYD maps claimed expertise to public footprints—GitHub pages, issue trackers, package contributions, and team reviews. If someone’s claiming to be a Python wizard but their commit history tells a different story, that’s a red flag. It’s not about catching cheats—it’s about filtering for legitimacy before the test starts. Continuous monitoring ensures that if someone got in through smoke and mirrors, their lack of substance will show up soon after.

The takeaway: stop trusting the puzzle, and start trusting the footprint

The era of one-off, high-pressure whiteboard puzzles is over. They’re easy for AI to defeat, and easy for real talent to mimic. If hiring is about assessing real capability, we must look beyond the one moment of performance and evaluate consistent behavior. Path dependency matters. The person you hire should have a history—not just a show. Anything else is playing with fire.

Sources Cited

Milanie Cleere