Describe a situation where you received criticism

How did you initially respond to receiving the criticism?

What steps did you take to understand and process the feedback?

What specific changes did you implement based on the feedback?

How did you follow up with the person who gave you the feedback?

• How did your work or approach improve after implementing the feedback?
• What measurable impact did the changes have on your project or team?
• What lasting lessons did you take away from this experience?

Sample Answer (Junior / New Grad) Situation: During my first internship at a fintech startup, I submitted a code review for a payment processing feature that I'd spent two weeks building. My senior engineer reviewed it and left extensive comments pointing out that my code was overly complex, difficult to test, and didn't follow the team's established patterns. I was surprised because I thought I'd done thorough work and the feature worked perfectly in my local testing.

Task: As the developer responsible for this feature, I needed to refactor my code to meet the team's standards before it could be merged. Beyond just fixing this one pull request, I also needed to understand the underlying patterns so I wouldn't repeat the same mistakes. This was my first real code review with significant criticism, and how I handled it would set the tone for my remaining time on the team.

Action: I initially felt defensive, but I took a few hours to cool down before responding. I scheduled a video call with my senior engineer to walk through the feedback point by point instead of just reading comments. During our conversation, I asked clarifying questions about why simpler code was better, and he showed me examples from the codebase. I took detailed notes and then spent the next two days refactoring my code, applying the patterns he'd shown me. I broke my large pull request into three smaller, more focused ones, added comprehensive unit tests, and wrote better documentation. After each iteration, I asked for feedback to make sure I was moving in the right direction.

Result: My refactored code was approved and merged within a week. More importantly, my next three pull requests received minimal feedback and were praised for their clarity and testability. My senior engineer mentioned in my end-of-internship review that my willingness to receive and act on feedback was one of my strongest qualities. I learned that clean, maintainable code is more valuable than clever code, and that lesson has guided my development work ever since. I now actively seek out code reviews and see them as learning opportunities rather than gatekeeping.

Sample Answer (Mid-Level) Situation: I was leading the development of a new API service for our e-commerce platform at a mid-sized retail company. Three months into the project, my engineering manager pulled me aside after a sprint demo and told me that while the technical work was solid, my communication with stakeholders was causing problems. Product managers and designers felt out of the loop, and my manager said I was being too focused on technical details without explaining the "why" behind delays or trade-offs. This feedback caught me off guard because I thought I was being efficient by minimizing meetings.

Task: As the tech lead for this critical project, I needed to rebuild trust with our cross-functional partners while keeping the engineering work on track. I had to acknowledge that my communication style wasn't working and develop a new approach that would keep stakeholders informed without derailing my team's productivity. The API launch was scheduled for two months out, and we couldn't afford friction between teams during this critical period.

Action: I first scheduled one-on-one conversations with each product manager and designer who worked with my team to understand their specific concerns and information needs. I discovered they weren't looking for daily updates, but they wanted visibility into blockers and early warning about scope adjustments. I created a weekly written update that took me 30 minutes every Friday, highlighting progress, upcoming decisions where we needed input, and any timeline impacts. I also started opening our sprint planning meetings to stakeholders and added a 10-minute stakeholder Q&A to our bi-weekly demos. When technical issues arose, I began explaining them in terms of user impact rather than implementation details. I asked my manager for feedback every two weeks to ensure I was improving.

Result: Within a month, the product team told my manager they felt much more aligned with engineering, and one PM specifically called out the weekly updates as incredibly helpful. We launched the API on schedule, and because stakeholders had been kept informed throughout, the launch coordination went smoothly. My manager noted the improvement in my performance review and asked me to share my communication template with other tech leads. I've carried this stakeholder communication approach to my current role, and it's prevented countless misunderstandings. The experience taught me that being a strong engineer means more than writing good code—it requires making technical work visible and understandable to non-technical partners.

Sample Answer (Senior) Situation: I was leading a major architecture redesign for our data platform at a healthcare technology company, managing a team of six engineers on a nine-month initiative. Four months in, our VP of Engineering gave me feedback during a skip-level meeting that my approach was too prescriptive and I wasn't developing my team members' decision-making abilities. She observed that engineers on my team would always escalate technical decisions to me rather than working through them independently, and that several senior engineers had expressed frustration about lack of ownership. This was difficult to hear because I prided myself on being a hands-on technical leader, and I thought my deep involvement was helping the project succeed.

Task: I needed to shift my leadership style to empower my team while ensuring our critical healthcare data platform remained on track. Beyond just this project, I had to recognize that my current approach was limiting my team's growth and my own ability to scale as a leader. With five months remaining on the project, I needed to transition from being the primary decision-maker to being a coach and advisor who built up my team's technical judgment and confidence.

Action: I spent time reflecting on specific instances where I'd jumped in too quickly or made decisions that others could have made. I scheduled individual conversations with each team member to understand their perspectives on ownership and where they wanted more autonomy. Based on these conversations, I restructured our team's responsibilities, explicitly delegating architecture decisions for specific subsystems to senior engineers and having them present their approaches to the broader team. I moved from making decisions in Slack to asking coaching questions that helped engineers think through trade-offs themselves. I created a decision-making framework document that outlined when escalation was needed versus when the team should decide independently. I also started holding weekly office hours where team members could discuss technical challenges, but I resisted the urge to immediately solve problems for them. I asked the VP for monthly feedback to gauge my progress.

Result: Within two months, I saw a noticeable shift in team dynamics. Engineers began debating technical approaches with each other rather than waiting for my input, and the quality of their technical design documents improved significantly. We delivered the platform redesign on schedule, and two engineers who had been frustrated earlier told me in retrospect that the second half of the project was the most growth they'd experienced in their careers. One engineer was promoted to staff level six months later, partly due to the expanded ownership they'd taken on. The VP noted my leadership growth in my performance review and asked me to mentor other engineering managers on delegation. This experience fundamentally changed how I think about technical leadership—my job isn't to make all the best technical decisions, it's to build teams that can make those decisions without me.

Sample Answer (Staff+) Situation: As a Staff Engineer at a financial services company, I had championed and led the adoption of a new microservices architecture across our organization over 18 months. I believed this was the right technical direction and had invested heavily in building momentum. During a leadership offsite, our CTO provided pointed feedback that while the technical vision was sound, my advocacy approach had been divisive and had created factions within the engineering organization. Some teams felt the migration was being forced on them without consideration for their specific contexts, and several senior engineers had privately expressed concerns that I dismissed alternative viewpoints too quickly. This was particularly hard to hear because I'd seen the migration as a technical imperative and thought resistance was simply fear of change.

Task: I needed to acknowledge that my influence approach had created organizational friction at a time when we needed unity and alignment. Beyond this specific initiative, I had to recognize that my effectiveness as a technical leader at scale required building consensus rather than winning arguments. With dozens of teams now in various stages of migration, I needed to repair relationships, restore trust with skeptical engineers, and create a more inclusive path forward that would ultimately be more sustainable than top-down mandate. The company's technical strategy was at stake.

Action:

Result: Over the following six months, migration velocity actually increased by 40% as teams felt more ownership over their approaches. The architecture council became a trusted decision-making body that helped resolve cross-team technical challenges beyond just microservices. Several previously skeptical engineers became migration advocates and contributed significant improvements to our migration tooling. The CTO noted in my annual review that my ability to receive and act on leadership feedback demonstrated the maturity expected at the staff level. More fundamentally, I learned that technical correctness alone doesn't drive organizational change—building trust, creating space for diverse perspectives, and empowering teams to adapt solutions to their contexts are what enable transformation at scale. This lesson has shaped how I approach every strategic technical initiative since, and I now see consensus-building as a core technical skill, not a distraction from "real" engineering work.

Common Mistakes

• Being defensive or blaming circumstances -- Don't justify why the criticism was unfair or explain why you couldn't have known better. Show genuine accountability
• Choosing minor or trivial feedback -- Select meaningful criticism that required real reflection and change, not just "use more comments in your code"
• Not showing emotional honesty -- It's okay to acknowledge that critical feedback was hard to hear initially; this shows self-awareness and authenticity
• Vague actions -- Don't just say "I improved my communication." Describe the specific systems, habits, or behaviors you changed
• No follow-through or verification -- Strong answers show you checked back with the feedback-giver to confirm improvement and demonstrate ongoing application of the lesson
• Focusing only on the feedback-giver being wrong -- Even if the feedback was partially unfair, find the kernel of truth and show what you learned

Result: Within a month, the product team told my manager they felt much more aligned with engineering, and one PM specifically called out the weekly updates as incredibly helpful. We launched the API on schedule, and because stakeholders had been kept informed throughout, the launch coordination went smoothly. My manager noted the improvement in my performance review and asked me to share my communication template with other tech leads. I've carried this stakeholder communication approach to my current role, and it's prevented countless misunderstandings. The experience taught me that being a strong engineer means more than writing good code—it requires making technical work visible and understandable to non-technical partners.

Result: Within two months, I saw a noticeable shift in team dynamics. Engineers began debating technical approaches with each other rather than waiting for my input, and the quality of their technical design documents improved significantly. We delivered the platform redesign on schedule, and two engineers who had been frustrated earlier told me in retrospect that the second half of the project was the most growth they'd experienced in their careers. One engineer was promoted to staff level six months later, partly due to the expanded ownership they'd taken on. The VP noted my leadership growth in my performance review and asked me to mentor other engineering managers on delegation. This experience fundamentally changed how I think about technical leadership—my job isn't to make all the best technical decisions, it's to build teams that can make those decisions without me.

Result: Over the following six months, migration velocity actually increased by 40% as teams felt more ownership over their approaches. The architecture council became a trusted decision-making body that helped resolve cross-team technical challenges beyond just microservices. Several previously skeptical engineers became migration advocates and contributed significant improvements to our migration tooling. The CTO noted in my annual review that my ability to receive and act on leadership feedback demonstrated the maturity expected at the staff level. More fundamentally, I learned that technical correctness alone doesn't drive organizational change—building trust, creating space for diverse perspectives, and empowering teams to adapt solutions to their contexts are what enable transformation at scale. This lesson has shaped how I approach every strategic technical initiative since, and I now see consensus-building as a core technical skill, not a distraction from "real" engineering work.