Getting Rid of LeetCode Interviews in the World of AI

Almost every developer has been asked to write an algorithm on a whiteboard, and almost every developer thinks the exercise is a poor proxy for the job. Daniel Doubrovkine's thesis is that the LeetCode-style interview never measured what companies claimed it measured — it measured recent preparation and luck — and that AI coding tools have now removed the last excuse for keeping it. His proposed replacement is not "no coding": it is a design-and-build interview in which the candidate is expected to use AI, and the interviewer watches judgment, decomposition, and recovery rather than recall.

Doubrovkine is a former CTO of Artsy.net, led the Augmented Engineering team at Shopify, and served as a Principal Engineer at AWS in New York working on OpenSearch. This 46-minute, 45-second talk was recorded at QCon AI New York 2025; InfoQ published the recording and transcript on July 29, 2026.

These notes report what he presented. Where an intermediate engineer needs background the talk assumed — for example what the specific puzzle problems actually are — that background is labeled as supplementary.

What You Will Learn

• Why a strong track record of shipping software does not predict performance on algorithmic puzzle interviews, using the speaker's own career as the evidence.
• What signal the LeetCode format actually produces, and why the usual justification of "consistency and objectivity" does not survive scrutiny.
• The concrete abuse patterns the whiteboard format enables from the interviewer's side.
• The interview loop Doubrovkine designed at Artsy: evidence of past work, T-shaped hiring, systems thinking, and reference checks weighted as half the process.
• How to restructure a system design interview so the candidate designs and builds with AI, which problems suit that format, and which behaviours to score.
• The open problems he acknowledges, including evaluation rubrics and cheating.

The Contradiction That Opens the Talk

Doubrovkine opens with an admission: roughly a year before the talk, he failed a coding interview at one of the large FAANG companies. The question was to implement the diameter of a binary tree — a problem the interviewer described as a warm-up exercise, and which Doubrovkine characterises as about ten lines including the signature and comments, five lines of real code. He froze, could not do it, and asked to end the interview early rather than waste both people's time.

He then stages the contradiction directly. To prove he can in fact produce the code, he plays a recording of the diameter being implemented on his board, made into a GIF because he did not want to type it — and then immediately concedes the point the audience is already making: Claude did it, not him. He asked for it, and it arrived. He connects that to growing up in the USSR, where getting bread or a VCR meant queuing and improvising, and observes that tools like Claude are now available to everyone, and available to everyone equally, so "we don't need to seize means of production." The argument this sets up is the one the rest of the talk develops: if the exact artefact the interview measures can be produced on demand by a tool every candidate already has at their fingertips, the measurement itself needs re-examining.

The rest of the opening exists to establish that this was not rustiness. At the time he was coding every day; his GitHub contribution graph is full going back to roughly 2014. He anticipates the objection that recent commits are AI-generated — he jokes that 2025 might be "AI slop," 2024 possibly, 2023 "cutting-edge AI slop" — and points out the graph looks the same in 2022, 2021, and 2015, before those tools existed. He claims to have written more tree structures than the audience combined: his first commercial server-side product was a C++ search engine called Alkaline, built in the late 1990s, which required a hand-written cross-platform base-classes library because the STL of the era was either unavailable or not performant enough, and which was ported to Linux, Solaris, SunOS, Windows, and IRIX. Alkaline was not a toy: it powered whereas.com, which in 1997 was the eighth most-trafficked website in the world — people went there to find serial numbers for software — serving roughly eight requests per second at millisecond response times, a load he calls completely insane for a C++ server-side search engine of that era. He also cites being ranked by the site Algora as a top 1% Ruby engineer globally in 2025 while co-maintaining around 65 Ruby gems, and six years as a Principal Engineer at AWS.

He then undercuts his own evidence deliberately. Photos of a yacht and a Lamborghini are offered as "proof" he is well paid to write code, with the audience immediately calling them fake; later he shows a tweet predicting LeetCode interviews would be gone by 2026 and says he believes the tweet itself is fabricated. The recurring point is that résumés, contribution graphs, and internet artefacts are all weak evidence — which is precisely the vacuum the puzzle interview claims to fill, and, he argues, does not.

One anecdote generalises the contradiction beyond himself: at AWS he sat in principal-engineer debriefs where, in his recollection, more than half of candidates bombed their coding interviews and were hired anyway. The room would rationalise it — too senior, rusty, has not coded in a while — which is an admission that the signal is being overridden whenever it conflicts with other evidence.

Doubrovkine characterises the problem on stage as "a totally basic DFS, Depth-First Search." Supplementary context, not from the talk: the diameter of a binary tree is the number of edges on the longest path between any two nodes, which may or may not pass through the root, and the standard solution is a single post-order depth-first search that returns each subtree's height while tracking the best left-height plus right-height sum seen so far, giving O(n) time. An LRU cache — the other problem in his stories — is a fixed-capacity key/value store that evicts the least recently used entry, conventionally implemented as a hash map for O(1) lookup plus a doubly linked list for O(1) recency reordering. Doubrovkine describes the LRU cache in these terms in passing but does not walk through either implementation.

Career Evidence That the Format Measures Preparation and Luck

Before the interviews begin, he forecloses the obvious objection that he simply never had an algorithms background. Studying computer science in Moscow in the late 1990s, he loved algorithms: he solved the Towers of Hanoi in three languages — C, Lisp, and hand-optimised x86 assembly, squeezing performance out of the implementations for its own sake — and spent long stretches in the college computer lab reimplementing tree structures and other solutions time and again. One of his classmates found an iterative solution to the n-queens problem, a genuine result that was published in a maths magazine at the time. His obsession with algorithms and data structures produced his actual first commercial product: an expression calculator, published in Germany in a 3,000-copy CD-ROM run and sold on shelves as Global Calculator, for which he was paid $3,000. The point is that the man who froze on the diameter of a binary tree had once been paid to ship exactly the kind of code a basic interview question asks for.

The talk's argument is built as a sequence of interviews spanning twenty-five years, and the pattern is consistent: outcomes tracked what he happened to have rehearsed and the conditions he was placed in, not his ability.

Two of these carry most of the argument. The AWS and FAANG results are separated only by which problem was drawn: he says plainly that the FAANG interviewer "should have asked the LRU cache." The bank result isolates a different variable — given a computer, privacy, and time, he solved the same class of problems well, and concludes he could do LeetCode questions when he could concentrate without someone breathing down his neck. The failure at Microsoft's Rotor team adds the psychological dimension: standing at the board trying to implement a memory allocator, he flashed back to failing a university analysis exam twice in his second year, after which he had to spend four months preparing for the single retake under the risk of being kicked out of the maths faculty — and the self-doubt compounded the failure. He also notes the human cost of that failure — he did not get a job he badly wanted, on a team porting .NET to Linux, after having built exactly the relevant experience. That experience was a second, different from-scratch C++ container library, written for the Netdocs server at Microsoft: where Alkaline's base classes existed to be portable across operating systems, this one existed to defeat the memory fragmentation that killed long-running Windows servers, by keeping allocations on the stack as far as possible and spilling into virtual memory only when the stack ran out. He describes it as STL for servers, implementing trees, graphs, vectors, and strings from nothing.

What the Format Enables From the Interviewer's Side

Doubrovkine is unusually candid that he enjoyed administering these interviews, and he lists the techniques he used and wrote about at the time. He frames them as things a Russian upbringing made him good at, and as an abuse of power he later regretted, not as recommendations.

• The insulting warm-up. Take a candidate who is a credentialed expert in algorithms and ask them to reverse a string. They will comply reluctantly because they have to.
• Isolation. Put them in a room and leave them there, then see how long it takes before they ask for water. He took this one directly from his own bank interview.
• "Now solve it a different way." Ask for an alternative solution regardless of whether one exists; when the candidate says they do not know of another, end the interview. He describes this as destroying the ego.
• Abandonment mid-problem. Tell them to keep working, leave for a cigarette or coffee, come back, observe them stuck, and optionally end the session there.

The counterpart story is the VP of Engineering candidate his startup interviewed: a credentialed candidate who introduced himself as someone who writes code all day, every day. Doubrovkine asked whether he would write a sort on the whiteboard if asked. The candidate said of course; when actually asked, he said that if the request was serious he was walking out of the room, and Doubrovkine told him to feel free. At the time he was certain the team had dodged a bullet. In retrospect the story reads differently — he notes there were many reasons that candidate was not hired, and that the company itself later failed for lack of money, with the software being fine. The interview theatre made no difference to the outcome that mattered.

The regret had a lasting operational form. For years afterwards, whenever he was required to run a whiteboard round, he would open it by apologising to the candidate and framing the exercise as something the two of them were going to have to work through together — his way of signalling that he knew the format was indefensible even as he administered it.

The Alternative He Built at Artsy

At Artsy the constraint was structural: good engineers are not queuing at the door of a startup nobody has heard of, and, as he puts it, the offer is essentially half the money for twice the work. So the loop was designed deliberately around evidence rather than hypotheticals.

The centre of the process is asking what the candidate has actually made. He demonstrates the questioning style with a deliberately absurd example — a candidate who worked on reticulating splines is asked what a spline is, how you build one, how you reticulate one, and how many they reticulated — the point being that a naive interviewer who genuinely knows nothing about the domain can still probe depth by asking the candidate to teach it. The target profile was T-shaped people, defined in Key Terms below. His favourite hiring example is an engineer he met at an art-and-technology conference, where each pair had to split hardware and software work on a small blinking art project. She took the soldering iron, blew up the circuit on the first attempt, guessed that flipping the cables might work, resoldered it, and it worked. He was impressed specifically by the trial-and-error instinct, which he says is how he codes. She turned out to have an MFA in painting from RISD before learning to code at Flatiron School, became Artsy's first junior hire, and fifteen years later runs a software consultancy.

The full loop had roughly five parts. An engineer interview covering past work. An interview focused on the human: how you collaborate, drawn from experience working with other engineers, tested against the reality of a ten-person company where you know everyone. A check that you can do the coding job — but conducted by discussing code you already wrote, ideally open source, or a take-home assignment discussed afterwards if you have no public history. A systems whiteboarding round, because designing systems is a separate skill from writing code, and because the questions the candidate asks during design are themselves the signal. Finally a round with a director or above, largely for the candidate to ask about the company, plus competency questions on values alignment and growth potential.

Crucially, all of that was only half the process. The other half was reference calls: talking to people the candidate names and asking what this person built, whether they were good, why they were the best on the team, why we should hire them. He compares this to an NPS score (see Key Terms), and states flatly that it turned out to be a much better signal about ability than coding tests. Candidates were sourced heavily through open-source collaboration, and some wrote publicly about how it felt to go through an interview with no coding puzzles in it.

On the take-home component, he clarified in Q&A that its purpose is not assessment in isolation but to create shared material for a conversation. Not everyone has open-source history, and someone straight out of college may have none at all. The take-home gives the panel a problem the candidate solved thoroughly at home, with or without AI, that can then be discussed: is this code performant, is it interesting, are there other ways to solve it — reasoning rather than recall.

Why the Stated Justification Does Not Hold

When Doubrovkine asks companies why they still run whiteboard coding, the most common answer he gets is that they want a consistent, fair, objective process that produces uniform, evaluable signal about every candidate. His response is to ask what the signal actually is. If the claim is "the candidate can code," his own history refutes it: none of his interviews demonstrated to anyone whether he could code, and the passes came down to luck. His conclusion is that asking a deep algorithmic question tells you the candidate is good at deep algorithmic questions, or that they got lucky, and nothing more.

He also attacks the format's lineage. Whiteboard coding descends from the punch card era, when code was written on paper and submitted to a machine. The bank that gave him a computer in 2004 was already an improvement on that. AI, in his framing, is simply a much faster horse than the computer that replaced the punch card — and candidates are adapting to it far faster than hiring processes are. That adaptation includes cheating: he points out that in his remote FAANG interview he could have had a second machine behind the monitor listening to the question and producing the answer, and would probably have passed. The format's claim to objectivity is therefore being eroded from both ends at once.

His prediction is deliberately unromantic. He does not believe LeetCode interviews will be gone by 2026, because a lifetime of process has been built on top of flawed assumptions, but he expects the industry to catch up sooner rather than later. He names Shopify as a company that has encouraged AI use in interviews for a long time and does it well, speculates that Meta might follow, and frames the choice for companies as adapt or face extinction because nobody will want to work there.

Redefining the Interview Loop for the Age of AI

The forward-looking half of the talk starts from a conversation with an executive recruiter at a firm he names as People Project. Her observation is that every company is now asking how to make developers more productive, and that the real differentiator in productivity is not the AI tooling but human skills — empathy, ethics, collaboration, judgment. Those matter more than the code you can personally write, because the tools write much of the code.

From that he derives a simple rule: if you want to be an AI company, hire people capable of using AI, which means interviewing them with AI so you can see how they use it. The coding interview is the natural place to do it. The question becomes whether the candidate can multiply the skills that matter using the machine, not whether they can reproduce an algorithm from memory.

The concrete change is to the system design interview. In a traditional 45-minute design slot you draw boxes on a whiteboard and stop, because there is no time to implement anything. With AI writing the code, the candidate can be asked to design the system and build it by prompting the model. That converts a hypothetical discussion into an observable one: how they break problems down, how they handle curveballs, whether they write tests, whether they can iterate when things break, with a very fast partner.

Good problems, he argues, have not changed. They should be big enough to require clarifying questions, admit multiple solutions, need iteration, and not reduce to copy-paste. The goal is to reveal the individual's skills, so the problem should be fairly open-ended: start a little vague, reach a milestone, throw a complication, extend it. His preferred examples are autoscalers (with follow-ons like leader election or stuck pods if you push it toward a Kubernetes operator), rate limiters (how do you stop abuse across a distributed system in fifty regions), event-ingesting data pipelines, and building an AI chat system, which he likes because everybody has direct daily experience of one.

He is emphatic that this is not a rewrite of the whole loop. The same interview features apply; the only change is that you also observe how the candidate uses the tools. For candidates, he points to an existing public list of companies that do not do whiteboard coding — arguing that the norm should be the default and the list should not need to exist — and says he could not find an equivalent list of companies that encourage AI in interviews, so he created a GitHub repository for one, using Claude, and invited the audience to add their employers.

On scoring, asked in Q&A how evaluation stays consistent across many different managers running these interviews, he said he is working with people looking into rubrics and evals, and that the structure is largely the same as before: red flags and green flags. Most criteria are unchanged — do you ask questions before implementing anything, do you ask questions of the interviewer, do you ask questions of the AI, and what kind of questions are they. He offers one genuinely new anti-pattern: if a candidate prompts the AI to write code and then sits down to read that code line by line, he treats it as a warning sign, because in his view you want to stay an abstraction layer above the output and work at the level of systems — for example writing a test and making the test pass, rather than manually verifying as a human that generated code works. That is his opinion about working style, not a measured result.

Asked separately whether he still cares about code at all, he said the code itself is not what he is evaluating: he wants to see code you wrote in a past life and reason about it together, and for senior engineers the interview should be design the system and implement it. What he is mostly interested in is how you think, and specifically whether you can get unstuck when the AI produces something that does not work.

He closes on role drift: he now sees designers vibe coding entire features as prototypes rather than staying in Figma, and expects roles to keep evolving in ways nobody can predict. For engineers inside large companies who believe they cannot change entrenched hiring process, his suggested lever is political — quote your own CEO's statement that every company is now an AI company back to the recruiting organisation, and ask whether an interview loop that prevents you from hiring people who know how to use AI is compatible with that.

Architecture And Data Flow

The diagram below is my rendering of the AI-era design-and-build interview as Doubrovkine described it in sequence; he did not present an architecture diagram in the talk.

flowchart TD
    A["Deliberately vague open-ended problem
(autoscaler, rate limiter, pipeline, AI chat)"] --> B{"Does the candidate ask
clarifying questions first?"}
    B --> C["Candidate designs the system"]
    C --> D["Candidate prompts AI to implement it"]
    D --> E["Milestone reached"]
    E --> F["Interviewer throws a complication
(leader election, stuck pods,
abuse across 50 regions)"]
    F --> G{"Can they get unstuck when
the AI output does not work?"}
    G --> D
    E --> H["Interviewer extends the scope"]
    H --> D
    G --> I["Signals: decomposition, curveball handling,
testing discipline, iteration,
questions asked of human and AI"]

The important structural property is that the loop between prompting and complication runs several times inside one slot. In the whiteboard version of the same interview, the process stops permanently at the design box.

Trade-offs And Limitations

The evidence base is anecdotal, and Doubrovkine does not pretend otherwise. His opening claim that every developer he asked hates these interviews is presented as a joke about data provenance — the "source" on the slide is a fragment of Python, not a study. The career sequence is a single person's experience, the AWS debrief statistic is his recollection rather than a measurement, and the Artsy process is reported as having worked without any comparative hiring outcome data. Treat the argument as a well-constructed existence proof that the format can fail badly on a strong engineer, not as a quantified effect.

Consistency remains genuinely unsolved. The objection raised in Q&A — that many different managers running open-ended AI interviews will evaluate differently — is the strongest version of the case for standardised puzzles, and his answer is that rubrics and evals are still being worked out. Adopting this format means accepting evaluator variance in exchange for richer signal, and investing in calibration you will have to build yourself.

Reference checks carry their own bias. Doubrovkine weights them at half the process and reports them as the best signal he has seen, but by construction they favour candidates with established professional networks. Supplementary observation, not from the talk: that is the same population-level fairness concern that anonymous algorithmic tests were originally introduced to address, so a loop built on references plus public open-source history can disadvantage career changers and people from less connected backgrounds. He partially addresses this through the take-home option for candidates with no public history, but the tension is not resolved in the talk, and take-homes shift cost onto unpaid candidate time.

Cheating does not disappear; it changes shape. This is my analysis rather than a point Doubrovkine made: making AI use explicit removes the incentive to hide a second machine, but it does not by itself distinguish a candidate who directs a model well from one who is reading answers. The interviewer's ability to throw curveballs and watch recovery is the actual control here, and it only works if the interviewer keeps pushing past the first working milestone.

Finally, the transition is slow and partly political: beyond internal pressure, he offers no mechanism for changing an entrenched loop. One further caveat is mine rather than his: the read-the-generated-code anti-pattern sits uncomfortably beside ordinary code review practice, and an interviewer who scores it mechanically could penalise careful candidates.

Practical Takeaways

Most of these follow directly from Doubrovkine's recommendations. The operational details — budgeting the slot for interruptions, auditing your own loop for the abuse patterns he described — are my suggestions for applying his position rather than his prescriptions.

• Replace the algorithm puzzle with the evidence you already have. Ask what the candidate built, then ask them to teach it to you from first principles and keep asking until you hit the edge of their depth.
• If you keep a coding round, let it be a design-and-build round with AI enabled, and budget the slot so the interviewer can interrupt with at least one complication after the first milestone.
• Score behaviour, not output: clarifying questions asked before implementation, questions asked of the model, test-first iteration, and recovery when the generated code is wrong.
• Weight structured reference conversations far more heavily than most loops do, and ask specific comparative questions rather than confirming employment dates.
• Offer a take-home only as conversation material for candidates without public work, and spend the interview discussing alternatives and performance rather than grading the artefact.
• Audit your own loop for the abuse patterns above — insulting warm-ups, isolation, unanswerable "solve it another way" demands, abandonment — because they are properties of the format, not of bad individuals.
• If you cannot change your company's process directly, escalate it as a strategy contradiction: an interview loop that filters out AI-capable engineers is incompatible with a stated goal of becoming an AI company.

Key Terms

• LeetCode-style interview — A timed live interview built around self-contained algorithmic puzzles, named after the practice site; the target of the talk's argument.
• Whiteboard interview — Writing code by hand on a board with an observer present, a format Doubrovkine traces to the punch card era of submitting code written on paper.
• T-shaped engineer — Someone with a broad set of interests across many areas plus real depth in a narrow specialty; Artsy's explicit hiring target.
• Reference-as-NPS — Treating reference calls like a net promoter score, the customer-loyalty metric that asks how likely someone is to recommend a product: here, how many people who have worked with a candidate would actively recommend working with them again.
• Pair programming interview — Writing code jointly with an interviewer rather than being observed solving alone; the format Doubrovkine encountered for a manager role at Shopify, where managers are expected to code.
• Vibe coding — Producing working software primarily by prompting an AI rather than authoring the code directly; he cites designers building entire feature prototypes this way.

The talk's closing position is that the whiteboard was replaced by the computer, and the computer is now being replaced by AI, but the interview never moved. The useful signal was always human judgment — how someone breaks a problem down, what they ask before they build, and whether they can recover when the machine hands them something broken — and that signal is now easier to observe, not harder, if you are willing to hand the candidate the machine and watch.

Reference: Daniel Doubrovkine, Getting Rid of LeetCode Interviews in the World of AI, QCon AI New York 2025, published by InfoQ on July 29, 2026.