Give me an example of a tough or critical piece of feedback you received.
Asked at:
Meta
DoorDash
Amazon
SoFi
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess self-awareness, coachability, and whether you can turn uncomfortable feedback into better performance. They are usually less interested in the feedback itself than in how honestly you describe it, how deeply you understood the root issue, and whether your behavior actually changed afterward.
“Tell me about a time you got feedback that was hard to hear.”
“What's a piece of constructive criticism you've received that really changed how you work?”
“Describe a situation where someone gave you feedback you didn't love at first. What did you do with it?”
“Can you share an example of a weakness or development area that was pointed out to you and how you responded?”
“What is the most valuable critical feedback you've gotten in your career?”
Key Insights
- You do not need to pick a catastrophic failure. A strong answer is usually a real, meaningful weakness that had consequences, not a disguised strength or a trivial nit.
- You should show more than compliance. Strong answers explain how you interpreted the feedback, validated it, changed your approach, and checked whether the change actually worked.
- If the feedback was hard to hear, say so without becoming defensive. Honest discomfort followed by mature action is often a stronger signal than pretending the conversation was easy.
What interviewers probe atlevel
Top Priority
You do not need to take all the blame, but you should clearly own your part instead of arguing that the feedback was unfair.
Good examples
🟢At first I felt frustrated, but after thinking about it I could see I had been trying to prove I could work independently instead of unblocking myself sooner.
🟢There were some unclear parts of the assignment, but the part I owned was not communicating early when I was stuck.
Bad examples
🔴I got that feedback because onboarding was rushed and nobody had really explained the expectations clearly.
🔴My lead said I should ask more questions, but honestly the tickets were under-scoped and anyone would have struggled.
Weak answers spend energy defending the candidate; strong answers acknowledge context while still taking clear responsibility.
Show a real improvement plan with specific behavior changes, not just a promise that you tried harder.
Good examples
🟢I started posting a brief update by midday whenever I was blocked, and I set a personal rule that if I had tried two approaches without progress, I would ask for help.
🟢I asked a more experienced teammate to review how I scoped my work for a month, and I began writing down assumptions before starting implementation.
Bad examples
🔴After that, I just made a point to be more careful and communicate better.
🔴I kept the feedback in mind and focused on improving over the next few weeks.
Weak answers rely on intention; strong answers create repeatable mechanisms that change day-to-day behavior.
Pick feedback that exposed a real gap in how you worked, not a cosmetic suggestion or a fake weakness.
Good examples
🟢Early on, my mentor told me I waited too long to ask for help and sometimes lost a day spinning on problems that someone could have unblocked in ten minutes.
🟢I was told that my status updates sounded confident even when I was uncertain, which made it hard for others to see delivery risk early.
Bad examples
🔴The toughest feedback I got was that I care too much about quality, so I needed to stop over-polishing things.
🔴A teammate told me my pull requests were a little long, but that was mostly because I was doing more work than expected.
Weak answers minimize the flaw or smuggle in a compliment; strong answers name a real developmental issue with believable impact.
Valuable
Do not end the story at the plan; explain how you knew the change was actually working.
Good examples
🟢Over the next couple of months, my mentor noted that I was flagging blockers much earlier, and I also noticed my tasks stopped slipping for the same reason.
🟢I asked for follow-up feedback at the end of the project, and my lead said the difference was that risks were now visible early enough to help.
Bad examples
🔴I think it got better because nobody brought it up again.
🔴After I changed my approach, things seemed smoother.
Weak answers infer success from silence; strong answers actively validate improvement with evidence or follow-up feedback.
Example answers atlevel
Great answers
One tough piece of feedback I got during my first few months was that I waited too long to ask for help when I was stuck. My mentor pointed out that I would spend hours trying to debug something on my own, and by the time I raised it, the ticket was already at risk. That was hard to hear because I thought being independent was the right thing to do, but I realized I was optimizing for looking self-sufficient instead of making steady progress. After that, I started writing down what I had tried and asking for help once I had exhausted two reasonable approaches or been blocked for more than an hour. I also began posting short updates when I hit uncertainty instead of waiting until the end of the day. A month later, my mentor told me my updates made it much easier to unblock me early, and my work stopped slipping for that reason.
Early in my first job a lead pulled me aside and said my pull requests were too large and detailed — they took too long to review and hid important changes, which caused integration delays. That stung because I pride myself on delivering complete, well-tested work, but I realized I was trading thoroughness for slow feedback cycles. I started breaking features into smaller, runnable increments, adding concise PR descriptions that called out the risk areas, and including focused tests so reviewers could trust the change quickly. Within a few sprints reviews were much faster, I caught integration issues earlier, and the product team appreciated that I was delivering usable progress more frequently.
Poor answers
The toughest feedback I got was that I care too much about doing things well and sometimes spend extra time making sure everything is correct. I understood the comment, but I think that is mostly a good problem to have, especially as a newer engineer. Since then I have tried to move a little faster when needed, but I still think quality should come first. Overall it did not really change much because my work was already strong.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early March, 2026
Meta
Mid-level
Early March, 2026
Meta
Mid-level
Mid February, 2026
Meta
Staff
Hello Interview Premium
Your account is free and you can post anonymously if you choose.