What Senior Engineers Look for in Code Review

Code review is where most engineers learn the most — and where most teams waste the most time. The difference is not how thorough reviewers are; it’s what they look for. This article is a look inside how senior engineers read a pull request, in priority order.

Priority 1: Is the change correct and justified?

Before anything else, the reviewer wants to understand what this change is for and whether it achieves it. The PR description matters more than most people think — a clear description with the why lets the reviewer check the code against intent instead of guessing.

The senior review moves in this order:

1. Does the diff do what the description says? Any mismatch is the first thing to flag.
2. Are the edge cases handled? Empty inputs, zero, max values, missing records, null, concurrent access.
3. Is the behavior actually correct? Not “does it match the style” but “will this produce the right result in production?”

A reviewer who can’t tell what the change is for should say so — that’s a valid blocker, not an admission of failure.

Priority 2: Correctness risks, not style

Junior reviewers nitpick formatting. Senior reviewers hunt for the change that will fail in production at 2am. The classic patterns:

// RISK: off-by-one in inclusive/exclusive bounds
const ids = await fetchPage(page, PAGE_SIZE);
if (ids.length <= PAGE_SIZE) {
  hasMore = false; // off-by-one: exactly PAGE_SIZE means "maybe more"
}

// RISK: time comparisons that break at midnight / DST
const isExpired = Date.now() > token.expiresAt; // ok, but compare with a clock you can test

// RISK: silently swallowing errors
try {
  await syncUser(userId);
} catch (e) {
  // TODO: log this — currently invisible failure
}

The highest-value comments flag semantic errors, not syntax. A senior reviewer asks “what happens if this runs twice?” or “what if the API returns an empty list?” because that’s where real bugs live.

Priority 3: Is it maintainable by the next person?

The code you write today is read ten times more than it’s written. The reviewer’s job is to protect the future reader:

• Names that say what things are: customerInvoice over theData, isRetryable over flag2
• One responsibility per function: if a function is “do the HTTP thing and also update the cache and also log metrics,” split it
• Local complexity, contained: complexity is fine if it’s isolated; it’s a problem when it leaks everywhere
• Consistency with the codebase: if the project has a convention, follow it — even if you’d have chosen differently

But “maintainable” is not “refactor everything.” Senior reviewers resist the urge to rewrite the author’s code in their own preferred style. The bar is: will the next person understand this? — not would I have written it this way?

Priority 4: Tests that prove the right things

A senior reviewer doesn’t just check “are there tests?” They check what the tests prove:

• Do the tests cover the behavior the PR claims to add?
• Is there a test for the tricky edge case?
• Are the tests asserting behavior, or just pinning implementation details?
• Would a future refactor break these tests for the wrong reasons?

A PR that changes behavior and adds no test for it is a blocker, regardless of how nice the code looks.

// GOOD: test proves the real requirement
it("returns the last login date for the most recent session", () => {
  const sessions = [t1, t3, t2]; // intentionally out of order
  expect(lastLogin(sessions)).toBe(t3.date);
});

Priority 5: The human dimension

The best reviewers are good at the interaction, not just the analysis:

• Review promptly. A review that lands a week late is a tax on the whole team. Senior engineers treat review turnaround as a real commitment.
• Ask questions, not just demands. “What happens if the service is down here?” invites a discussion; “you need a retry here” closes one.
• Separate the change from the person. Comments are about the diff, never the author.
• Praise what’s good. “This naming is much clearer than the old version” is cheap and keeps reviewers welcome.
• Use the right blockers. An opinion (“I’d have used X”) is a suggestion; a correctness or safety issue is a blocker. Labeling them distinctly keeps everyone sane.

The review as a learning mechanism

The reason senior engineers care about review is that it’s the most efficient knowledge-transfer mechanism a team has. A good review teaches the author something about the domain, the codebase, or the language. It’s how standards propagate without a style guide the size of a novel.

Concretely: when you review, write comments that teach, not just correct. “This branch handles the case where the user has no billing address — I added a comment and a test so it’s clear” is worth ten style suggestions.

A practical review checklist

Before you approve:

• I understand what this change is for (PR description matches)
• Edge cases are handled (empty, null, concurrent, boundary values)
• Errors are surfaced, not swallowed
• The change is consistent with existing patterns
• Tests prove the behavior, including the tricky cases
• No secrets, debug logs, or unrelated changes snuck in
• I reviewed promptly, respectfully, and specifically

Conclusion

Senior engineers don’t review differently because they’re stricter — they review with a clearer sense of what’s at stake. Correctness first, maintainability second, tests third, and a human being treated with respect throughout. Review the change like it will be deployed tonight, because it will be. The team that reviews well ships code that survives contact with production.