Tell me about a time you received critical feedback from your manager. How did you respond to it, and what did you learn?

Detail your response step-by-step:

• How did you initially react to the feedback in the moment?

• What steps did you take to process and understand it fully?

• How did you create a plan to address the concerns?

• What specific changes did you implement in your work or behavior?

• Did you seek additional input or support from others?

• What improvements did you demonstrate?

• How did your manager respond to the changes?

• What impact did this have on your performance or team results?

• What lasting lessons did you take away from the experience?

Sample Answer (Junior / New Grad) Situation: During my first three months as a software engineer at a fintech startup, I was working on implementing new API endpoints for our mobile banking app. My manager scheduled a one-on-one where she told me that while my code quality was good, I wasn't communicating enough about blockers and my progress was often unclear to the rest of the team. She explained that other engineers didn't know when to expect my work or when they could build on top of my features.

Task: I needed to improve my communication practices and become more proactive about sharing status updates. My manager expected me to provide daily updates in our team Slack channel and flag any blockers within 24 hours rather than waiting for standup meetings. She also wanted me to update ticket statuses in Jira more consistently so the team had visibility into my work.

Action: I immediately thanked her for the feedback and asked for specific examples to better understand where I'd fallen short. I set up a daily reminder to post a brief update in Slack before lunch each day, summarizing what I'd completed and what I was working on next. I also started adding comments to my Jira tickets whenever I made meaningful progress or encountered an issue. When I hit my first real blocker after the conversation, I proactively reached out in Slack and set up a quick pairing session with a senior engineer rather than struggling silently for days.

Result: Within two weeks, my manager noticed the improvement and specifically thanked me for the increased transparency. Two other junior engineers on the team told me they appreciated seeing my updates because it helped them model their own communication. By the end of my fourth month, my manager mentioned in my check-in that communication was no longer a concern and I was setting a good example for newer team members. I've carried this habit of over-communicating into every role since then.

Sample Answer (Mid-Level) Situation: As a mid-level product manager at an e-commerce company, I was leading the redesign of our checkout flow with the goal of reducing cart abandonment. Three months into the project, my manager pulled me aside after a stakeholder meeting and gave me tough feedback that I was too focused on getting buy-in from everyone and not making decisions quickly enough. He said that my desire to keep everyone happy was actually slowing down the team and creating decision fatigue among the engineers who were waiting for clear direction.

Task: I needed to shift from consensus-seeking to decisive leadership while still incorporating important stakeholder input. My manager expected me to define a clear decision-making framework, reduce the number of people involved in every decision, and empower the engineering team to move faster. The goal was to cut our decision cycle time in half while maintaining quality and strategic alignment.

Action: I took a day to reflect on recent decisions and realized he was right—I had been scheduling too many alignment meetings and second-guessing choices that didn't need executive approval. I created a RACI matrix for the project that clearly defined who needed to be consulted versus informed on different types of decisions. I scheduled a working session with my manager to validate my new decision framework, which categorized decisions into three tiers based on reversibility and impact. For Tier 1 decisions, I would decide independently with my engineering lead. I then communicated this new approach to all stakeholders in a written document and started making smaller decisions in Slack threads rather than scheduling meetings. I also began protecting my engineering team's time by handling stakeholder questions directly rather than pulling engineers into every conversation.

Result: Our decision velocity improved significantly—we went from an average of 6 days to reach alignment on design decisions down to 2 days. The engineering team shipped the redesigned checkout flow two weeks ahead of schedule because they had clearer direction and fewer context switches. The new flow resulted in a 23% reduction in cart abandonment, exceeding our goal of 15%. My manager highlighted this project as an example of responsive leadership in his quarterly update to the product org. Most importantly, I learned that being a good leader sometimes means making decisions that not everyone will love, and that's okay as long as you're transparent about your reasoning.

Sample Answer (Senior) Situation: As a senior engineering manager at a cloud infrastructure company, I was leading a team of 12 engineers working on our observability platform. During my performance review, my director gave me critical feedback that while my team delivered high-quality work, I wasn't developing enough future leaders and was creating dependencies on myself. She pointed out that I was personally involved in too many technical decisions, design reviews, and incident responses, which meant my engineers weren't getting enough opportunities to grow into senior and staff roles. She showed me data indicating that none of my direct reports had been promoted in the past 18 months, while peer teams had promoted three people during that time.

Task: I needed to fundamentally change my leadership approach from being a hands-on technical leader to a coach who developed others. My director expected me to create a concrete plan for leveling up three high-potential engineers to the next level within the next year. She also wanted me to delegate more technical leadership responsibilities and step back from being the go-to person for critical decisions. This was challenging because I genuinely enjoyed the technical work and had built my credibility through technical excellence.

Action: I spent a week doing honest self-reflection and realized this feedback aligned with comments I'd dismissed from 360 reviews. I created individualized growth plans for three engineers who were ready for more responsibility, identifying specific gaps between their current level and the next. I assigned each of them as the technical lead for an upcoming project and committed to being a sounding board rather than the decision-maker. I established a weekly "leadership office hours" where any engineer could discuss technical decisions with me, but I focused on asking questions rather than providing answers. I also started documenting my technical decision-making frameworks and design principles in internal docs so knowledge wasn't trapped in my head. When the next P1 incident occurred at 2am, I consciously didn't join the call and instead let my senior engineer run the response while I stayed available for questions only.

Result: Within six months, all three engineers I'd focused on received promotions—two to senior engineer and one to staff engineer. My team's engagement scores improved by 15% in the category of "career development," and I received unsolicited feedback from my engineers that they felt more trusted and empowered. The observability platform launched two major features that I had minimal involvement in, both delivered successfully. My director promoted me to senior director based partly on my ability to receive and act on difficult feedback. This experience taught me that the highest impact of senior leadership isn't in the code you write or decisions you make, but in multiplying your impact through others. I now regularly ask my team for feedback on whether I'm over-indexing on being hands-on.

Common Mistakes

• Getting defensive -- Explaining why the feedback is wrong or making excuses rather than accepting responsibility and focusing on growth
• Staying too surface level -- Saying you "worked on communication" without specific examples of what you changed
• No meaningful change -- Describing feedback you received but not showing concrete actions you took to improve
• Lacking self-awareness -- Not acknowledging that the feedback was valid or what blind spots it revealed about yourself
• Missing the outcome -- Failing to quantify the impact of your improvements or show how the relationship with your manager evolved
• Being vague about the feedback -- Not specifying what the actual criticism was, making it impossible to understand the challenge
• Blaming the manager -- Suggesting the feedback was poorly delivered or unfair rather than focusing on what you learned

Result: Our decision velocity improved significantly—we went from an average of 6 days to reach alignment on design decisions down to 2 days. The engineering team shipped the redesigned checkout flow two weeks ahead of schedule because they had clearer direction and fewer context switches. The new flow resulted in a 23% reduction in cart abandonment, exceeding our goal of 15%. My manager highlighted this project as an example of responsive leadership in his quarterly update to the product org. Most importantly, I learned that being a good leader sometimes means making decisions that not everyone will love, and that's okay as long as you're transparent about your reasoning.

Result: Within six months, all three engineers I'd focused on received promotions—two to senior engineer and one to staff engineer. My team's engagement scores improved by 15% in the category of "career development," and I received unsolicited feedback from my engineers that they felt more trusted and empowered. The observability platform launched two major features that I had minimal involvement in, both delivered successfully. My director promoted me to senior director based partly on my ability to receive and act on difficult feedback. This experience taught me that the highest impact of senior leadership isn't in the code you write or decisions you make, but in multiplying your impact through others. I now regularly ask my team for feedback on whether I'm over-indexing on being hands-on.