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 s...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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!
I hate leetcode for obvious reasons. is it still considered for jobs?
Oh yeah. Especially for pre interview stages / screening
I've been through quite a few interview processes, typically with separate soft skills and technical rounds. In my experience, the technical interview rarely required solving coding challenges. A handful of well-chosen questions was usually enough to assess someone's knowledge and problem-solving ability. I believe LeetCode-style exercises are often overused—a meaningful technical discussion can reveal a candidate's competence just as effectively, without the unnecessary performance aspect blogyz.xyz/
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).
This matches what I keep seeing too. Knowing the pattern is table stakes. The part that still fails people is explaining the tradeoff out loud without freezing when the interviewer nudges the problem.
I started timing myself talking through a known problem from a blank editor. If I cannot narrate the invariant in under a minute, I do not actually own it yet.
I see your perspective. Where would you draw the line then? Is there a difference between memorising known problems and actively looking up solutions live during an interview?
The line I'd draw isn't about where the answer came from, it's about whether it survives a follow-up.
Memorised-and-understood holds up: ask what breaks when the input is already sorted, or what this costs at 10x the data, and the answer keeps coming. Looked-up-live usually collapses on the second question, because a snippet hands you the solution without the reasons underneath it.
That's the useful part for the interviewer too — you don't have to catch anyone out. Ask "why that data structure and not the obvious one" and the difference surfaces on its own, with no acting required from either side.