What is a difficult piece of feedback that you have received? When did you receive it and how did you handle 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.

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

Sure. In a previous project, I received feedback from my manager that while my
code was technically solid, I wasn’t documenting API changes and design
decisions clearly enough for the rest of the team. At first, it was tough to
hear because I was confident in my solutions, but I realized that in a
collaborative environment, clean documentation is just as important as correct
code. I took the feedback seriously—I started documenting endpoints, creating
detailed design notes, and using tools like Swagger for APIs. Over time, not
only did this make it easier for other developers to integrate and maintain
code, but it also improved team efficiency and reduced errors in production. I
now see it as an important part of being a senior developer, not just writing
good code, but making it usable and maintainable for the team.

Anonymous · Answer

S: first job as TPM, coming from dev bkgrnd, managing various projects at the
same time. Falling behind on some tasks. Manager gave feedback that I need to be
more efficient & think of scale

A: I analyzed my approach to PgM & processes:

was hands-on - manually tracking details, collecting status, reporting to exec

not scalable across multiple projects

need to build scalable, repeatable processes to enable scalable program
management

build an accountability mechanism (RACI) -

designating single point of contact for each major area in my team

this made ownership clear and reduced ambiguity

Automate tracking & visibility:

Setup org level Jira dashboards, with area level drilldowns, exec visibility
into R/Y/G

Eliminated manual efforts & became self-serve

Designated reporting mechanism - bi-weekly progress updates on all major
projects

Created a standardized reporting template

Shifted my role from status collector to facilitator of accountability by
enabling self serve updates for teams

weekly syncs w. major stakeholders on all - adv flag issues, blockers

R: I was able to create replicable processes for any program, enabled me to
scale up & manage several programs, freed up 30% of my time to focus on critical
areas- tech strategy & forward planning. Built strong trust with leadership due
to consistent, comprehensive updates.

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

In 2015, during my early days at Teradata, I received feedback from my manager
and colleagues that, while I had strong technical skills, I wasn’t vocal enough
in team discussions. I found this difficult to accept because I believed that my
work should speak for itself.

The goal was to improve my communication skills, particularly in team
discussions and design reviews, so my ideas and opinions would be heard and
valued.

I took the feedback seriously and began preparing thoroughly for design
discussions and technical meetings. I made a conscious effort to speak up,
sharing my opinions on designs, asking clarifying questions, and offering my
technical insights. I also sought feedback from colleagues to understand how I
could communicate more effectively.

As I became more vocal and engaged, my opinions were valued, leading to more
productive discussions. This strengthened my relationships with teammates,
boosted my confidence in sharing ideas, and helped me communicate complex
technical concepts more clearly and effectively.

Anonymous · Answer

After several years at Google Home I decided to move to the Fuchsia Organization
because I wanted to take the opportunity to work in a new operating system.
Fuchsia at that point was working to replace the Linux version used by Google
Home devices with Fuchsia. My onboarding project at Fuchsia was to support the
migration of the smart display applications to Fuchsia which required to work
very closely with the Google Home Team and very little with the Fuchsia Team.
The piece of feedback I received was that the Fuchsia Team saw me as an outsider
because I was working more closely with my previous team rather than with
Fuchsia. When I received the feedback I stopped for a minute to think about the
situation and I could understand why the Fuchsia Team was feeling like that.
I continued working on my onboarding project but I also allocated enough time to
work on Fuchsia specific projects. I also allocated time to socialize more with
my new team joining them for offsite activities and grabbing lunch. Even though
it took some time I was able to get considered as a core member of the Fuchsia
Team.

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

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

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 in the system. 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

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 in the system. 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

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
we should be targeting 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, I first
gathered all the data points which was present in the system. 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. 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

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
we should be targeting 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, I first
gathered all the data points which was present in the system. 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. 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

This happened while I was a bit green and working with a new UX researcher on
our team. I was given feedback of "overstepping boundaries". The researcher
explained that they had felt I was doing their job for them and asked me to let
them do their job. This was difficult for me because I had not received such
feedback before and was taken aback at first. The first thing I like to do is
reflect and understand it from my perspective. Then it's always good to get an
honest conversation going. The one on one was productive, I was able to give my
perspective of what happened and the UX researcher also clarified points they
had made. We were both able to come to a conclusion that there was some
miscommunication on when artifacts such as user interview scripts or testing
scenarios were going to be completed and I had overstepped by not asking when it
would get done and just creating a initial draft. By doing so I had made the
researcher feel almost left out without any communication.

Anonymous · Answer

While working as a software engineer at Cognizant for a UK-based energy client,
a high-priority business customer faced an issue with the energy quote
generation process. They were unable to generate a quote for their business
energy plan, and any delay risked incurring extra costs for the customer and
losing them as a client, which would have been a significant financial loss for
us. Later we found out that it was due to the usage of a in-built method which
was not supported in the version of the browser the user was using. which was an
old version.
Feedback: My team lead was disappointed and gave a tough feedback for not
testing it properly and catching it beforehand.
Task: My task was to make sure all the functions are working across different
version of browser and different and different browser and refer MDN
documentation and their supported browsers and version before using a inbuild js
function.
Action:
I acknowledged the feedback by setting a standard in the team of referring to
the documentation before using any latest js in build functions and testing it
across different browser version and browser using tools like browser stack
before moving to the QA team to make sure it's double checked.
Result:
As a result it reduced the service tickets raised by customer by 90% and
internally this approach was recognized by stakeholders, and we implemented a
new practice of consulting MDN documentation before using JavaScript features to
avoid similar issues in the future.

Anonymous · Answer

At CaptialOne, when I was Sr. Dev I started setting up lot of meetings to make
decisions. Hindsight this was a waste of time and Product Managers were not
happy about the meetings, that's when my Manager pulled me and said "Treat
Meetings as Bugs not a feature" - I realized the mistake and pivoted using
shared documents such as onenote and email - as means to get clarifications and
only use meetings when we need to make important decisions.

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

While working as a software engineer at Cognizant for a UK-based energy client,
a high-priority business customer faced an issue with the energy quote
generation process. They were unable to generate a quote for their business
energy plan, and any delay risked incurring extra costs for the customer and
losing them as a client, which would have been a significant financial loss for
us. By reviewing the analytics data got from the analytics team and tried to
recreate the bug using the same version of browser the user used and I found out
that it was due to the usage of a in-built method which was not supported in the
version of the browser the user was using. which was an old version.
Feedback: My team lead was disappointed and gave a tough feedback for not
testing it properly and catching it beforehand.
Task: My task was to make sure all the functions are working across different
version of browser and different and different browser and refer MDN
documentation and their supported browsers and version before using a inbuild js
function.
Action:
I acknowledged the feedback by setting a standard in the team of referring to
the documentation before using any latest js in build functions and testing it
across different browser version and browser using tools like browser stack
before moving to the QA team to make sure it's double checked.
Result:
As a result it reduced the service tickets raised by customer by 90% and
internally this approach was recognized by stakeholders, and we implemented a
new practice of consulting MDN documentation before using JavaScript features to
avoid similar issues in the future.

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

S: during previous job while I was ramping toward sr level, I informed manager
of planning process improvements in team, he advised me to think big and
simplify planning for entire org

A: I understood the importance of proactively improving processes at org level,
as their impact is more

I partnered with other teams in org on understanding their pain points

req input & prioritization was not streamlined

no common release schedule

Streamlined process for entire org

all teams on common sprint cadence- easy to coordinate requests

common req gathering form for customer teams

shared dashboard showing sprints for all teams

R: resulted in improved cust satisfaction, reduced time spent on planning

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

First, I will say thank you to that person for their feedback.
For example, they provided feedback about the information sharing in the meeting
is insufficient.
Then, I will review it whether it is insufficient and if so, I will carefully
prepare information in next meeting by trying to think in different dimensions
what else of information is needed to have the meeting run smoothly.
Anyway, I will also expand this feedback/ lesson learnt to other activities for
example, when sending email to other people, I have to review if the information
is really sufficient to have it clearly communicated at one time, no rework or
double job is needed.

Anonymous · Answer

At CaptialOne, while I was a Sr. Dev - I started setting up lot of meetings with
PM to get clarifications. This was not a best use of time, but at the time - it
allowed me to get a clarify things. My manager, gave me the feedback that I was
setting up too many meetings impactinging PMs productivity. He advised me to
treat meetings a bug not a feature, I pivoted to other forms of communication
such as Email and google docs etc. this increased both my productivity and my
PMs productivity. Lesson I learnt was Meetings are needed only when we need a
quorum to make a decision.

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.

What is a difficult piece of feedback that you have received? When did you receive it and how did you handle it?

Practice this question with AI

Go Premium

Practice More Questions

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

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

Master Data Science Interviews