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

How did you ensure you were making meaningful progress?

Did you seek additional guidance or resources?

• How did your performance improve in measurable ways?
• What impact did this change have on your team or project?
• What lasting lessons did you take from this experience?

Sample Answer (Junior / New Grad) Situation: During my first internship at a fintech startup, my manager told me in our one-on-one that my code review comments were coming across as overly critical and discouraging to other junior developers. I had been trying to be thorough but didn't realize my tone was creating friction on the team. This feedback caught me off guard because I thought I was being helpful.

Task: I needed to maintain high code quality standards while being more constructive and collaborative in my approach. My manager emphasized that as someone who would be working with the same team for the rest of the summer, building trust was just as important as catching bugs. It was my responsibility to find a better balance between technical rigor and team dynamics.

Action: I immediately apologized to my manager and asked for specific examples so I could understand the pattern better. I then reached out to two teammates I had recently reviewed code for and asked them directly for feedback on my comments. Based on what I learned, I started using a "feedback sandwich" approach and began each review by acknowledging what was done well. I also changed my language from "this is wrong" to "what do you think about trying it this way?" and made sure to explain the reasoning behind my suggestions rather than just pointing out issues.

Result: Within two weeks, one of the developers I had previously clashed with thanked me for a particularly helpful code review. By the end of my internship, my manager noted in my evaluation that I had shown remarkable improvement in collaboration skills. This experience taught me that technical excellence means nothing if you can't communicate effectively with your team, and I've carried that lesson into every role since.

Sample Answer (Mid-Level) Situation: Three years into my role as a software engineer at an e-commerce company, I received feedback during my performance review that while my technical output was strong, I was operating too much in isolation. My tech lead explained that I rarely shared knowledge in team channels, didn't participate in design discussions, and usually only spoke up when my own work was affected. The team was scaling rapidly, and my lack of engagement was becoming a bottleneck for newer engineers who could benefit from my experience.

Task: I needed to shift from being purely an individual contributor to becoming someone who actively multiplied the team's effectiveness. The expectation was clear: I should be mentoring junior engineers, contributing to architectural discussions, and helping establish best practices. My promotion to senior engineer depended on demonstrating this broader impact, not just shipping features.

Action: I created a personal development plan focused on collaboration and knowledge sharing. I started hosting biweekly "brown bag" sessions where I shared learnings from my recent projects, and I committed to reviewing at least three pull requests per day from engineers outside my immediate squad. I also began writing detailed technical documentation for the systems I owned and volunteered to pair program with two junior engineers once a week. To track my progress, I set up monthly check-ins with my tech lead specifically about these collaboration efforts.

Result: After six months, the number of direct messages I received asking basic questions about my systems dropped by 70% because the documentation was readily available. Two junior engineers I mentored told our manager that my guidance had significantly accelerated their onboarding. When promotion decisions came around, I was promoted to senior engineer with my tech lead specifically citing my transformation from a "lone wolf" into a team multiplier. The critical feedback fundamentally changed how I define success in my role—it's not just about what I build, but about how I enable others to build better.

Sample Answer (Senior) Situation: As a senior engineering manager at a SaaS company, I received pointed feedback from my director during a difficult quarter where my team had missed several key deliverables. She told me that while I was excellent at supporting my direct reports individually, I was failing to make tough prioritization calls and say no to stakeholders. The result was that my team of eight engineers was spread across twelve initiatives, leading to burnout and poor execution. This feedback was delivered after a sprint retrospective where three team members expressed frustration about context-switching.

Task: I needed to fundamentally change how I approached stakeholder management and product prioritization. My responsibility wasn't just to advocate for my team internally, but to actively protect their focus and make strategic trade-offs between competing priorities. The stakes were high—we had two engineers actively looking at other opportunities, and our product roadmap credibility with leadership was suffering due to repeated delays.

Action: I conducted a brutally honest audit of all our commitments and created a prioritization matrix based on business impact and engineering capacity. I then scheduled difficult conversations with four different stakeholders where I explicitly said no to their requests and explained our reasoning using data about team capacity and velocity. I implemented a "one in, one out" policy where we couldn't take on new work without explicitly deciding what to stop. To change my own behavior, I started every sprint planning by asking "what are we NOT doing this sprint?" before discussing what we would do. I also established a weekly 30-minute sync with my director to pressure-test my prioritization decisions before communicating them broadly.

Result: Within two quarters, our on-time delivery rate improved from 45% to 85%, and both engineers who had been considering leaving decided to stay. Team survey scores on "clarity of priorities" jumped from 2.8 to 4.2 out of 5. More importantly, I developed a reputation as a leader who could be trusted to make and communicate hard decisions. My director told me at year-end that this transformation was the primary reason she felt confident nominating me for promotion to senior manager. The feedback taught me that being supportive sometimes means disappointing people in the short term to protect the team's long-term effectiveness and wellbeing.

Sample Answer (Staff+) Situation: As a Staff Engineer leading our platform architecture across multiple teams, I received critical feedback from our VP of Engineering during a leadership offsite. He shared that while my technical vision was sound, my approach to driving adoption was creating resistance across the organization. Multiple engineering managers had privately expressed that I was being too prescriptive, mandating architectural patterns without adequately considering team-specific contexts or building genuine buy-in. One team had even built a workaround to avoid using the platform I had designed because they felt it was being forced upon them.

Task: I needed to transform my leadership approach from "architect with authority" to "architect who builds consensus." The challenge was to maintain architectural coherence across 50+ engineers while respecting team autonomy and creating a sense of shared ownership. My credibility as a technical leader was at stake, and more critically, we risked fragmenting into incompatible systems if teams continued building around the platform rather than with it.

Action: I launched a comprehensive "listening tour" where I conducted 20+ one-on-one conversations with engineers and managers across all teams to understand their specific pain points and contexts. I then facilitated a series of architecture working groups where teams could propose modifications to the platform standards based on their learnings. Rather than mandating solutions, I shifted to creating decision frameworks and RFC templates that empowered teams to make local choices within broader architectural guardrails. I also established an Architecture Council with representatives from each major team, giving them real authority to approve exceptions and evolve our standards. Most importantly, I publicly acknowledged in an all-hands that my previous approach had been too heavy-handed and that I was committed to earning trust rather than relying on title.

Result: Over the following year, platform adoption increased from 60% to 95% of new services, but this time with genuine enthusiasm from teams. The team that had built workarounds became one of our strongest advocates after we incorporated their feedback into the platform design. Three architectural patterns that emerged from the working groups became company-wide standards that were better than my original proposals. Our engineering satisfaction scores around "technical decision-making" improved by 35 percentage points. The VP later told me this transformation was a key factor in my promotion to Principal Engineer. This experience fundamentally reshaped my understanding that staff+ leadership is less about being the smartest person in the room and more about creating the conditions for the collective intelligence of the organization to emerge.

Common Mistakes

• Getting defensive or making excuses -- Focus on what you learned rather than justifying your initial behavior
• Choosing trivial feedback -- Select meaningful criticism that required real change, not just "I should comment my code more"
• Blaming the feedback giver -- Even if it was delivered poorly, demonstrate that you extracted value from it
• No concrete evidence of change -- Provide specific metrics or observable behaviors that shifted after receiving feedback
• Lacking self-reflection -- Don't just describe actions; explain what the experience taught you about yourself

Result: Over the following year, platform adoption increased from 60% to 95% of new services, but this time with genuine enthusiasm from teams. The team that had built workarounds became one of our strongest advocates after we incorporated their feedback into the platform design. Three architectural patterns that emerged from the working groups became company-wide standards that were better than my original proposals. Our engineering satisfaction scores around "technical decision-making" improved by 35 percentage points. The VP later told me this transformation was a key factor in my promotion to Principal Engineer. This experience fundamentally reshaped my understanding that staff+ leadership is less about being the smartest person in the room and more about creating the conditions for the collective intelligence of the organization to emerge.