Tell me about a time you received critical feedback from your manager. How did you respond to it, and what did you learn?
Asked at:
Oracle
Udemy
Meta
Duolingo
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 improved performance. They are usually less interested in the feedback itself than in how honestly you received it, how deeply you understood the root issue, and whether your behavior meaningfully changed afterward. At higher levels, they also look for whether you created lasting changes that affected how others work with you.
“Describe a time your manager gave you difficult feedback. What did you do with it?”
“What's an example of feedback from your boss that was hard to hear but useful?”
“Tell me about a time your manager pointed out a weakness or blind spot. How did you handle it?”
“Have you ever gotten feedback from a manager that changed how you work? Walk me through that.”
“Can you share a situation where your manager challenged the way you were operating, and what happened next?”
Key Insights
- You do not need a dramatic failure story. A strong answer is one with real stakes, credible self-awareness, and a visible improvement loop—not a catastrophic mistake or a fake weakness dressed up as a strength.
- You should explain how you processed the feedback, not just what the feedback was. Strong candidates show curiosity, ask questions, test changes, and verify later that the issue actually improved.
- If your answer subtly argues that the manager was wrong or that the problem was mostly caused by everyone else, experienced interviewers will hear defensiveness. Honest ownership is usually the fastest positive signal here.
What interviewers probe atlevel
Top Priority
At junior level, interviewers mainly want to see that you can hear hard feedback without getting defensive and accept your part in it.
Good examples
🟢My manager told me I was waiting too long before asking for help, and they were right. I thought I was being independent, but I was actually slowing myself down and creating rework.
🟢I received feedback that my updates were too sparse during a task. I realized I was assuming people would ask if they needed something, instead of treating communication as part of the job.
Bad examples
🔴My manager said I needed to be more proactive, but the real issue was that nobody had explained the task clearly, so I just tried to ask for clearer requirements next time.
🔴I got feedback that I missed some edge cases in testing, but that was mostly because the timeline was short and I was new to the codebase.
Weak answers reframe the feedback as someone else's problem; strong answers show the candidate understood their own contribution without exaggerating or spiraling.
A good junior answer includes a realistic improvement plan you actually followed, not just a promise to do better.
Good examples
🟢I started sending short end-of-day updates on tasks that had dependencies, and I also set a personal rule that if I was stuck for more than an hour I would ask for help or propose a next step.
🟢I broke my pull requests into smaller pieces, asked a teammate to review one early as a check, and used that pattern on the rest of the project.
Bad examples
🔴After the feedback, I just tried to be more careful and keep the advice in mind.
🔴I listened to what my manager said and made a mental note to communicate more.
Weak answers rely on intention; strong answers create repeatable behaviors and guardrails.
Valuable
You should show how you knew the change worked, even if the proof is simple.
Good examples
🟢A few weeks later, my manager mentioned that my updates made it much easier to spot risks early, and reviewers were turning around my work faster because the changes were smaller.
🟢I asked for follow-up feedback after the next project, and my manager said the difference was noticeable because I was surfacing blockers much earlier.
Bad examples
🔴After that, I felt like I was doing better and there were no major complaints.
🔴I changed my approach and moved on to the next task.
Weak answers assume improvement; strong answers verify it through feedback or visible outcomes.
Example answers atlevel
Great answers
In my first year on a backend team, my manager told me that I was waiting too long before asking for help when I got stuck. I thought I was showing independence, but they pointed out that I was sometimes burning half a day on the wrong path and then creating a last-minute rush for review. I asked them for a couple of specific examples so I could understand the pattern, and I realized I hesitated whenever I felt I should already know the answer. After that, I set a rule for myself that if I was blocked for more than an hour, I would either ask a focused question or share two options I was considering. On my next project, I also sent brief updates when something might affect another person. A few weeks later my manager told me my updates were much more useful and that I was unblocking myself faster without disappearing for long stretches. The big thing I learned was that asking early is not a sign of weakness if you do the preparation first.
Early on as a junior frontend engineer on a small, fully remote product team, my manager pulled me aside and said my pull requests were too large and mixed visual changes with unrelated refactors, which made reviewers miss visual regressions and slowed down delivery. I asked for concrete PRs they found hard to review and realized I was trying to bundle everything into one ‘complete’ change rather than shipping in reviewable pieces. After that I started breaking work into small, single-purpose PRs, attaching before-and-after screenshots and a short checklist of what to look at, and I offered a quick screen-share walkthrough for anything with subtle UI behavior. Reviews became faster, fewer issues reached QA, and I got direct praise for making reviewers’ lives easier. The lesson I took away was to respect other people’s time by making changes easy to review — that discipline actually helped me iterate faster and build better user-facing features.
Poor answers
My manager once told me I should communicate more while I was working on a feature. I took that feedback and started posting more messages in our team chat so people knew I was active. After that there were not really any issues, and I think it mostly came down to everyone having different expectations about updates. In general I prefer to focus and not interrupt my flow too much, but I can adapt if a manager wants more visibility.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late June, 2026
Rubrik
Manager
Late May, 2026
Meta
Senior
Late April, 2026
Meta
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.