Manual code reviews in interviews feel like a memory test rather than a skill test

I aced my technical questions and demos in a tech interview last Friday, but the manual code review sent me into a spiral. It raises a frustrating question: who actually gets to decide the "bar" for potential? When a recruitment pipeline passes on you, is it because of a standardized score, or does the whole thing pivot on one specific moment where you missed a detail?

Manual code review is often marketed as a way to see "how a candidate thinks," but the environment is completely wrong for that. I currently manage 12 projects across 4 different systems; I don't spend my days staring at raw code without tools, and I certainly don't do everything in Rust. Does struggling with a manual review make someone incompetent, or just out of practice with an archaic workflow? In a real production environment, we use benchmarks, write tests, and let AI do the initial sweep to provide context and fix obvious errors. Using those tools doesn't mean a developer needs "hand-holding"—it's just how the work is actually done.

Reviewing untestable code during an interview is more of a trap than a proficiency check. If you're asked to review a caching system but haven't built one in three years, you're relying on memory, not skill. Skill is the ability to implement a mandate correctly; memory is just remembering a specific pattern from the past. These are not the same thing.

The industry seems to conflate "years of experience" with talent. During my review, the interviewer noted that I caught a [u8; 16] for sha256 and mentioned that "not many people caught that one." I only caught it because I've dealt with it recently. Does that make me a one-trick pony, or does it just mean that specific snippet happened to be in my recent "training data"? A developer with 20 years of experience might spot more patterns, but if a 10-year veteran dealt with a specific problem last month and the 20-year veteran dealt with it a decade ago, the 10-year dev is likely to write the better solution.

If pattern recognition is just a byproduct of what we've personally encountered recently, then the "bar" for hiring is completely arbitrary. We aren't hired to be human compilers. From a business perspective, the only metric that should matter is ROI—what value does the hire bring to the company today? When a tool like Claude costs $20 a month, the value proposition for a human developer has to be about innovation and creation, not how well they can spot a syntax quirk in a whiteboard exercise.