{"slug": "the-interview-that-wouldn-t-die", "title": "The Interview That Wouldn't Die", "summary": "A Columbia student named Chungin \"Roy\" Lee built Interview Coder, a tool that screenshots coding problems during interviews and feeds them to an AI for real-time solutions, used it in an Amazon interview, had his offer pulled, was suspended, and dropped out to raise $15 million from Andreessen Horowitz. The company, later rebranded as Cluely, publicly admitted to lying about its revenue numbers to TechCrunch, and the tool claims 150,000+ users. Interviewing.io data shows the median successful candidate's technical score rose 15% from Q1 2022 to late 2022, and a survey of 67 interviewers found zero of 52 FAANG respondents had moved away from algorithmic questions.", "body_md": "Before you reach the bottom of the article and get annoyed, the bottom line hasn't changed: you still need to grind LeetCode. **The question this article attempts to answer is, why?**\n\nIn early 2025, a Columbia student named Chungin \"Roy\" Lee built [Interview Coder](https://www.interviewcoder.co/), a tool that screenshots coding problems during interviews and feeds them to an AI for real-time solutions. He used it during an [Amazon](/companies/amazon) interview, Amazon pulled his offer, Columbia suspended him, and he dropped out to [raise $15M from Andreessen Horowitz](https://techcrunch.com/2025/06/20/cluely-a-startup-that-helps-cheat-on-everything-raises-15m-from-a16z/). The company, later rebranded as Cluely, [publicly admitted to lying about its revenue numbers](https://techcrunch.com/2026/03/05/cluely-ceo-roy-lee-admits-to-publicly-lying-about-revenue-numbers-last-year/) to TechCrunch. His tool claims 150,000+ users. It is not the only tool. Each one is a subscription product solving a specific problem: the [LeetCode-style interview](/study/coding/concepts/coding-interview-intro) is gameable, and where there's a gameable system, there's a market for gaming it.\n\n## The arms race\n\nThe tool isn't as invisible as the marketing claims. It is visible in macOS Activity Monitor, its hotkeys can be tracked by browser keyboard listeners, and platforms often let candidates finish tests before silently disqualifying them. It's also slow: response delays of 5-90 seconds, long enough to be noticeable in a live interview. The \"150,000+ users\" claim is self-reported. The marketing outpaces the evidence.\n\nWhether the tool works as advertised barely matters. The *belief* that it might is enough to poison the pool.\n\nThe candidates using these tools are scared anyway. On [Reddit's r/csMajors](https://www.reddit.com/r/csMajors/), one user reported being silently rejected after using Interview Coder for a Capital One assessment. \"I don't want to try it again for other companies out of fear of potentially getting blacklisted.\" You pass the tool, your application silently disappears three days later, and you never know why.\n\nBoth sides are paranoid, and both sides have reason to be. The tool makers overstate detection difficulty. The platforms overstate their catch rate. Building a tool will always be easier than building a detection system without false positives, so the tool makers stay one step ahead. The honest candidate loses either way.\n\n## The candidate's dilemma\n\nSo the honest candidate runs the calculation. If you don't cheat and the person before you did, you lose the offer to someone who scored higher with AI-generated code. If you do cheat and the company catches it silently, you lose the offer and you don't know why. If you cheat and they don't catch it, you get the job, and you'll have AI on the job too...\n\nThere is no version of this calculation where the honest path is clearly the rational one. The rational response to a gameable, unvalidated filter is to game it.\n\n[interviewing.io](https://interviewing.io/blog/you-now-need-to-do-15-percent-better-in-technical-interviews) tracks the technical score of the median successful candidate. In Q1 2022, you needed to be better than 68% of candidates who reached the phone screen. By late 2022, you needed to be better than 78%. That's a 15% increase, associated with market leverage: tech jobs contracted roughly 40% over the same period. Fewer openings, higher bar. The bar rose, and nobody proved it was measuring anything.\n\n## FAANG hasn't moved\n\n[interviewing.io](https://interviewing.io/blog/how-is-ai-changing-interview-processes-not-much-and-a-whole-lot) surveyed 67 of its interviewers. The headline finding: **of 52 respondents from FAANG companies, zero said their company had moved away from algorithmic questions.** [Their own cheating study](https://interviewing.io/blog/how-hard-is-it-to-cheat-with-chatgpt-in-technical-interviews) showed that small twists on LeetCode questions don't stop cheaters. Only fully custom questions are cheat-resistant, and most interviewers aren't there yet.\n\n[Meta](/companies/meta) is the one FAANG company running an experiment: an [AI-assisted coding interview](https://www.wired.com/story/meta-ai-job-interview-coding/) as part of the onsite loop. But candidates still have to pass the algorithmic phone screen first. Meta added a new gate behind the old one rather than replacing it.\n\n[Anthropic](https://www.anthropic.com/candidate-ai-guidance), the AI company, explicitly forbids AI during technical interviews. If the company building the models says the interview should test you and not your tools, that's a signal. See our [Anthropic interview guide](/companies/anthropic), and for the other side of AI in interviews, labs probing your safety thinking, see our [AI safety primer for engineering interviews](/articles/ai-safety-for-interviews).\n\nThe companies keeping the algorithmic screen have a steelman: a company hiring thousands of engineers per year needs a format that thousands of interviewers can calibrate against. A standardized screen is legally defensible and resistant to interviewer bias. Changing it risks trading a known, imperfect filter for an unknown one, at a cost of months of calibration.\n\n[Google](/companies/google) published that brainteasers had zero predictive validity and that structured interviews did predict performance. **They never published whether the algorithmic coding screen specifically predicts engineering performance. Nobody else has either.**\n\nThe conversation about how to stop cheating assumes that the thing being cheated on was worth defending.\n\n## What does the interview test?\n\nA LeetCode-style interview tests solving curated problems in isolation. The job requires solving uncurated problems in production: reading code you didn't write, debugging a failure that doesn't appear in any documentation. Yes, the 2am on-call example is the worn cliche of this genre, but it's worn because it's true. The payment service times out for 3% of transactions, the staging environment doesn't reproduce it, and there is no LeetCode problem for that.\n\n### The rabbit hole\n\nI went looking for research that directly connects LeetCode-style screen success to later job success. The direct question barely has an answer: no peer-reviewed study has tracked algorithmic interview scores against performance reviews for hired engineers. What exists is adjacent and underwhelming - [structured interviews](https://psycnet.apa.org/record/1998-10661-006) and [work samples](https://psycnet.apa.org/record/1998-10661-006) predict job performance, but timed algorithm puzzles aren't a work sample. [Google](https://www.nytimes.com/2013/06/20/business/in-head-hunting-big-data-may-not-be-such-a-big-deal.html) found brainteasers useless, [reformed around structured interviews](https://rework.withgoogle.com/intl/en/guides/a-guide-to-structured-interviewing-for-better-hiring-practices), kept algorithmic screens anyway, and never published whether those scores predict engineering performance. [interviewing.io](https://interviewing.io/blog/how-well-do-leetcode-ratings-predict-interview-performance) found LeetCode questions solved correlates with interview performance (r = 0.27) and more weakly with FAANG employment (r = 0.17) - not job performance. Whiteboard observation itself [cuts performance by more than half](https://chrisparnin.me/pdf/stress_FSE_20.pdf) under controlled conditions. The industry copied the gate without copying the validation.\n\nNobody has published the regression that says \"LeetCode score → year-one performance.\"\n\nYou probably read this and think: okay, he's not telling me anything new. You're mostly right. The research confirms what experienced engineers already suspect.\n\n### The grit filter\n\nMaybe the LeetCode interview was never meant to predict coding ability. Maybe it was a grit filter.\n\nThree months of unpaid prep to pass a 45-minute phone screen is a signal of something: willingness to grind, tolerance for arbitrary systems, ability to memorize on command. If the old interview was a \"did you put in 100 hours of prep\" filter, it was measuring something real. It just wasn't measuring what it claimed to measure.\n\nWhen AI collapsed the cost of grinding to zero, it exposed what the signal was. The interview was never testing whether you could [invert a binary tree](/study/coding/concepts/trees). It was testing whether you'd invert a hundred of them, unpaid, for the chance to be considered.\n\nAnd some companies would be fine with that. The grit filter has defenders. When [Google](/companies/google) killed brainteasers, they kept the algorithmic interview. For organizations that run on arbitrary, difficult, time-consuming systems, tolerance for those systems is the trait the interview selects for. This is why FAANG stasis is rational. **They never had a validity signal to lose. They lost a grit signal.** Its value comes from its correlation with compliance: will this person do the boring, arbitrary thing we ask them to do, even when it's pointless? Every large organization needs that question answered, and the algorithmic interview answers it by accident.\n\n\"By accident\" is not a hiring strategy, though. **If the interview is a grit filter, call it that, validate it as that, and stop pretending it measures coding ability.** The companies that don't will keep running a filter they can't defend, while candidates cheat around it and honest candidates suffer through it.\n\n## Startups are doing something different\n\n### Open-book with AI as the reference\n\nIn the same survey, 67% of startup respondents said AI has meaningfully changed their interview process, versus 0% at FAANG and FAANG-adjacent companies. The startup sample was small, roughly 5 companies, but the contrast is stark. The new format is open-book, with the AI as the reference, and the tasks are correspondingly harder. Amanda Richardson, CEO of [CoderPad](https://coderpad.io/), described it: \"AI questions are 1000-2000 line code bases, and you have to add a feature in a short amount of time. Open-book is more representative of the job, but it's making interviews harder and impossible to do without AI.\"\n\nThe clearest articulation of the open-book philosophy came from Farhan Thawar, Head of Engineering at Shopify, in a [conversation with Gergely Orosz](https://newsletter.pragmaticengineer.com/p/the-pulse-146). Shopify is a large company behaving like a startup on this question.\n\n\"I've seen engineers, when there's something very easy to fix, they won't fix it. They will try to\n\npromptto fix it. And I say, are youreallyan engineer? I get the nuance of just prompt and prompt and prompt. But sometimes the fix isright thereand they will keep on prompting. I'm thinking: just change that one character, but they won't change it!\"\n\n### Take-home and defend\n\nAnother approach skips the live coding session entirely. Give the candidate a vague requirement. Build it at home, with whatever tools you want. Then come in and defend it: why this architecture, what tradeoffs did you accept, what would break first under load. The candidate has to defend the whole project, even if they wrote it with AI. The AI generated the code, but the candidate has to explain why each piece is there and what happens when it breaks. AI assistance is a given. The question is whether they used it well, and the [defense interview](/study/coding/concepts/coding-challenge-interviews) is where you find out.\n\nThis format isn't new. [Firebase used it in 2011](https://startupandrew.com/posts/how-firebase-interviewed-software-engineers/): a take-home problem called GoldMine, followed by an on-site defense round. Hundreds of companies in the [hiring-without-whiteboards](https://github.com/poteto/hiring-without-whiteboards) list use some variant. It fell out of favor for good reasons: candidate fatigue, bias toward people with free time, unpaid labor. What AI changed is not the defense round's value. The defense round was always the mechanism that caught candidates who didn't write the code they submitted. Before AI, that meant plagiarism. After AI, it means generated code. Either way, the candidate has to explain why each piece is there and what happens when it breaks. [Work samples](/study/coding/concepts/code-review-interviews) at r = 0.54 are among the strongest predictors in the research, and the defense round is what makes them practical at scale.\n\n### The level problem\n\nThe new format has a level problem. The open-book test asks whether you can tell when the AI is wrong. That requires judgment, and judgment comes from having written enough code to recognize the difference between a correct solution and a plausible one. A senior engineer has that. A new grad doesn't. **The format that was supposed to replace a filter biased toward grinders may have replaced it with one biased toward people who've already shipped production bugs.**\n\nBut difficulty is not validation. LeetCode was difficult too. The only way to know if the new formats predict job performance is to track the people who passed them and see if they actually did the job better. Nobody has done that either.\n\n## Why it survives\n\n**Grind, baby, grind.** The algorithmic interview is not going away soon. It's sad and annoying, but it's still the most structured way to compare candidates at scale. You can calibrate thousands of interviewers against it. You can defend it in court. You can run it cheaply, consistently, and across continents. The open-book formats are better, but they need interviewers who can judge architecture and defense under pressure, and there aren't enough of those.", "url": "https://wpnews.pro/news/the-interview-that-wouldn-t-die", "canonical_source": "https://returnzero.dev/articles/coding-interviews-in-the-age-of-ai", "published_at": "2026-08-23 12:38:28+00:00", "updated_at": "2026-08-23 13:14:57.328259+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-ethics", "ai-policy"], "entities": ["Chungin \"Roy\" Lee", "Interview Coder", "Cluely", "Amazon", "Columbia", "Andreessen Horowitz", "TechCrunch", "interviewing.io"], "alternates": {"html": "https://wpnews.pro/news/the-interview-that-wouldn-t-die", "markdown": "https://wpnews.pro/news/the-interview-that-wouldn-t-die.md", "text": "https://wpnews.pro/news/the-interview-that-wouldn-t-die.txt", "jsonld": "https://wpnews.pro/news/the-interview-that-wouldn-t-die.jsonld"}}