What Reviewers Look For in a Java Code Review
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
When reviewing Java code, I look at several dimensions beyond just whether it compiles.
First is correctness. Does the code actually solve the problem it's supposed to solve? What happens with edge cases like null inputs or empty lists?
If it's calling an external API, what happens when that API is down? I test these scenarios mentally or by running the code locally. Second is readability.
If I came back to this code in six months with no context, would I understand it? Are variable names clear? Is the method doing one thing or trying to do five things?
Complex logic needs comments explaining why we're doing it this way. Third is security. This is huge in production systems.
Does the code validate user input? If it's building SQL queries, are they parameterized to prevent injection? Are we accidentally logging sensitive data like passwords or credit card numbers?
Fourth is performance. Obvious issues like looping through a million records or making a database call inside a loop need fixing before merge. Fifth is test coverage.
Does the code include unit tests? Do those tests actually verify the new behavior, or are they just placeholder stubs?
Finally, consistency with team standards. Does it follow our package structure, naming conventions, and error handling patterns?
A common mistake freshers make is only checking syntax and whether the code runs. They miss security holes or performance problems. Another mistake is approving code they don't fully understand because they don't want to seem incompetent.
If you don't understand something, that's a sign the code needs better naming or comments. Ask questions.
What Reviewers Look For in a Java Code Review
Direct Answer
Reviewers check correctness and edge-case handling, readability and naming, security vulnerabilities, obvious performance issues, and test coverage. The mental test for readability is whether you'd still understand the code six months from now with no context.
Code Example
// Reviewing this OrderController method
@RestController
public class OrderController {
@Autowired
private OrderService orderService;
@PostMapping("/orders")
public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
// Reviewer checks: Is input validated? (Missing @Valid annotation)
// Security: Can users inject malicious data? (No validation)
// Error handling: What if orderService throws an exception? (Unhandled)
// Performance: Is this method doing too much work in the HTTP thread?
// Readability: Is field injection best practice? (Constructor injection preferred)
// Tests: Are there integration tests covering this endpoint?
var order = orderService.createOrder(
request.productId(),
request.quantity()
);
// Reviewer checks: success should return 201 Created, not 200 OK
return ResponseEntity.ok(order);
}
}
The comments show the running checklist a reviewer applies to a single endpoint.
Common Mistakes & Pitfalls
- Only checking if it compiles: Freshers approve pull requests because the code runs without exceptions during happy path testing. They miss that null inputs cause crashes, or the code doesn't handle database failures. Correctness means testing edge cases too.
- Ignoring readability for working code: A method named processData that does twelve different things technically works, but it's unmaintainable. Freshers think if it works, ship it. Professionals know readable code prevents future bugs.
- Missing security implications: Freshers see code that concatenates user input into SQL strings and don't recognize the SQL injection vulnerability. They approve code that logs passwords or exposes API keys. Security requires specific knowledge freshers often lack, so they need to learn common vulnerability patterns.
- Skipping test coverage check: Code without tests will break eventually. Freshers focus on the implementation and forget to verify that unit tests exist and actually test the new logic.
Check your understanding
Answer these without looking back at the article.
- What is an N+1 query problem and how do you detect it in code review?
- What are code smells and how do you identify them?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.