The Interview Game in the AI Era: Where Does Human Expertise Still Matter?

When candidates start using AI tools to tackle technical interviews, a never-before-seen battle of wits has erupted between recruiters and job seekers. This isn't just a cat-and-mouse game in the interview room — it reflects a deeper question of our times: as Agent Coding capabilities grow increasingly powerful, how should students and practitioners approach learning, and where does human expertise still hold value?

This article draws on the firsthand interview experiences of a technical team lead to explore the absurd new reality of hiring in the AI era — and a question every technologist should sit with.

A 15-Second Problem That Cuts Half the Candidates

The story starts with a controversial article. A former CTO designed a 15-second coding micro-test, claiming it quickly filtered out 50% of unqualified candidates.

The problem itself was trivially simple — determine what a loop would ultimately print. But hidden inside was a carefully engineered trap: the condition shown visually on the webpage appeared to be x > 3, but a CSS trick had concealed an equals sign, making the actual code x >= 3.

This trick exploits the gap between CSS visual rendering and the actual DOM content. Common techniques include setting a character's color to match the background (white text on white), using font-size: 0, or opacity: 0 — the character is invisible to the eye but still physically present in the HTML document, and will be carried along when copied. This reveals a deeper issue: AI tools process structured text streams, not the visual presentation a human eye sees. That gap is the very foundation on which such "trap questions" are built.

If a candidate copy-pasted the question directly into an AI tool or Coding Agent for the answer, the hidden equals sign would come along for the ride — yielding the wrong result. Those who worked it out by hand would get it right.

The CTO used this trick to weed out half the candidates who "hand everything to AI without even looking at it themselves." Interestingly, his favorite candidate wasn't the hand-calculator or the AI-user — it was the person who initially gave the wrong answer and then followed up with an email to self-correct. In his view, this person had developed the habit of reviewing AI output, which is exactly the rarest skill in the AI era.

Whether this test is truly effective is debatable, but it demonstrates at least one thing: the number of interviewers being "driven mad" by AI tools is not small.

The God Move: A Real-Time Human vs. AI Battle

Even more striking were the performances of two campus-recruit frontend candidates.

The interview question was a classic JS fundamentals problem: how would you improve the native JSON.stringify method to handle circular references that cause serialization to fail? The elegance of the question lies in its progressive depth — from efficient object traversal, to using pointer equality to detect circular references, to which data structure (array vs. Set/WeakSet) to store visited references — candidates at different levels naturally reveal their knowledge boundaries.

The first candidate had weak fundamentals but carried a distinctly "AI-era" quality about him. He chose to type out his answer by hand, yet his keystrokes were painfully halting. What was truly uncanny: his very first line was let cache = new WeakSet() — the most critical, optimal solution right out of the gate.

The author reached for a perfect analogy: the "God Move" sought in the Japanese anime Hikaru no Go — like the move AlphaGo played in its famous match that humans struggled to comprehend.

Why call this a "God Move"? It comes down to how LLMs generate text. Today's mainstream large language models are built on the Transformer decoder architecture and generate text autoregressively: each token prediction sees only the tokens already generated, with no ability to "go back and revise" earlier output. This means that before an LLM outputs its first line of code, it has already internally "planned" the overall structure — its streaming output is determined top-to-bottom in a single pass, with none of the back-and-forth revision that characterizes human thinking.

Real humans writing code in the process of thinking show a mismatch between cognitive logic and code order: you define the function, define the parameters, then realize mid-traversal that you need to store references, then debate whether that cache should live inside or outside the function. This candidate was clearly transcribing the AI's streaming output from another screen — which is why, without any idea what came next, he led with the final answer. That kind of linear, deterministic progression from conclusion to code simply doesn't match the exploratory nature of human cognition.

When the Candidate Becomes the AI's Mouthpiece

The author didn't call it out immediately, but followed up: "Why use a WeakSet instead of a more conventional array?"

This question probes an important technical nuance. WeakSet is a collection type introduced in ES6, and its core distinction from a regular Set is that it holds weak references to objects. In JavaScript's garbage collection (GC) mechanism, an object won't be collected as long as there's a strong reference to it (e.g., as an array element or Set member). WeakSet references don't count toward GC's reference counting — once an object has no other strong references, the GC will automatically collect and remove it from the WeakSet, even if it's still listed there. This is precisely why knowing how to use it and knowing why to use it are inseparable in this context — if you truly understand, the answer is obvious; if you don't, you'd never think to go there.

The candidate "thought" for a moment (in reality, the AI behind the scenes was thinking) and produced a textbook answer: WeakSet won't cause memory leaks; arrays, if not cleaned up, might.

The author pressed further: "Can you swap it out for an array and construct a scenario that would actually cause a memory leak?"

Here's where the technical irony gets sharp: the candidate's current implementation placed cache inside the function, where it gets naturally destroyed when the function returns — there's no room for a leak. For a memory leak to occur using a regular array, the cache variable would have to be hoisted outside the function and remain alive, preventing GC from collecting those strong references to traversed objects. So the AI had no choice but to move that line outside the function. At this point, the author's question was being "relayed" through the candidate directly to the AI — the interview had become a face-off between the author and the AI.

When the author asked, "Why exactly does it have to move outside the function?" the AI's output grew longer and longer, the candidate completely lost the thread, and finally replied with stubborn defiance: "Because I think this way looks better. I just prefer writing it this way." The interview ended there.

The second candidate was far more honest — when pressed, he openly admitted to using AI assistance. The author actually respected that candor more.

Why "Cheating" in Interviews Is a Bad Idea

One point needs clarifying: the author isn't opposed to using AI when solving problems. What he objects to is pretending you haven't used AI — that's cheating, plain and simple.

More importantly, the candid candidate raised a question that cuts to the heart of the matter:

"In the age of Agent Coding, AI can clearly write this correctly. So as a 'driver' of AI, do I actually need to possess this knowledge myself?"

This deserves a serious answer — and a dismissive "if AI can do it, why do we need you?" isn't good enough.

75% AI Adoption Rate — So Why Do We Still Need Human Experts?

The author answered this with a set of data and a thought experiment.

First, the industry signal: Google publicly stated that the proportion of newly generated code produced by AI continues to climb, and many tech companies domestically and abroad highlight similar "AI adoption rates" in earnings calls and press releases to prove they aren't falling behind.

But the author cuts right to it: enterprises can't ultimately measure AI's value by that number. Whether it's 25% or 75%, the figure doesn't directly generate business value. What companies actually care about are end-to-end metrics — how many more features were shipped in the same cycle, how many fewer bugs appeared, how much labor cost was reduced.

This is where a critical "disconnect" emerges. Imagine an Agent generates a 30,000-line code patch. 29,700 lines are completely correct, but 300 lines have problems: they might not fully match the requirements, might have performance issues, might be poorly extensible.

This is fundamentally a context problem, and it's far deeper than "the context window isn't long enough." In software engineering, a huge amount of design constraints exist as tacit knowledge living in engineers' heads: a certain interface can't break backward compatibility because it will be called by third parties; this module sits on the hot path for high-frequency trading so latency must stay under 5ms; the security team just issued a ban on SQL string concatenation... These constraints are scattered across historical PR comments, internal wikis, verbal agreements, and years of professional experience. They can never be fully "fed" to an Agent. When doing Agent Coding, we can rarely guarantee that all relevant context about requirements has been input — performance requirements, security requirements, stability requirements, extensibility needs — these typically don't enter the context early in development, but only surface mid-project or after something breaks.

And to precisely identify those 300 problematic lines from 30,000 requires a human expert to satisfy two conditions: fully understand all 30,000 lines, and quickly locate where the issues are. You don't have to fix it yourself, but you must be able to point out where the problem is and what direction to go. Achieve that, and your one-shot acceptance rate hits 99% — but that outcome depends even more heavily on the expert who can "find the 300 lines."

In other words, the 29,700 lines are interchangeable between human and AI authorship — but the ability to find those 300 lines from 30,000 is the core of human value. The knowledge and experience that ability demands are higher than before, not lower. Industry observation broadly confirms this: AI has significantly raised the output floor for junior engineers, while simultaneously raising the ceiling on the judgment required from senior engineers.

A Closing Note: The Disorientation of a Disappearing Path

This piece ends with a question that has no standard answer.

Before the Agent explosion, the technical learning path was relatively well-defined: read the docs, acquire knowledge, enter a work environment, iterate through practice — gaps between people opened up slowly in the details and in taste. But in the Agent era, that path has suddenly been cut off. Insisting on writing code by hand can still get you the same knowledge as before, but your output efficiency falls hopelessly behind industrial demand. If you follow everyone else into rapid Agent Coding, you find that your senior colleagues already built a decade's worth of knowledge in the traditional era — as a student, "catching up" has become bewilderingly difficult.

As a hiring manager, the author can only state the desire for "stronger programming fundamentals" without being able to offer a concrete path to get there. That honesty may be the truest portrait of this moment: we all know we need more experts who can drive AI and find those 300 lines — but the road to developing that ability is still being mapped.