Technology
Why AI Coding Tools and Real-World Experience Demand a Rethink of Technical Interviews
An engineer who failed a basic tree-algorithm interview despite decades of cutting-edge work argues that LeetCode-style screening no longer reflects actual developer capability in an AI-assisted world.
InfoQ
Software developer Daniel Doubrovkine recently bombed a fundamental coding interview at a major tech company—asked to implement the diameter of a binary tree in under ten lines. Yet his résumé tells a different story: two decades building production systems, top-1% Ruby engineer status, principal engineer tenure at AWS, and a long track record of shipped code stretching back to the 1990s.
His stumble has crystallized a broader argument gaining traction in tech hiring: the traditional whiteboard algorithm interview is fundamentally broken, especially now that AI tools like Claude can solve these problems instantly.
The Disconnect Between Interview Performance and Real Capability#
When Doubrovkine recounts his experience, he notes a familiar pattern among hiring teams: rationalization. Interviewers often dismiss weak puzzle performance with excuses—rustiness, seniority, time away from daily coding. Yet his GitHub history, dating back to 2014, shows consistent contribution. His work on production systems at AWS included tackling hard distributed systems and memory-management problems far more complex than any LeetCode-style puzzle.
The deeper problem is that the interview format tests pattern recognition under pressure, not the skills that actually ship products: architectural thinking, debugging real systems, understanding tradeoffs, and collaboration with teammates. A developer comfortable implementing malloc from scratch in a timed session might struggle with the ambiguity, cross-functional communication, and incremental iteration that real software engineering demands.
When AI Changes the Game#
Doubrovkine's story takes a sharper edge when he openly uses Claude to implement the exact algorithm he failed to write in his interview. The point isn't cynicism—it's inevitability. Tools for code generation, search, and documentation are now table stakes. Refusing to use them in an interview scenario but then hiring people who must use them in production creates a false and unfair gate.
In a world where every developer has access to powerful AI assistants, the question shifts: Are we screening for the ability to think through problems and guide tools toward solutions, or for the ability to regurgitate solutions under artificial stress? Doubrovkine argues we're measuring the wrong skill.
The Pattern Across Hiring#
Doubrovkine's anecdote extends to his experience inside major companies. During his years at AWS, he observed that more than half of principal engineers who were ultimately hired had bombed their technical coding rounds. Once inside, many of those same people proved themselves exceptional. The mismatch suggests the interview is filtering for something orthogonal to on-the-job effectiveness.

