Why companies are moving from "solve this problem" to "explain this code"

Back with another one in the interview series. This one is about a shift I keep seeing in how companies run their technical loops: the classic "here is a blank editor, solve this LeetCode hard" round is losing ground to the code review interview, where you read existing code and explain what you would change.

I run Levelop, so I talk to a lot of engineers interviewing right now. The same story keeps coming up. People who grind algorithm problems for months get handed a 60 line pull request with a subtle bug and a question that is not "make it faster" but "tell me what you would change and why." They freeze, not because they cannot code, but because nobody told them the format moved.

AI broke the signal, not the skill

The "solve this problem" round was never really testing whether you can write a binary search. It was a proxy for whether you could reason under pressure and turn an idea into working code. The algorithm was just convenient to measure.

The moment a model could spit out a correct two pointer solution in two seconds, that proxy stopped working. If a machine produces the answer instantly, watching a human reproduce it tells you almost nothing. I went deeper on this in how AI is breaking the coding interview. So companies started asking a different question: not "can you produce code" but "can you judge code." Judging code got harder, not easier, in a world where a machine writes the first draft.

What a code review interview actually is

A code review interview hands you existing code and asks you to evaluate it: a function with a real bug, a class with a questionable design choice, or a pull request that works but would be painful to maintain. Some teams call it a code review round, some run it as a code comprehension interview, some just frame it as "explain this code." You are not starting from a blank page. You are adding judgment, the same way you would on a real software engineering team.

What you are graded on: reading unfamiliar code fast and accurately, spotting correctness bugs and not just style nits, telling a real problem from a personal preference, and suggesting concrete fixes instead of vague complaints.

A small example of what they hand you

Read this like you are reviewing a coworker's pull request.

def get_user_discount(user, cart_total):
    discount = 0
    if user.is_premium:
        discount = cart_total * 0.1
    if cart_total > 100:
        discount = cart_total * 0.15
    return cart_total - discount

It runs, it returns a number, the happy path tests are green. But the second if overwrites the first instead of combining with it. A premium user with a 150 dollar cart gets 15 percent, not 25 percent, because the second assignment clobbers the first.

A weak answer is "line five is wrong." A strong answer adds the judgment: if premium and the threshold discount are meant to stack, this is a bug because the second branch replaces the first rather than adding to it. If only the best single discount should apply, it is correct but fragile, since the order of the conditions silently decides the outcome. I would compute both candidate discounts and take the max, so the intent is visible. Same bug, completely different signal. The reasoning around the bug is the score, not the bug itself.

Why companies prefer this now

It maps to the actual job. New hires spend their first months reading the codebase and reviewing pull requests, so a code review interview is a better predictor of week one performance than a graph traversal under a timer. That is why so many tech companies now weight it in their technical interviews.

It is also harder to fake with a model. You can paste a problem into a chatbot and get a clean solution. It is much harder to get a genuinely useful, context aware critique that survives the interviewer pushing back with "are you sure that is a bug?" The follow up questions are where memorized answers fall apart.

And it scales across seniority. The same format works for a junior and a staff engineer, you just hand them harder code. None of this means algorithm rounds are dead. Big companies still run them. The shift is that code review is being added alongside, and sometimes replacing, the pure algorithm round. The Google interview loop in 2026 is a good example of a process that kept its core but changed what each round probes.

How to prepare for a code review interview

The good news is that the prep is genuinely useful work. Here is what I would do.

Read real pull requests. Open source projects on GitHub are full of merged and rejected PRs with full discussion threads. Read how experienced maintainers critique contributions and notice what they flag first. This is the highest leverage habit for problem solving on real world code, and it is free.

Do mock interviews in this format. Most people only do mock interviews for algorithm rounds. Hand a friend a buggy file and review it out loud. The interview experience of being watched while you reason is half the difficulty.

Run a checklist in order, and say it out loud:

1. Correctness    edge cases (empty, null, max size, concurrency),
                  off-by-one, overwrite, shared-state mutation.
                  Does it do what it claims? Highest weight.
2. Maintainability is the intent obvious? what breaks when
                  requirements change? hidden coupling?
3. Style (last)   naming, dead code, formatting. Only mention
                  if it genuinely hurts readability.

The mistake I made first was treating it like a timed bug hunt. I would find the broken line and stop. The candidates who pass keep talking after the find: they explain the blast radius, weigh fixes, and ask about intent. Treat "explain this code" as a skill you drill on purpose, the same way you drill two pointers or sliding window.

The engineers doing well in 2026 loops can do both. They produce a clean solution when asked, and they pick up a stranger's messy file and tell you in two minutes what is wrong, what is risky, and what they would change. The second skill used to be optional. Now it often decides the offer. The other half is being able to communicate your thought process during a coding interview, which is exactly what a review round is built to test.

Grinding 2500 problems prepares you for an interview that is slowly disappearing. The format is moving toward judgment, and judgment is something you can train. That is what the Levelop blog is built around, and you can see the whole approach at Levelop. For outside practice, the annual Stack Overflow Developer Survey is a useful pulse on how AI tools are reshaping the day to day work that these interviews now test.