When reviewing a pull request for a .NET backend service, what do you look at beyond whether the code compiles?

What do you look for in a pull request for a .NET backend service?

Explains practical pull request review signals for .NET services, including tests, API contracts, migrations, configuration, and operational impact.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I first understand the intended behavior and keep the review scoped to that change. I check API contracts, validation, authorization, error behavior, data access, and whether the tests prove the important outcomes. I also look for accidental secrets, unsafe configuration, or public compatibility changes. My comments explain the concrete risk and distinguish blockers from suggestions.

Full answer below

Practice focus

Code review judgment, maintainability, API compatibility, test coverage, migration risk, and production ownership.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A pull request review protects contracts, runtime behavior, and maintainability while sharing context across the team. Compilation is only the first check.
I first understand the intended behavior and keep the review scoped to that change. I check API contracts, validation, authorization, error behavior, data access, and whether the tests prove the important outcomes. I also look for accidental secrets, unsafe configuration, or public compatibility changes. My comments explain the concrete risk and distinguish blockers from suggestions.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I then follow the failure paths: cancellation, retries, transactions, concurrency, null or invalid input, downstream failure, and observability. For EF Core changes I inspect query shape, migrations, indexes, and transaction boundaries rather than trusting that a test merely passed. I avoid rewriting the author's code to match personal taste; style belongs in shared tooling and conventions unless it affects clarity or correctness.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Reviewing only formatting and naming.
Approving large risky PRs because tests pass.
Ignoring migration and deployment impact.
Giving vague comments without explaining the risk.

When reviewing a pull request for a .NET backend service, what do you look at beyond whether the code compiles?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Suggest an improvement