Someone was accused of cheating because they were able to solve a difficult problem very quickly. Not for playing with AI. Not for copying from a screen. Just for excelling at it.
The theater everyone agreed to perform
There's a survival strategy floating around interview forums that broke my brain a little. You see the issue right away. How do you react to that? You act as if you don't. One applicant nailed it: feign "you've never encountered that problem before," provide "the wrong answer or method" initially, then "come upon the best answer."
Yes, just let that sink in for a moment. The most successful strategy would be to pretend to be inept in a way that is believable. We created an interview process in which having the right answer would actually be a disadvantage. That's not a talent filter. That's an acting workshop filter. 🎭
Pattern recognition is the actual job
Here's the part everyone's thinking but no one is actually saying. In most cases, the actual implementation or execution of work is rarely new or unique. That's all there is to it. In addition, the patterns are not infinite in numbers as well. Benchmark data from CodeIntuition.io suggests that just 5 core patterns cover roughly 80% of the interview problems, and CoPilot Interview's data goes further, arguing that the vast majority of problems are "re-skins of about 15 underlying patterns."
Therefore, what you're memorizing is a small deck of cards. And then, you're supposed to act as if you've never encountered it before. The candidate who has is not cheating. They are simply more advanced on the same curve that the job pays.
What real engineering actually tests
If not pattern recall, then what skill is worth measuring? Dan Abramov provided the best response I have come across, during a simulated interview with Theo. His point was that it's not "whether you can reinvent quicksort given a clock."
The cue is: When I give you something unorganized, do you locate the edge where it shatters? Are your decisions sustainable as the subsequent aspect is placed above it? You can't measure that using a timer and a board. The way to measure is to observe someone constructing it. That's probably the reason why OpenAI gives candidates a 48-hour take-home work trial and pays them approximately $1,000 for it, according to an Interview Coder report. It's not a test. It's a simulation of the job. Paying people to do real work and judging the real work. Wild concept.
The honesty trap
So, returning to the initial question: Is it okay to admit that you've come across the problem before? The tension is fake. It only exists because we designed a test where honesty hurts you. If saying "yeah, I know this one" makes you fail, it's not the honest student who's the problem. It's the grading criteria that values performance more than honesty. → Recognizing a solved problem is a feature, not a confession. → A test you can only pass by faking ignorance is measuring the wrong thing. → If your interview punishes the honest expert, it selects for good liars. I prefer to hire someone who can say "I've seen that pattern and here's how that problem fits," over someone who does a slow-motion discovery they memorized the night before. The other one is trying out for a role. 🎬
The takeaway
We continue to pretend that the algorithmic interview tests some kind of 'raw' problem-solving ability. It is in fact mostly testing who has recently practiced those same handful of patterns and who is willing to hide that fact. Reward the right behaviors. Test the skills and the corner cases. And stop forcing the good folks to act as if this is the first time they've ever encountered a coin-change variant. If a candidate solves your problem quickly because they have encountered it before, is that considered cheating, or is that actually the type of engineer you are looking for?
Top comments (5)
As a frontend dev, this is so spot on! 🎭
In UI work, pattern recognition is literally what we do every day. Nobody reinvents state management from scratch.
I much prefer real-world component building over LeetCode theater. Great read!
This resonates a lot with my experience on the other side of the table. As a Tech Lead, I interviewed quite a few candidates, and I honestly never cared whether someone knew the exact syntax to fire or capture an event, or could recall some API from memory. That's what docs and autocomplete are for.
What I actually screened for was conceptual understanding: does this person understand why events propagate the way they do? Can they reason about trade-offs? When I described a messy, underspecified problem, did they ask the right questions and find the edges where things break — or did they freeze waiting for the "correct" answer pattern?
Your point about the "acting workshop filter" is painfully accurate. The candidates who performed the little ritual of fake discovery often revealed less about their actual ability than the ones who just said "yeah, I've seen this pattern — here's how I'd adapt it, and here's where it would fail." The latter told me something real in two minutes; the former told me they read the same interview-prep forums I did.
If your hiring process can't distinguish between memorized performance and genuine understanding, that's a process problem, not a candidate problem. I'd hire the honest pattern-matcher every time.
I've been through several interview processes, usually split into soft skills and technical rounds. In my experience, the technical part rarely involved actual coding tasks — a few well-targeted questions were enough to gauge someone's real understanding. I honestly think LeetCode-style exercises are often unnecessary; a good conversation reveals competence just as well, without the theater this article describes.
I hate leetcode for obvious reasons. is it still considered for jobs?
Speedy solves aren't cheating - they reveal solid prep and a clear problem-solving process. Interviewers want thinking aloud, not just the final answer. Show your work, explain tradeoffs, and you'll earn trust (and a job).