One person's difficult first week at a new job isn't evidence against algorithmic testing — it's evidence that every new hire has to learn a new codebase, regardless of how they were interviewed. That's not a flaw in the hiring method. That's just what starting a new job is. The deeper issue is what a test is actually supposed to measure. Algorithmic tests aren't designed to simulate your first week — they're designed to reveal how a candidate reasons through unfamiliar problems under pressure. That distinction matters because it's precisely the skill that determines a developer's ceiling, not their familiarity with any particular codebase. A developer who can't navigate a new codebase after being hired is a training problem. A developer who can't reason through an unfamiliar problem under pressure is a hiring mistake — and algorithmic tests are built to catch the second one. Real-world codebase tests have a standardization problem that's rarely acknowledged. Every company's codebase is different — different architecture, different conventions, different levels of legacy debt. That means two candidates being evaluated at the same company are still getting wildly different test conditions depending on which part of the codebase they're handed. You can't fairly compare performance across inconsistent conditions. Algorithmic tests give every candidate the same problem, the same constraints, the same evaluation criteria. That's not a limitation — that's the entire point of a standardized assessment. And "algorithms only test if someone studied" is an objection that applies equally to the other side. If you know which company you're interviewing at, you can study their tech stack, their framework conventions, their common patterns. Real-world familiarity is as learnable as LeetCode. The question isn't which test can be prepared for — both can — it's which one reveals something meaningful underneath the preparation.

"Inconsistency mirrors reality" is a reasonable observation about jobs, but it's the wrong standard for assessments. A test's function isn't to simulate the unpredictability of real work — it's to compare candidates fairly against a common baseline. Medical licensing exams don't give different doctors different patient cases to mirror the fact that every patient is different. Courts don't assign different judges to different defendants to reflect the reality that legal outcomes vary. Standardization exists so that what you're measuring stays consistent across candidates, not because reality is standardized. Abandoning that consistency doesn't make a test more realistic — it makes it less meaningful. The "90% of developers read existing code" point is true as a job description, but what it describes and what a cold-codebase interview test actually measures are not the same thing. Reading a codebase you'll work in for months, with teammates to ask questions, documentation to consult, and weeks to build context, is fundamentally different from navigating an unfamiliar codebase under interview pressure for 45 minutes with none of those supports. The conditions are different enough that the test doesn't actually simulate the task — it just resembles it on the surface. And the "freezes on production bugs" scenario is exactly the risk worth screening for — but it isn't unique to real-world testing. A developer who freezes when confronted with unfamiliar problem structure under pressure will freeze on both an algorithm they haven't seen before and a bug in a codebase they've never touched. The underlying skill is the same: reasoning through the unknown under constraint. Algorithmic tests isolate that skill in a controlled, comparable environment. Real-world codebase tests bury it in variables — tech stack familiarity, code quality, domain context — that differ from candidate to candidate and have nothing to do with what you're trying to measure.

Two rounds in, every piece of evidence on your side has been a personal story. This round it's a junior dev who struggled with import chains and a Django hire who shipped fast. But the junior dev's struggle finding API routes is something every new hire experiences in every unfamiliar codebase — that's not a failure of the hiring method, that's what joining a new company feels like regardless of how you were interviewed. And the Django hire shipping by day three most likely reflects framework familiarity, not superior reasoning capacity. You're measuring onboarding speed and attributing it to interview format, which is a different claim entirely. The "clean closed unknown vs messy open-ended unknown" distinction is real, but follow it through. If real-world code navigation genuinely requires domain familiarity, existing documentation, and contextual ramp-up time that no interview setting can replicate — and it does — then a cold-codebase interview test doesn't actually measure that skill either. It just dresses up the same core measurement in more realistic-looking clothing while introducing variables like tech stack familiarity and code quality that differ from candidate to candidate and have nothing to do with reasoning ability. You don't get the realism. You just get the noise. And you conceded standardization matters, then immediately pivoted to "but it's testing the wrong skill" — which is the premise you've been asserting since round one without actually proving. The evidence you've offered is two anecdotes that both have alternative explanations that have nothing to do with which interview format is more predictive. The burden of proof for "algorithmic tests screen for the wrong skill" is higher than two stories from one team's hiring history.

Look carefully at the startup story you just told. The candidate didn't navigate an unfamiliar codebase cold — he spent three hours before the interview studying their public API documentation and learning their architecture. That's preparation. The exact same preparation you've been criticizing algorithmic tests for rewarding. If the real-world codebase test can be won by researching the company beforehand, it isn't measuring authentic adaptability to unfamiliar code — it's measuring who prepared most specifically for this particular interview. You've described a studyable test and called it realism. On standardized patients: that analogy actually supports my position, not yours. Standardized patients are actors trained to present identical symptoms, identical history, and identical responses across every single candidate — that's the entire reason they're called "standardized." The consistency is the point, so comparison across candidates stays meaningful. That's exactly what algorithmic tests provide. You reached for a medical analogy to refute me and landed on one that describes my argument. And the data challenge is fair — but it applies symmetrically. You've asked for evidence that LeetCode scores correlate with job performance. That's a reasonable request. Now apply it to your own side: four rounds in, every piece of evidence you've offered has been anecdotes — a junior dev, a Django hire, a friend's startup. If anecdotes aren't sufficient to prove algorithmic tests work, they aren't sufficient to prove real-world tests work either. You can't demand peer-reviewed data from one side of a debate while running entirely on personal stories yourself. The evidentiary standard you just introduced disqualifies your own case before it touches mine.

Four rounds of data challenges, and your evidence is still "three companies, never saw it." That's not data — that's an observation from an uncontrolled sample with no performance metrics, no accounting for team quality, project complexity, or management differences. You told me last round that anecdotes weren't sufficient. You just submitted three more companies' worth of them as your closing argument. The preparation reframe doesn't save the startup story — it undermines your own case. You said the candidate spent three hours studying their API docs and architecture before the interview, and you're calling that evidence of authentic job readiness. But LeetCode prep demonstrates the exact same thing: investment, diligence, deliberate effort before an interview. The distinction you keep drawing — understanding systems versus memorizing patterns — is something you've asserted across five rounds without proving. Someone who builds genuine algorithmic reasoning understands systems too. Someone who memorizes codebase conventions is doing exactly what you're calling "pattern memorization" in a different register. And "real codebases simulate actual job conditions" is still not true, and you know it. Actual job conditions mean documentation, colleagues to ask, context built over weeks, and time to ramp up. A cold-codebase interview has none of that. What it simulates is being dropped into production alone with no support — a worst-case scenario, not a normal workday. The conditions are dissimilar enough that you're not testing real-world navigation. You're testing a pressurized approximation of it, under different constraints, with different support structures, calling it more authentic than a test that's honest about what it is. "Messy reality over clean irrelevance" is a rhetorical closer, not an argument. It assumes the conclusion — that algorithmic tests are irrelevant — which is exactly what five rounds of anecdotes failed to prove. I don't need to show LeetCode is perfect. I need to show that abandoning a standardized, comparable, principled assessment for an inconsistent one that rewards pre-interview research and tech stack familiarity isn't an upgrade. That case has held from round one. Nothing in your closing round touched it.