How do you handle feedback on your code during a code review?
Fast recall
Quick revision
Core answer
Assessing ego management and coachability—engineers who take code critique personally or defend their choices defensively don't learn quickly and create friction in collaborative environments.
Freshers claim they always accept all feedback without examples, which sounds robotic, or they frame themselves as needing convincing before accepting feedback, which signals defensiveness and closed-mindedness.
Describe a specific code review where you received substantial feedback, how you processed it without becoming defensive, what you learned from it, and concrete changes you made to your code or approach afterward.
Interview-ready guide
Interview answer
I welcome code review feedback because it's one of the fastest ways to learn.
When I get review comments, I read through them carefully without reacting defensively. If something isn't clear, I ask questions to understand the reasoning behind the suggestion.
For example, in my internship, I submitted a PR for a REST endpoint and the senior dev pointed out I wasn't handling the case where the database query returned no results—I was just calling dot get on an Optional, which would throw an exception. My first reaction was to think the controller was validating IDs, so it was fine.
But the reviewer explained that service layer code should never assume upstream validation because requirements change and someone might call the method directly. I implemented the fix using orElseThrow, and now I always handle Optional safely in my code. That lesson stuck because I understood the why, not just the what.
I don't take feedback personally—the code I wrote yesterday can always be improved, and reviewers have seen patterns I haven't encountered yet. If I strongly disagree with something, I'll respectfully explain my reasoning, but honestly that's rare as a fresher. Most feedback I get is genuinely making my code better, more readable, or catching bugs I missed.
The key for me is implementing feedback quickly and making sure I don't make the same mistake in the next review.
How do you handle feedback on your code during a code review
Direct Answer
I welcome code review feedback as a learning opportunity. I read through suggestions carefully, ask clarifying questions to understand the reasoning behind changes, and implement feedback without defensiveness. If I have a strong reason for my approach, I respectfully explain it, but I'm generally open to better ways of doing things.
Code Example
// Original code submitted for review
public class UserService {
public void updateUser(Long userId, String name, String email) {
User user = userRepository.findById(userId).get(); // Reviewer flagged this
user.setName(name);
user.setEmail(email);
userRepository.save(user);
}
}
// Reviewer comment: "What happens if userId doesn't exist? .get() throws NoSuchElementException."
// My initial reaction: "The controller validates the ID exists, so this is safe."
// Reviewer response: "Controller validation can be bypassed, always handle Optional safely."
// Revised code after accepting feedback
public class UserService {
public void updateUser(Long userId, String name, String email) {
User user = userRepository.findById(userId)
.orElseThrow(() -> new UserNotFoundException("User not found: " + userId));
user.setName(name);
user.setEmail(email);
userRepository.save(user);
}
}
// Additional feedback: "Consider validating email format before saving."
// Implemented without pushback, learned to validate inputs at service layer
Common Mistakes & Pitfalls
- Generic Claims Without Examples: Saying you always accept feedback gracefully without describing a specific code review where you actually received and implemented substantial criticism—sounds rehearsed and unbelievable.
- Framing Yourself as Initially Right: Describing feedback scenarios where you had to be convinced with multiple explanations before accepting changes—signals defensiveness and ego attachment to your code.
- Only Accepting Trivial Feedback: Mentioning you accept feedback on formatting or naming but not describing times when reviewers challenged your logic or approach—shows you're not really open to deep critique.
- Not Learning Patterns: Accepting feedback but making the same mistakes in the next code review—shows you're not internalizing lessons or updating your mental models of good code.
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.