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

Question

Anonymous · Accepted Answer

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 · Answer

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.

Aaron · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

I was working on the large scale entrprise wide program that included multiple
teams and stakeholders .During the initial phase of the program on discussion
with Business stakeholders , Product Management team , PO , Tech SME to
determine the scope of program , prioritization & aligning on the business
objectives  and tech objectives there was multiple discussion and it was tough
to get the agreement due to multiple people having conflicting agenda and need .
 I received the feedback that there was lot of time being wasted and people are
not aligning on the subject . This led me to reflect back and breakdown the work
and structure of how we were approaching  the topics to be discussed & limiting
to the required audience and building a steering committee that will be a small
set of devision makers representing from business stakeholders , Product
management , Technology team additional I also prepped the teams offline on the
discussion topics and things they need to come prepared so that our meeting
agenda is clear an we can effectively discuss and prioritize on the scope due to
the initial prep work done offline . This helped me in always being open for
feedback and being adaptive to the ongoing situation and doing initial ground
work so that there is clear and effective communication transparency

Anonymous · Answer

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 · Answer

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 · Answer

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?

Practice this question with AI

Go Premium

Community Answers

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Try Free AI Interview

Google

Product Manager

Meta

Product Manager

Meta

Engineering Manager

Amazon

Data Scientist