51. Tell me about a time your work was criticized
Use a real criticism event, explain how you responded in the moment, and show what you changed afterward.
Use STAR to structure your answer: briefly explain the Situation and Task, make Action the most detailed part, and finish with the Result. For example, describe a real situation where someone criticized an important part of your work, explain how you listened and clarified the concern without becoming defensive, show how you evaluated the feedback and changed your implementation, and explain what you learned from the experience.
In my last role, I completed a change to a .NET API that handled a business workflow. During code review, a senior developer criticized my implementation because too much business logic was inside the controller. The code worked, but the reviewer said the design would become difficult to test and maintain as the workflow grew.
I was responsible for delivering the change while keeping the service easy to maintain. I also needed to respond professionally to the criticism, understand whether the concern was valid, and make the right changes without turning the review into an argument about whose design was better.
My first response was to ask the reviewer to walk me through the parts that concerned them most. I avoided defending the code immediately because I wanted to understand the reasoning behind the feedback. We reviewed the controller together, and I saw that it was handling request validation, business decisions, and data access coordination in one place. I agreed that this made the controller responsible for too many things. I moved the business rules into a separate service and kept the controller focused on receiving the request, calling the service, and returning the response. I also separated the data access logic behind an existing repository abstraction so the business logic could be tested without depending directly on the database. After making the changes, I added focused unit tests around the service and asked the same reviewer to look at the revised version. I also changed my own review process afterward. Before opening future pull requests, I started checking whether each class had one clear responsibility and whether important business rules could be tested independently.
The revised code was easier for the team to review, test, and extend, and the change was accepted. More importantly, I learned not to treat criticism of my code as criticism of me. When feedback is specific and technically justified, I try to understand the concern first, improve the work, and carry the lesson into future designs.
Interviewers ask this question to see how a candidate reacts when their work is challenged. A strong answer shows that the candidate can listen without becoming defensive, evaluate feedback objectively, communicate professionally, take ownership of improvements, and apply what they learned to future work.