At some point in your career, someone will tell you that your work isn't good enough. A manager will tell you your code is hard to read. A peer will tell you your design document is unclear. A direct report will tell you you're not providing enough direction.
This kind of feedback is not a personal attack; it is a gift. It is an opportunity to grow. However, in the moment, it can feel like a threat. Our natural, defensive instincts kick in.
The ability to override that defensive instinct, to listen with an open mind, absorb the feedback, and use it to improve is a hallmark of a mature, high-performing professional.
The interviewer is trying to answer one fundamental question: "Are you coachable?" They are listening for signals that you are:
A candidate who gets defensive or claims they've never received critical feedback is a massive red flag. It suggests they are difficult to manage and will struggle to grow within the team.
A strong answer to this question should be structured as a four-part narrative. Notice how it's a slight variation of the STAR method, tailored for this specific scenario.
"My manager once told me my code comments weren't very good. So I started writing better comments. It's all good now."
(This answer is shallow, shows no process, and demonstrates no real growth.)
"In my first year as a mid-level engineer, my tech lead, Sarah, was my main code reviewer. In one of our 1-on-1s, she gave me some tough feedback. She said that while my code was functionally correct, it was often 'too clever' and difficult for other engineers to understand quickly. She pointed out that I was using a lot of complex one-liners and obscure language features, which would make the code hard to maintain in the future."
"Honestly, my initial internal reaction was a bit defensive. I was proud of my technical skills and I thought being 'clever' was a good thing. But I made a conscious effort to pause that feeling and really listen. I recognized that Sarah was a top engineer, and her feedback was coming from a place of experience. Instead of arguing, I asked a clarifying question: 'Could you show me an example of what 'good' looks like in this situation?'"
"Her feedback prompted me to take several specific actions. First, Sarah pointed me to our company's official style guide, which I had only skimmed before. I read it cover-to-cover that night. Second, I started explicitly optimizing my code for readability, not just cleverness. I would ask myself, 'Could a new engineer understand this in 30 seconds?' If the answer was no, I'd refactor it to be simpler, even if it was a few more lines of code. Finally, in my next few code reviews, I specifically added a comment asking Sarah, 'Is this implementation clearer and easier to follow?'"
"The outcome was significant. Within a couple of months, the feedback on my code reviews changed from 'This is hard to follow' to 'This is really clean and easy to understand.' More importantly, it fundamentally changed my philosophy of software engineering—from just solving a problem to building maintainable, long-lasting solutions for a team. In a later 1-on-1, I made sure to thank Sarah for that feedback, telling her it was one of the most important lessons I had learned that year. It really strengthened our working relationship."