Search
⌘K

How did you overcome a situation where you have been given a negative feedback?

Asked at:

U

Udemy

DoorDash

Meta

Trustpilot


Try This Question Yourself

Practice with feedback and follow-up questions

What is this question about

Interviewers use this question to assess how you respond when your self-image is challenged. They want to see whether you can receive criticism without getting defensive, understand the real issue beneath the feedback, and turn it into sustained behavior change. At more senior levels, they also look for whether your response improved outcomes beyond just your own performance.

  • Tell me about a time you received difficult feedback. What did you do with it?

  • Can you describe a situation where someone gave you critical feedback and how you responded?

  • What's an example of negative feedback you've gotten at work, and how did you improve afterward?

  • Have you ever heard something hard about your performance that turned out to be useful?

  • Walk me through a time when feedback changed how you worked.

Growth
Ownership
Communication
Leadership

Key Insights

  • You do not need a dramatic failure story. A strong answer usually features legitimate, meaningful feedback and shows a real learning loop, not a disguised strength or a trivial comment.
  • Don't stop at 'I accepted the feedback.' Strong candidates explain how they validated it, what they changed over time, and what evidence showed the change actually worked.
  • If the feedback came from someone else, show curiosity rather than defensiveness. Honest ownership of your part in the problem is a fast signal of maturity.

What interviewers probe at
level

Top Priority

Don't present feedback as a simple command to obey; show that you understood what behavior was causing the concern.

Good examples

🟢I asked my lead for examples and realized the real issue wasn't effort, it was that I waited too long to surface uncertainty when tasks got blocked.

🟢After the feedback, I reviewed a few recent pull requests with a teammate and saw the pattern: I was bundling unrelated changes, which made review slower and riskier.

Bad examples

🔴My manager said to communicate more, so I started sending more messages in chat.

🔴I was told to be more careful, so I slowed down and double-checked everything.

Weak answers apply a surface-level fix; strong answers identify the underlying behavior that needs to change.

Show that you could hear tough feedback, accept your part in it, and resist the urge to explain it away.

Good examples

🟢My first reaction was that I had been working hard, but after reviewing the examples I realized I had been sitting on blockers too long instead of asking sooner.

🟢The feedback was hard to hear because I felt I was being careful, but the examples were fair and I could see how my review habits were making life harder for others.

Bad examples

🔴My lead said I wasn't communicating enough, but that was mostly because the requirements kept changing and nobody else knew what was going on either.

🔴I got negative feedback on a bug I introduced, but it happened because I was under a lot of pressure and the tests were outdated.

Weak answers explain away responsibility; strong answers may include context, but they still clearly own the behavior.

Show a few specific changes you made consistently, not a one-time reaction right after the feedback.

Good examples

🟢I started posting a brief update whenever I was blocked for more than half a day, and I also asked a teammate to review my plan before I spent too long on uncertain tasks.

🟢I split my code changes into smaller pieces, used a simple checklist before opening a review, and for a month I asked reviewers if the changes were easier to follow.

Bad examples

🔴After that conversation I just tried to be more proactive and it got better.

🔴I made sure to pay closer attention going forward, and my manager seemed happier.

Weak answers rely on intention; strong answers describe repeatable actions and habits.

Valuable

Pick a real piece of feedback that mattered to your day-to-day effectiveness, not a fake weakness dressed up as a strength.

Good examples

🟢Early on I got feedback that I asked for help too late and sometimes spent a day stuck before raising a blocker, which slowed my small project.

🟢I was told my pull requests were hard to review because they mixed too many unrelated changes, and that was creating extra work for teammates.

Bad examples

🔴A manager told me I care too much about quality and spend too much time polishing things, which I think is just because I have high standards.

🔴Someone once said I was too quiet in one meeting, so after that I made sure to talk more in meetings.

Weak answers pick feedback that is flattering or too minor to reveal much; strong answers use believable feedback that affected team effectiveness.

Close the loop by showing how you knew the change worked, even if the evidence is simple.

Good examples

🟢Over the next few months my lead stopped needing to chase me for status, and in my next review they specifically called out that I was surfacing blockers early.

🟢Review comments on structure dropped a lot, and one of the same teammates later told me my changes had become much easier to review.

Bad examples

🔴After that I think it went better, and nobody brought it up again.

🔴I changed my approach and it seemed fine from then on.

Weak answers infer success from silence; strong answers provide concrete signs that others experienced the improvement.

Example answers at
level

Great answers

In my first few months on a backend team, my manager told me that I was waiting too long to ask for help when I got stuck. I was trying to be independent, but when we looked at a recent task together, I could see that I had spent almost a full day going in circles instead of surfacing the blocker early. After that, I started writing down my approach after about 30 minutes of being stuck and sending a quick update if I was still blocked after a few hours. I also asked a more experienced teammate to review my plan before I dove too deep into unfamiliar areas. Over the next couple of sprints, I was unblocked much faster, and my manager later called out that I was communicating risks earlier and moving work forward more predictably.

Early on in my front-end role I was told my pull requests were too large and bundled styling tweaks and small refactors with feature code, which made them hard to review and delayed merges. I’m someone who cares about polish and fixing things as I notice them, but that approach was slowing the team down. After the feedback I began breaking work into focused PRs (feature, styles, refactor), added short checklists and before/after screenshots to each PR, and used a feature flag for in-progress UI so the feature could be merged safely. I also asked a senior engineer and our designer to agree on a simple PR template for the team and followed it. Reviews became quicker, there were fewer follow-up changes, and I learned to balance wanting things to look right with keeping changes reviewable.

Poor answers

I got feedback once that I needed to communicate more while working on a task. I felt like I was already doing the work, so I didn't think a lot of extra updates were necessary, but after that I made sure to post more in chat. That seemed to address the issue and nobody really mentioned it again. I think sometimes managers just want more visibility.

Question Timeline

See when this question was last asked and where, including any notes left by other candidates.

Late March, 2026

DoorDash

Senior

Mid January, 2026

U

Udemy

Senior

Late November, 2025

Trustpilot

Mid-level

Your account is free and you can post anonymously if you choose.