The whiteboard interview went away not because it was inhumane, but because it lost out to a bot that could flicker faster than you could squeak the dry-erase marker.
Basically, timed algorithm puzzles only test one skill. How good you are at hiding a second monitor.
The trivia game we all agreed to play
Can we have an open conversation about what LeetCode screening has always measured? It's not skills. It's memory.
It calculated the amount of time you had spent grinding patterns over the past six months. That's it.
An essay on Medium from June 28, 2026 said it best. "AI didn't corrupt the whiteboard interview. It just made the corruption impossible to ignore by removing the one thing the ritual was actually measuring: how much time you'd spent on LeetCode recently."
That's the entire deception summarized concisely. We masked memorization as a substitute for engineering aptitude and assumed no one was aware of it.
The cheating got too easy to ignore
Here's where it falls apart. The machine is now better at the test than the people it's supposed to filter.
An article on PlainEnglish.io in November 2025 mentioned that GPT-5.1 and Claude 4.5 kind of models can solve a "Hard" LeetCode prompt like Trapping Rain Water for you instantly. They hand you the O(n) solution, comments, and explanation of trade-offs.
The same PlainEnglish.io piece, titled "The LeetCode Interview is a Scam," expressed it more straightforwardly. "If your entry test can be solved by a non-sentient autocomplete engine in 3 seconds, your test is garbage."
It's not only puzzle websites. As of August 2026, Failingfast.io reports that Claude Opus 4.5 achieved a 76.8% resolution rate with SWE-bench Verified, and GPT-5 scored 88.0% on the Aider Polyglot code editing benchmark.
In February 2026, Braincuber Technologies published a report stating that Claude 3.5 Sonnet achieved 93.7% overall coding accuracy, and scored 80.9% on SWE-bench Verified. The two SWE-bench figures come from different test runs and setups, so they aren't directly comparable. These aren't fluke numbers. They're consuming the very format we test on.
The arms race nobody can win
Cheating is not done in a clever way. It has become a commercial commodity.
In 2026, Final Round AI's Interview CoPilot™ became a fixture of live FAANG interviews. When the interviewer began to read the problem, the pattern silently appeared on the candidate's screen. "Prefix sums." "Sliding window." The response, whispered.
Now interviews have become a test for paranoia. Is the candidate looking away from the camera?
Devrim, who works as a software engineer, hit the nail on the head in September 2026. "You solved 300 problems, memorized all the pattern... and spent six months preparing to prove you can do a job that looks almost nothing like the interview... You are not going to beat a machine by becoming a larger storage device for known solutions."
That's the punchline. You can't out-memorize the thing built to memorize.
What actually replaces it
The companies with integrity are already making a shift toward decisions.
The shift is loud and clear if you're paying attention:
→ Architectural judgment over pattern recall. Can you reason about a system, not recite an algorithm?
→ System ownership over solo sprints. Do you know why a design breaks at scale?
→ AI-assisted rounds where the tool is on the table, not under it.
In reality, in the second quarter of 2026, Google launched a pilot of AI-aided coding rounds with interviewers' own models. By mid-2026, its internal research found that 75% of the new code in key software development repositories was generated by AI models. The final code was reviewed and committed by a human.
Isn't it interesting to consider? Nowadays, Google's hiring standards require you to work with a machine, rather than wait until you get the job to do so. Finally, the interview process reflects the real world.
The takeaway
The fact that the whiteboard ritual has made it this far is that it was easy to schedule, and easy to tally as a score. It was never precise. AI simply pulled the curtain and revealed that we were grading trivia all along.
Good riddance. The best engineers I've worked with weren't fast at Trapping Rain Water. They were slow, careful, and asked the right question before writing a line.
Here's the thing I can't get out of my head: if you can be 3 seconds faster than an autofill at an interview, what are we actually trying to assess for? What sets the great apart from the mediocre other than sheer fatigue resistance?
What replaced LeetCode in your last interview loop, and did it feel more honest or just harder to fake?
Top comments (2)
Imo, the real test in modern interviews, should be raw. Here's a broken codebase, fix it. Time them, look at their implementations, see how finely they implemented it, judge their implementation strategy... Essentially judge them for what actually matters, can they do the job. My last interview was the boss walking me through the office, asking me about my past work and my skillset and when I immediately jumped into it and gave him detailed explanations of what they should implement, I got the job, though I only saw it a year later, he actually implemented verbatim what I said, into a separate project from what he had me working on. Value is value, do you know what to do and do you add value. Then do a probation where you evaluate if it's all talk, no walk.
Or, you know, live, screenshare, here's a buggy codebase, or here's an implementation, do xyz. Judge on cleanliness, test coverage, speed and negatively judge overflow and cross-contamination. Ideally, drop a git push to the branch mid-implementation, to see whether they run it post merge to test that it still works. Real world problems, that they'd genuinely be doing 90% of the time.
I should clarify, no-holds barred. If they want to copy paste code, or use AI, doesnt matter, here's a task, do it how you'd do it in production, so we can see how you work. If it's just prompt monkeying, without checking code, without testing, without expanding on the instructions to be more precise, then it's a worthless employee, you're better off paying for an extra agent running. If they actually fix bugs, keep it targeted, implement it the way you want your codebase treated, then bingo, that's the person you want, because they just showed you that they can do the job.