The first time your Pull Request gets a dozen comments can feel unpleasant. It can seem like everything you did was wrong. But on a healthy engineering team, code review is completely ordinary — even senior engineers get comments on their PRs.

This article explains what code review is, what usually gets checked, and how to respond to feedback in a way that helps you grow fast.

What is code review?

Code review is the process of having someone else check code changes before they're merged into the main codebase. On teams that use GitHub, code review usually happens inside a Pull Request: reviewers read the diff, comment on specific lines, then approve or request changes.

The goal of code review isn't to find fault with people, but to:

maintain quality of the codebase over the long term,
catch problems early, while they're still cheap to fix,
spread knowledge about the code to more people,
align standards for how the team writes code.

What do reviewers check?

Every team has a different focus, but these are almost always examined.

1. Correctness

Does the code do what it's supposed to? Are edge cases handled — empty data, invalid input, or errors from other services?

2. Readability

Do variable and function names explain their intent? Are functions too long? Code is read more often than it's written, so readability matters a lot.

3. Design and structure

Are responsibilities clearly separated? Does the change follow patterns already used in the codebase? Is there duplication that should be consolidated?

4. Performance

Are there patterns that will be slow as data grows? A classic example is the N+1 query: fetching a list of data, then running an extra query for each item inside a loop.

// N+1: 1 query for the order list + 1 query per order
const orders = await db.select().from(ordersTable);
for (const order of orders) {
  order.customer = await getCustomer(order.customerId);
}

With 1,000 orders, this code runs 1,001 queries. Reviewers will usually suggest fetching the related data in one go, for example with a join or a single IN (...) query.

5. Security

Is user input validated? Is sensitive data being written to logs? Is data access restricted according to user permissions?

6. Type safety and error handling

Are data types clearly defined, or is there a lot of any? Are errors handled, or silently swallowed?

7. Testing

Does this change have appropriate tests? Are existing tests still relevant?

Example review comments

Good review comments are usually specific and explain the reasoning. For example:

"This function handles validation and saves to the database. How about splitting out the validation so it can be tested on its own?"
"The query inside this loop runs once per item. Could we fetch it all at once with a join?"
"If user is null here, the page will crash. Should we handle that?"
"Nit: data2 doesn't describe what it holds — maybe paidOrders?"

The prefix "nit" (from nitpick) is commonly used for small, optional suggestions. Distinguishing required from optional helps the PR author prioritize.

How to respond to code review

Separate the code from yourself

Review comments assess the code, not your ability or worth as a person. The sooner you separate the two, the faster you learn.

Understand before replying

Read the comment until you really understand what it means. If it's unclear, ask: "You mean the case when X, right? Could you give a quick example?"

Respond to every comment

Reply to comments with the action you took:

"Fixed in commit abc123."
"Agreed, split into a validateOrder function."
"I kept it because of Y — what do you think?"

Marking comments as addressed helps reviewers re-check quickly.

It's fine to disagree — with reasons

If you have a strong reason for your approach, explain it calmly and openly. Healthy technical discussion produces the best decisions. If you can't reach agreement, follow the team's conventions or ask a third person for their view.

Note recurring patterns

If the same comment appears across several PRs, it's a sign there's a habit to change. Write it down, then check for it yourself before opening your next PR.

Checklist before requesting review

Before hitting Request review, check:

I've re-read the whole diff as a reviewer would.
No leftover console.log, commented-out code, or accidentally included files.
The main edge cases are handled.
Tests and automated checks pass.
The PR description explains what, why, and how to test.

If you don't have a reviewer

Learning alone makes code review hard to come by. Some alternatives:

Self-review with a break. Re-read your code the next day; you'll see it with fresh eyes.
Communities and open source. Contributing to open source gets you reviews from maintainers.
Automated tools. Linters, type checkers, and AI-based review can catch many common issues. Their strengths and limits are covered in AI in Software Development.
Review-based programs. Some programs make reviewing every Pull Request the core of practice.

Conclusion

Code review is a normal and important part of an engineer's work. Reviewers usually check correctness, readability, design, performance, security, type safety, and testing. The best way to respond is to separate the code from yourself, understand before replying, respond to every comment, and learn from recurring patterns.

If you want to get used to code review before your first job, the KodingCamp software engineer job simulation reviews every one of your Pull Requests — including things like N+1 queries, type safety, and code structure.

Code Review for Beginners: What Reviewers Check and How to Respond