Behavioral

Can you tell me about a difficult piece of feedback you received and how you handled it?

Product ManagerBackend EngineerProgram ManagerFull Stack Software Engineer

Amazon

Square

Netflix

Meta

Dropbox

Flexport

Did you come across this question in an interview?

Answers

Expert Answer

Anonymous

4.2Exceptional
When I recieve difficult feedback, I try to analyze what went wrong and how I can improve and grow from it.
At Auctane, we had small outage as during our initial phase. My Manager was not happy that we did not catch it early - to avoid customer impact. I looked at the current process of capturing and we lacked some of the metrics - instead of just  fixing and moving forward, I wanted my team and myself to own and learn from it.
I facitlited a deep dive into the root cause of the issue, by documenting and having a lessons learnt drafted by my team, I communicated to my leadrship - on what mistakes were made and what we learnt from our mistakes - we broadcasted to all the team members so that they can also learn from our mistakes. We call this document as "Correction of Errors"

Anonymous

4.6Exceptional
Situation: I was working on a new reporting feature for OneTrust, specifically adding functionality for users to set up default dashboards. In our initial enthusiasm to deliver a robust solution, we rushed into the design phase without fully understanding the project's requirements and user needs.

Feedback Received: My manager provided me with difficult feedback, pointing out that we had skipped crucial steps in the process by not thoroughly collecting user requirements upfront. This oversight had led to overly complex design concepts, threatening to bloat the project scope and delay the release.

Task: The task was to address this feedback by improving the process of collecting user requirements at the project's outset to prevent scope creep and ensure the project stayed on track.

Action:

Acknowledged the Feedback: I took the feedback seriously and recognized the importance of thorough upfront research and clear goal setting.
Led Upfront Research: I initiated cross-functional workshops with key stakeholders, including product managers, developers, and user researchers. These workshops focused on:
Collaborative Goal Setting: Clearly defining the core functionalities of the default dashboard feature to ensure everyone was aligned from the outset.
Uncovering User Needs: Conducting in-depth user research through interviews and usability testing to tailor the design to actual user needs.
Documented and Approved: I documented all the findings from the workshops in a comprehensive report, including user insights, revised project goals, and a proposed design direction. I presented this documentation to all stakeholders for review and approval, ensuring a clear path forward.
Result:

Reduced Scope Creep: Implementing these strategies contained the project scope within its original boundaries, preventing unnecessary feature creep and ensuring efficient resource allocation.
Improved Focus and Efficiency: A well-defined project roadmap allowed the entire team to maintain focus and execute the design and development process efficiently, saving time and resources.
Enhanced Team Collaboration: The collaborative workshops fostered better communication and alignment among all stakeholders, leading to a more cohesive project approach and stronger teamwork.
High-Quality Deliverables: By addressing user needs and prioritizing clarity from the start, we delivered a high-quality, user-friendly default dashboard feature that met all project requirements and provided a positive user experience.
Lesson Learned: This experience solidified the importance of thorough upfront research and clear goal setting in UX design. The feedback, although difficult to hear, was crucial in improving my approach to project management. By prioritizing these actions, I learned to ensure focused, efficient, and high-quality project execution.

Anonymous

4Strong
In the past, I received difficult feedback in the form of critiquing code. For instance, situations involved negative feedback on code organization, choice, or format. However, in cases like these I found these critiques quite useful. After receiving feedback on my code organization, I took the time to learn more about best practices in code organization and applied these principles in my subsequent projects. This significantly improved the readability and efficiency of my code. I can prevent future mistakes by using this feedback as a guide to write code in an organized and robust fashion. I value keeping composure and seek feedback as improvement for attributes/knowledge I lack.

Anonymous

4.4Exceptional
Situation: While working as a Software Engineer at Cognizant for a UK-based energy client, a high-priority business customer encountered an issue with the energy quote generation process. They were unable to generate a quote for their business energy plan, which risked incurring extra costs for the customer and potential financial loss for the client.
Task: I was tasked with identifying the root cause of the issue, ensuring compatibility across browsers and their versions, and implementing a process to prevent such incidents in the future.
Action:
  • I collaborated with the analytics team to gather data, including the customer's browser version, and successfully recreated the issue.
  • The root cause was identified as an unsupported JavaScript in-built method used in an outdated browser version.
  • Acknowledging feedback from my team lead for not catching this earlier, I established a new standard within the team: referring to MDN documentation to verify browser compatibility for JavaScript features and testing across different browsers and versions using tools like BrowserStack.
  • I also ensured rigorous testing was conducted before handing over to QA, minimizing future risks.
Result:
  • The new practice reduced customer service tickets related to browser compatibility issues by 90%.
  • This approach was recognized by stakeholders and adopted as a best practice across the team, improving overall product reliability and customer satisfaction.

Anonymous

4.4Exceptional
Initially when I joined the project, I was testing user stories and creating defects on defect management tool. In bug triage meeting, I discussed about the defects which I created and got it reviewed. However, after the meeting my supervisor gave me a critical feedback about the incomplete information in the defect.
At first I was defensive about the feedback and was little concerned. But then I soon realized that this feedback will help me improve my QA skills and processes.
So, I reviewed the defects raised by me and added all relevant information like when was the first time I noticed the issue, steps to reproduce the issue, what test data was used, which environment has this issue occurred, also updated the summary of the defect with proper wordings.
Thus, going forward I always use standard format in creating the defects like- details, steps to reproduce, expected result, actual result, test data/ payload used, any other information.
I learnt from this incident the importance of information given, which leads to quick turnaround time in resolution of the issue.
Now after standardizing the format of raising the defect by me, it is being used by other coworkers. 

Anonymous

4.4Exceptional
While working at XXY as the Director of Technology, one of my key responsibilities was to develop an Operational Excellence roadmap for the upcoming fiscal year. We were onboarding many new customers, and my CTO wanted me to lead this initiative.
After two weeks of preparation, I called a meeting to present my plan. However, I was unprepared for the depth of questions I faced, such as inquiries about our escalation strategy and ticketing process. Unable to answer many of these questions, I left the meeting feeling disheartened.
That evening, I reflected on where I went wrong. Instead of rushing to set up another meeting, I decided to take a more methodical approach. I documented my thoughts and strategies in detail, outlining a comprehensive roadmap. I then shared this document with my peers to gather additional input and feedback.
After incorporating their suggestions, I refined the document and shared it with my CTO. Following a few iterations and improvements, I felt confident that the roadmap addressed our operational requirements comprehensively.
I then called a meeting with my peers to gain their buy-in. With their support, we proceeded with the plan as documented.
The key lessons I learned from this experience are:
  1. Document Your Thoughts: Clearly articulate your strategies and approaches in writing to ensure thoroughness and clarity.
  2. Collaborate with Stakeholders: Actively seek and incorporate feedback from peers and stakeholders to strengthen your plan.
  3. Prepare for Decision-Making: Schedule meetings only when you have addressed potential edge cases and are ready to make informed decisions.

Anonymous

4.2Exceptional
Situation: While I was working at CMC Limited, during my initial days, I realized I was struggling with estimating my work. I often jumped straight into tasks without conducting thorough investigations or providing time estimates. This led to missed deadlines and increased pressure on the team.

Task: As a member of the development team, it was my responsibility to manage my workload effectively to ensure we met our project deadlines. I recognized that not providing estimates not only affected my work but also impacted the team's planning and coordination.

Action: After receiving feedback from my manager about the importance of proper estimations, I took it to heart. I began to implement a more structured approach to my tasks. I started conducting thorough investigations before beginning any work, breaking down each task into smaller components, and then estimating the time required for each. I also began using tools like Jira to track my progress and communicate with the team about my timelines.

Result: This change in my approach significantly improved my efficiency and the team's workflow. By providing accurate estimates, we were able to plan sprints more effectively, which reduced last-minute rushes and improved overall team morale. Additionally, this experience taught me the value of planning and communication in project management, skills that I continue to prioritize in my current role.

Anonymous

4Strong
During my early days at Teradata in 2015, I received critical feedback from my manager and colleagues that, although I had strong technical skills, I wasn't very vocal in expressing my opinions during discussions. I initially found this feedback difficult to accept because I believed that my work alone should be enough to communicate my value.  The task was to enhance my communication skills, particularly during team discussions and design reviews, to ensure that my thoughts and ideas were being heard and valued, rather than relying solely on the quality of my technical work.  Taking the feedback to heart, I made a concerted effort to prepare thoroughly for design discussions and technical meetings. I started to actively participate by sharing my opinions on the designs, asking questions to gain clarity, and offering my technical insights. Additionally, I sought feedback from my colleagues to better understand how I could communicate more effectively in these settings.  By consistently engaging in discussions, I found that my opinions were appreciated and valued, which led to more productive conversations and collaborations. This not only helped me build stronger relationships with my teammates but also improved my overall presence in the team. Over time, I became more confident in expressing my ideas and saw growth in my ability to communicate complex technical concepts more clearly and effectively.

Anonymous

4Strong
The scenario was once when I got feedback that my international colleague felt I was overly aggressive in our commitment to delivering for the customer and I did not consider their personal sacrifice to make sure this happened. Immediately, I took ownership of the issue, I reached out to my international counterpart, apologized and explained that I was unaware of the labor rules in his locality and made some wrong assumptions. I then listened intently to his explanation of the labor rules. I then made sure that I incorporated the rules into our communications and meeting plan, invited my colleague to comment and then socialized the new engagement plan with my team,  I apologized to the team as well and opened up for feedback as I set the expectation of how important everyone was to meeting the customer goal in a healthy fashion. The result of this action was more cohesion on the team, a slight tick up in our monthly surveys on the operating environment was also experienced, and I gained a life long friend in a remote location.

Anonymous

4Strong
The actual words were "You're not the manager, I am the manager". This was a consulting engagement where an engagement manager was managing multiple projects including mine. I was leading a pipeline migration team for a client manager, where my team was pulled in different directions because of lack of clarity in work. My first task after joining the team was to streamline these adhoc requests and gate them so that we don't drop the ball on the migration. While doing that I had to make a number of hard conversations with the client manager, where I was trying to manage scope and say no to a bunch of his requests. This included some technical requests which was usually taken by the solution architect in the team. When the engagement manager heard about that he felt that I was overstepping my authority. He felt that I was taking decisions which I should not. I politely informed him that I did not intent to be a manager, but just wanted to make sure that the correct work was driven. Also, I had had conversations with the solution architect, and we had reached on an agreement on pushing back on these requests. I also told the engagement manager that I will keep him informed of these decisions in the future. I set up a 1:1 weekly meeting with him afterwards, where we would talk about the progress and impediments, and I would discuss my approach on how to manage them.

Anonymous

4Strong
During my initial years at Amazon, I received a critical feedback from my manager and other colleagues that even though I have strong technical skills, I am not very vocal in expressing my opinions. Initially this was difficult to take as I always thought my work speaks for itself. I later started showing improvements by prepping for design discussions and actively participating in them. I noticed that my opinions mattered and people valued them. This helped me grow in my team and fostered a positive relationship with my teammates.

Anonymous

4Strong
Certainly, here's another example:

"One particularly tough piece of feedback I received was from a professor on a research paper I had worked on for months. They pointed out several flaws in my argumentation and analysis, suggesting that my conclusions were not well-supported by the evidence. Initially, I felt disheartened and frustrated, especially after investing so much time and effort into the project. However, I knew that dwelling on those feelings wouldn't help me improve. Instead, I took a step back and carefully reviewed the feedback, trying to understand where I went wrong. It was hard to accept at first, but I realized that constructive criticism is essential for growth. I revisited my research, strengthened my argument, and refined my analysis based on the feedback. In the end, the paper improved significantly, and I learned valuable lessons about humility, perseverance, and the importance of seeking feedback to enhance my skills."

Anonymous

4Strong
At center card, while I was leading the infrastructure team - my CTO asked me to come up with metrics and monitoring strategy. Initially I presented the metrics with only the Kubernetes related metrics  and the monitoring setup we need to have, my CTO was not happy and he asked me re-work on the metrics and come up with a more comprehensive data points. I realized that i need to do a deep dive with not just Kubernetes but also in relation to applications we would running on, I first gathered all the data points which was present on Kubernetes and the applications which were running on it. then I looked at the logs to understand the nature of errors - based that I came up with more precise and wholistic approach to determine the health of the system and the applications that were running on it. The lesson I learnt is that, I need to not take the feedback personally, but a way to improve on the feedback and learn from it.

Anonymous

3.6Strong
After several rewarding years at Google Home, I made the strategic decision to join the Fuchsia Organization to work on an innovative new operating system. At that time, Fuchsia was focused on replacing the Linux version powering Google Home devices, and my onboarding project was pivotal: leading the migration of smart display applications to Fuchsia. This role required me to collaborate closely with the Google Home team, which naturally limited my initial involvement with the Fuchsia team.
Early on, I received feedback that some members of the Fuchsia team viewed me as more aligned with my previous team. This input prompted me to reflect on my approach and recognize the importance of deepening my connection with the Fuchsia team.
To address this, I continued delivering on my onboarding project while intentionally dedicating time to contribute Fuchsia specific infrastructure. I also made it a priority to build relationships with my new colleagues, joining them for fun activities after work. Over time, this effort paid off, and I successfully integrated as a valued and trusted member of the Fuchsia team.

Anonymous

3.4Strong
Yes, I will give you one example that I got from my co-worker. He mentioned that the information that I prepared to discuss in the meeting is insufficient and he cannot proceed next step and have to wait until information from me is available that caused delay in feedback to customer.
What I did for this case is:
Firstly, I say thank you and apologize for the insufficient information and then I came back to review if it is really insufficient. The answer was yes, I missing to provide him about production date of the component that caused he cannot trace back production historical and checked other related information with manufacturing team. This information is part of the request from customer.
Then right after the meeting, I immediate find out that information and provided him and confirm with him if other information is required. Then he can use this information to work with other members and we can submit the required information to customer on time.
What I have learnt from this situation, 1) I have expanded this lesson learnt to other activities for example, when writing email, I have to review it carefully and ensure the information is sufficient to make it clear communicated, no rework or double job. 2) When reviewing, I have to think in different dimensions or wear different hats then I can get potential questions and I will prepare it accordingly.

Anonymous

I was responsible for performing nightly software upgrades to our DNS servers.  The upgrade script failed around 1/3rd of the time, in which case I ran a separate back-out script that undid the changes.  I assumed the systems engineer responsible for the project was checking the upgrade results when he came in for the day, and addressing the failed upgrades.  He advised me later that he expected me to notify him of on any failures, and he took my silence to suggest all upgrades succeeded.  I acknowledged that I should have provided detailed nightly reports, apologized for failing to do so, and provided complete reports going forward.  I also requested additional training on how the scripts worked and what could be done in the event of a failure.  Ultimately all of the upgrades were completed, with additional assistance from the systems engineer for the failed upgrades.
  • Can you tell me about a difficult piece of feedback you received and how you handled it?
  • Can you share with me a time when you received difficult feedback?
  • How did you handle a piece of difficult feedback you received?
  • Have you ever received difficult feedback? If so, how did you react to it?
  • Have you received any difficult feedback and how have you handled it?
  • Can you give me an example of difficult feedback you have received?
  • What is a difficult piece of feedback that you have received? When did you receive it and how did you handle it?
  • Which difficult feedback have you received and how did you respond to it?
  • Would you mind sharing a difficult piece of feedback you received and how you handled it?
  • Have you received a difficult piece of feedback? Do you know how you handled it?
  • Tell me a piece of difficult feedback you received and how you handled it?
  • Can you share an instance where you received constructive criticism that was hard to hear, and how did you manage it?
  • Have you ever been given difficult feedback that challenged you? Can you describe the feedback and how you responded to it?
  • Could you walk me through a time when you received critical feedback that was tough to swallow? How did you react to it?
  • Tell me about a piece of feedback you received that was particularly hard to hear. How did you process it?
  • Have you ever received feedback that was tough to accept? Can you tell me about the feedback and how you handled it?
  • Can you describe a time when you were given tough feedback, and how did you respond to it?
  • How have you dealt with difficult feedback in the past? Can you give an example?
  • What is the most challenging piece of feedback you have received, and how did you approach it?
  • Tell me about a time when you received feedback that challenged you. How did you manage the situation?
  • Have you ever received feedback that felt particularly harsh? How did you process it, and what actions did you take as a result?
Try Our AI Interviewer

Prepare for success with realistic, role-specific interview simulations.

Try AI Interview Now

Interview question asked to Android Engineers, Product Managers, Backend Engineers and other roles interviewing at ETRADE, Poshmark, Kajabi and others: Can you tell me about a difficult piece of feedback you received and how you handled it?.