What to Check in a Code Review
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
When I review someone else's code, I check several things systematically.
First is correctness. Does the code actually solve the problem it's supposed to solve? I test it mentally with edge cases.
What happens if the input list is empty? What if the database call times out? What if a user passes a negative number?
I also look at whether the code handles errors properly. If an API call fails, does the code catch that and return a meaningful error message, or does it just crash with a stack trace? Second is readability.
If I came back to this code in six months, would I understand it without asking the author questions? Are variable names descriptive? Is the method doing one thing or trying to do five things?
If I see a method called processData that parses JSON, validates business rules, updates the database, and sends notifications, that's too much responsibility in one place. Third is security. This is critical for production systems.
Does the code validate user inputs? If it's building SQL queries, are they parameterized to prevent injection? Are there any hardcoded passwords or API keys that should be in environment variables?
Freshers often miss security issues because they focus on making the feature work. Fourth is code duplication. Is the same logic repeated in multiple places where a shared utility method would work?
Duplication creates maintenance problems because if you fix a bug, you have to remember to fix it in all three copies. Fifth is consistency with team standards. Does the code follow our package structure, naming conventions, and architectural layers?
For example, controllers should call services, not repositories directly. That separation matters for testability and maintainability.
A common mistake freshers make when reviewing is only checking formatting and syntax. They approve code because it compiles and passes the linter, but miss that it doesn't handle edge cases or has a SQL injection vulnerability. Another mistake is not actually running the code.
You should pull the changes locally and test with unusual inputs, not just read through it. One thing to remember is that code review is a learning opportunity for both people. When I find an issue, I explain why it's a problem and suggest a better approach.
That helps the author understand patterns to apply in future code.
What to Check in a Code Review
Direct Answer
Check for correctness and edge cases, readability and naming, proper error handling, code duplication, security issues like SQL injection or exposed credentials, and adherence to team standards and architectural layering. Code review is a learning tool, not a fault-finding mission.
Code Example
// A reviewer dry-runs edge cases instead of only reading the happy path.
public class ReviewChecklistDemo {
public static void main(String[] args) {
System.out.println(safeDivide(10, 2)); // 5
System.out.println(safeDivide(10, 0)); // 0 (guarded, instead of ArithmeticException)
}
static int safeDivide(int a, int b) {
if (b == 0) return 0; // the correctness guard a reviewer would insist on
return a / b;
}
}
Running the awkward inputs in your head — zero, null, empty — is how reviewers catch bugs the author missed.
Common Mistakes & Pitfalls
- Only checking formatting and syntax: Freshers approve code because it compiles and follows style guides, missing that it has security vulnerabilities or doesn't handle errors. Syntax is the least important thing to review.
- Skipping the test run: Freshers read code but don't pull it locally to test edge cases. You should actually run the code with unusual inputs to verify behavior, not just read it.
- Missing architectural violations: Code that works but violates the project's layering—like a controller calling the repository directly instead of going through the service—creates technical debt. Freshers focused on immediate correctness miss these structural issues.
- Approving without understanding: When freshers don't understand code, they approve it anyway to avoid seeming incompetent. If you don't understand something, that's valuable feedback—it means the code needs better documentation or simpler structure. Ask questions.
Check your understanding
Answer these without looking back at the article.
- How would you give feedback in a code review without coming across as harsh?
- What's the difference between a blocker and a suggestion in a code review?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.