Tell me about a time when you made an unpopular decision

Question

Anonymous · Accepted Answer

My team was preparing for a critical release of a new feature in our SDK, 
which was crucial for upcoming business use cases involving personally
identifiable information (PII). 
Shortly before the release, a partner team reported a high-priority production
incident: their application instance was crashing due to high memory usage,
which they attributed to our SDK.

Despite our investigation revealing no inherent issues with our SDK, 
the VPs and other senior leaders were concerned about the stability of our
software. 
My manager decided to delay the planned release due to the recent incident, a
decision supported by most of the team who were wary of further issues.

I reviewed the incident details and suggested that restarting the partner team's
application instance might alleviate the problem. 
This recommendation was implemented during the incident call, and it resolved
the issue, 
indicating that the problem was not with our SDK but potentially with the
partner’s application.

Understanding the urgency of the release, I presented a case to the VPs
highlighting that the release was fully developed, tested, and ready. 
I emphasized its importance for business use cases and the fact that customer
expectations were high.
 I proposed a controlled rollout approach to mitigate any risk, where we would
monitor the release closely 
 and be prepared to address any unforeseen issues promptly.

Despite initial resistance, my recommendation to proceed with the release was
accepted. 
The deployment went smoothly, and the new feature was well-received by
customers, significantly advancing our business objectives related to PII. 
The decision to proceed, even amidst the recent concerns, demonstrated our
commitment to delivering value while managing risk effectively. 
It also reinforced the team’s confidence in balancing operational stability with
strategic priorities.

Anonymous · Answer

At Acutance, when I joined the team, I noticed that our legacy code was lacking
unit tests, which was a significant gap in our development process. Recognizing
the importance of maintaining high-quality code, I decided to set a goal for our
team to incorporate unit tests into all our microservice projects.
This decision was initially met with resistance, particularly from long-standing
team members who were accustomed to the existing workflow and didn't see the
value in implementing unit tests. Despite this pushback, I was convinced that
introducing unit tests was essential for improving our code quality and reducing
future maintenance issues.
To address the resistance, I took a strategic approach. I identified the newer
developers on the team, who were more open to adopting new practices. I tasked
them with implementing unit tests as part of their development work. Over the
course of one to two sprints, we gathered empirical data showing the benefits of
this approach, including increased code reliability and easier debugging
processes.
The turning point came when the results became evident to the entire team. The
initial skeptics saw firsthand how unit tests helped catch errors early and made
the codebase more robust. This empirical evidence convinced even the most
resistant team members to embrace the new approach.
The lesson I learned from this experience is that sometimes, leading by example
and demonstrating tangible benefits can be more effective than theoretical
arguments. Showing concrete results helped build consensus and drive the team
toward a higher standard of code quality.

Anonymous · Answer

In a previous project, our team was working on a data pipeline that was
consistently failing near peak hours. After analyzing the issue, I realized that
the fastest solution would be to temporarily reduce the frequency of some
non-critical reports to stabilize the system.

I knew this decision wouldn’t be popular because some stakeholders relied on
these reports daily. I communicated clearly why this step was necessary, shared
the data supporting the decision, and explained that it was temporary while we
implemented a more permanent fix.

Initially, there was pushback, but after monitoring system performance and
showing that the critical reports were running reliably, the stakeholders
understood and supported the approach.

The experience taught me that difficult decisions are easier to implement when
you explain the rationale transparently, back it with data, and show that you’re
considering both short-term impact and long-term benefits.

Anonymous · Answer

Was working as a Product Manager at Uber. We were working on the driver app and
trying to make it easy to see total payouts post-Uber's commission. We had
received bad coverage in the news recently, regarding our cut and it was urgent
to roll out transparency as quickly as possible. Last-minute, we realized that
our changes, while delivered the intended impact, also violated several SLAs in
terms of app loading time when someone visited this section. This was so bad
that for 0.5% of all drivers, it could also crash the app. It was also a risky
call since any fix would require users to update their app, something we can't
really guarantee. So some users might stay exposed to bad app performance even
beyond our usual 2 week rollout period.
I made the decision to go ahead with the rollout knowingly, inspite of being
aware of the loading issue. The engineers and EM in my team were quite unhappy
with my call since they disagreed with the compromise and also felt it would
reflect poorly in their craft assessments. My decision was driven by the urgency
of resolving our burgeoning PR issues though. So while I pushed through my POV,
I also understood where the engineers were coming from.
I also tried to mitigate the negative effects of my decision, both by trying to
provide them shielding and accepting ownership of the decision and its
consequences. I also went out of my way to ensure senior stakeholders were aware
of the consequences and had a chance to "veto" my decision before we went ahead.

Anonymous · Answer

"One time, I had to make an unpopular decision during a major project when I was
leading a development team. We were working on a new feature with a tight
deadline, and the team had proposed several enhancements that they felt would
greatly improve the user experience. However, after a thorough analysis, I
realized that these enhancements would significantly delay the project and could
compromise our ability to meet the deadline.
Despite the team's enthusiasm, I decided to prioritize the core functionality
and set aside the additional enhancements for a future release. I knew this
decision would be disappointing, as the team had put a lot of effort into the
proposed features and believed they were crucial for the project’s success.
To address the situation, I organized a meeting with the team to explain my
decision. I detailed the reasons behind it, emphasizing that meeting the
deadline was critical for the project's overall success and that delivering a
stable and functional product on time was our primary goal. I acknowledged their
hard work and assured them that their proposed features were valuable and would
be considered for the next iteration.
I also worked closely with the team to reassess and streamline our current tasks
to ensure we could meet the new timeline without sacrificing quality. Throughout
the process, I made sure to maintain open communication and provide support to
address any concerns or frustrations.
In the end, the project was completed on time and received positive feedback
from users. The decision, though initially unpopular, proved to be the right one
for the project's success. By handling the situation transparently and
empathetically, I was able to maintain team morale and ensure that everyone
understood the rationale behind the decision. The team also appreciated the
opportunity to revisit and implement their enhancements in subsequent releases."

Anonymous · Answer

I once made an unpopular decision to remove a new feature from a release after
testing showed serious stability issues. The team had invested a lot of effort
and was disappointed, but I explained the risks clearly and assured them we’d
revisit it with proper time. The release went smoothly, and we later launched
the feature successfully. It taught me that unpopular decisions are sometimes
necessary to protect quality and long-term outcomes.

Anonymous · Answer

My team was preparing for a critical release of a new feature in our SDK, which
was crucial for upcoming business use cases involving personally identifiable
information (PII). Shortly before the release, a partner team reported a
high-priority production incident: their application instance was crashing due
to high memory usage, which they attributed to our SDK.

Despite our investigation revealing no inherent issues with our SDK, the VPs and
other senior leaders were concerned about the stability of our software. My
manager decided to delay the planned release due to the recent incident, a
decision supported by most of the team who were wary of further issues.

I reviewed the incident details and suggested that restarting the partner team's
application instance might alleviate the problem. This recommendation was
implemented during the incident call, and it resolved the issue, indicating that
the problem was not with our SDK but potentially with the partner’s environment.

Understanding the urgency of the release, I presented a case to the VPs
highlighting that the release was fully developed, tested, and ready. I
emphasized its importance for business use cases and the fact that customer
expectations were high. I proposed a controlled rollout approach to mitigate any
risk, where we would monitor the release closely and be prepared to address any
unforeseen issues promptly.

Despite initial resistance, my recommendation to proceed with the release was
accepted. The deployment went smoothly, and the new feature was well-received by
customers, significantly advancing our business objectives related to PII. The
decision to proceed, even amidst the recent concerns, demonstrated our
commitment to delivering value while managing risk effectively. It also
reinforced the team’s confidence in balancing operational stability with
strategic priorities.

Anonymous · Answer

Was working as a Product Manager at Uber. We were working on the driver app and
trying to make it easy to see total payouts post-Uber's commission. We had
received bad coverage in the news recently, regarding our cut and it was urgent
to roll out transparency as quickly as possible. Last-minute, we realized that
our changes, while delivered the intended impact, also violated several SLAs in
terms of app loading time when someone visited this section. This was so bad
that for 0.5% of all drivers, it could also crash the app. It was also a risky
call since any fix would require users to update their app, something we can't
really guarantee. So some users might stay exposed to bad app performance even
beyond our usual 2 week rollout period.

I made the decision to go ahead with the rollout knowingly, inspite of being
aware of the loading issue. The engineers and EM in my team were quite unhappy
with my call since they disagreed with the compromise and also felt it would
reflect poorly in their craft assessments. My decision was driven by the urgency
of resolving our burgeoning PR issues though. So while I pushed through my POV,
I also understood where the engineers were coming from.

I also tried to mitigate the negative effects of my decision, both by trying to
provide them shielding and accepting ownership of the decision and its
consequences. I also went out of my way to ensure senior stakeholders were aware
of the consequences and had a chance to "veto" my decision before we went ahead.

Anonymous · Answer

In 6 months cycle we had received 14-15 product feature requirements from across
the teams, which were a mix of big and small tasks.
We had 3 months left for the cycle and I decided to conduct a meeting with the
engineering head and the leadership to discuss on which tasks could be picked up
next.
I realised that the team was focusing on picking up feature enhancements rather
than product development and the impact was not as high leading to delays in
delivering higher impact tasks.
I made the difficult decision to temporarily halt additional feature requests
and focus solely on delivering the core functionalities that had been promised
to our stakeholders.
This decision was initially unpopular among some team members and stakeholders
who felt that the additional features were critical for user engagement. To
address this, I organized a meeting to explain the rationale behind my decision,
backed by data on how the delays were affecting overall project success and
client satisfaction. I emphasized our commitment to delivering a high-quality
product on time and outlined a plan to revisit the additional features in a
future phase after we had successfully launched the initial version.
In the end, the team aligned behind the decision, and we managed to deliver the
project on time. Post-launch, we received positive feedback from users, and our
ability to focus on quality over quantity strengthened our relationship with
stakeholders. This experience taught me the importance of making tough calls for
the greater good and communicating effectively to ensure buy-in from the team.

Anonymous · Answer

Situation: At Zendesk, shortly after we formed a new team focused on user,
organization, and group services, I identified a significant gap in our legacy
code. Specifically, I noticed that many key features lacked adequate unit and
integration tests, which posed a risk to the quality and reliability of our
development process.

Task: Understanding the critical need for high-quality code, I felt it was
essential to address this issue. I decided to set a goal for our team to
incorporate unit tests in all areas where they were missing. I anticipated some
resistance, as many team members were eager to focus on feature development
rather than refactoring and writing tests for existing code. However, I made a
case for the importance of quality assurance and how it would ultimately lead to
fewer bugs and a more stable product.

Action: To address the resistance, I took a strategic approach. I identified the
newer developers on the team, who were more open to adopting new practices. I
tasked them with implementing unit tests as part of their development work. Over
the course of one to two sprints, we gathered empirical data showing the
benefits of this approach, including increased code reliability and easier
debugging processes.

Result: While the decision was initially met with some skepticism, the team
gradually recognized the value of implementing comprehensive testing. Over time,
we successfully integrated unit tests into the codebase, leading to improved
code quality and fewer regressions in future releases. This effort not only
bolstered the reliability of our services but also fostered a culture of quality
within the team. In retrospect, I’m proud of making that unpopular decision, as
it laid a strong foundation for our development process moving forward.

Anonymous · Answer

Whilst conducting an operation on drug trafficking there was a possibility that
a team would need to be deployed outside of sociable hours. This wasn't an
unpopular decision with some team members due to various reasons such as having
young children.

To overcome the issues, I explained the reasoning behind why this was required,
where the main suspects were moving large amounts of contraband from London to
the north of England.

To ensure that  team were not recalled for a false alert, I made representations
to have a tracker placed on the car and should it pass a certain point on the
outskirts of north London we can assume a trip is being made triggering a call
in to follow
Additionally, all team members with childcare issues were exempt from the call
up. This was to ensure no additional burden was placed in staff with children.

The actions taken came to fruition, where as expected the suspect travelled up
north and the precautions taken ensured that only available staff were deployed
and able to evidence the movement of contraband, which was eventually able to be
used in the conviction of the suspect.

Anonymous · Answer

One such instance occurred during a navigation redesign where there was a strong
divergence of opinions regarding the design direction for the browse navigation
item.
Despite differing decisions, I ultimately made the decision to prioritize
simplicity and user needs over the opinion of a stakeholder, backed by user
research and usability testing. I presented compelling evidence as to why I was
making this decision, and I was open and honest about the user feedback we had
received. I helped stakeholders understand the rationale behind my decision and
the impact it had on users. After implementing the decision, I monitored the
user feedback to keep an open mind towards iterating our solution and made sure
users were satisfied with the experience.

Anonymous · Answer

I had to redesign a table where the marketing managers would lose access to all
their performance metrics at a deeper grain. However, it was the right choice to
make given that the data at deeper grains was incomplete. For this, I convinced
the marketing managers by creating a slide deck with many examples pointing out
the days of outages and how that impacted their ability to optimize campaigns
and perform WBRs. Eventually they agreed

Anonymous · Answer

At Acutance, when I came into the team - I saw that legacy code was lacking any
unit tests. I wanted to raise the standard for my team and set up a goal of
adding unit test to all microservice projects. I had a initial push back from
folks where old timers. they did not see any value of Unit Tests. I knew I had
to convince them that Unit tests were a good idea, In order to do that - I
identified new devs on the team and asked them to implment tasks with Unit
tests, after 1-2 sprints  folks who opposed saw the emperical data and adopted
to this new approach.
Lesson I learnt is sometimes showing an example goes a long way to convince that
we are on the right path.

Anonymous · Answer

WHILE REVIEWING ONE OF THE OLDER PROJECTS THAT WAS CURRENTLY IMPLEMENTED IN THE
COMPANY I NOTICED THAT THERE WAS NO ALERTING IN PLACE IF THE DATA PIPELINE
BREAKS, THE DATA PIPELINE HAS NEVER BEEN BROKEN AND IT NEVER FAILED FOR THE LAST
2 YEARS. IT WAS A PIPELINE WHERE THE DATA WOULD BE DROPPED INTO AN SFTP BUCKET
BY THE CUSTOMER EVERY HOUR AND THEN IT WAS MOVED TO AN S3 BUCKET WHERE S3
TRIGGERS WERE IMPLEMENTED TO MOVED THE DATA IN TO QUEUE. SO IN CASE THERE IS AN
ISSUE WITH THE DATA NOT BEING PROCESSED WE WOULD ONLY KNOW WHEN THE WE SEE A
DROP IN VOLUME. I IDENTIFIED IT AS A POTENTIAL ISSUE WITH THE SYSTEM AND WORKED
ON A PROPOSAL TO HAVE MONITORING IN PLACE SO WE ARE NOTIFIED WHEN THERE IS AN
ERROR. I WORKED WITH THE PROGRAM MANAGER AND DEVISED A PLAN ON HOW TO IMPLEMENT
THE ALERTING AND THE TIME LINES AS WELL AS THE EFFORT THAT WILL BE NEEDED TO
IMPLEMENT IT. I MAPPED THE IMPACT OF NOT HAVING IT TO THE CURRENT GOALS OF THE
COMPANY AND THEN PUT FORWARD A PROPOSAL OF IMPLEMENTING THE ALERTS TO THE
BUSINESS AND TOOK THEIR BUYINS. AFTER GETTING THE BUYINS I PROPOSED THE TASK TO
MY TEAM AND SOME OF THE SR DEVLOPERS WERE NOT TOO KEEN ON IMPLENTING THE ALERTS,
I GAVE THE TASK TO SOME OF THE JR DEVLOPERS AND THE ALERTS WERE IMPLEMENTED.
AFTER THE IMPLEMENTATION WE DISCOVERED THAT FOR SOME HRS IN A DAY WE WERENT
GETTING ANY FILES SO INSTEAD OF GETTING 24 FILES IN A DAY WE WERE GETTING 20
FILES A DAY IN AN AVERAGE. THIS WAS RECTIFIED BY TALKING TO THE CUSTOMER AND THE
MISSING DATA WAS SOLVED. BUT THIS MADE THE WHOLE TEAM REALIZE THE IMPORTANCE OF
MONITORING AND ALERTING. IT ALSO BOSTED THE MORAL OF THE JR DEVELOPERS SEEING
THE DIRECT IMPACT THEY MADE TO THE BUSINESS GOALS

Anonymous · Answer

As a program manager, I faced a divisive choice between prioritizing new
features or fixing existing bugs. Despite resistance, I prioritized bug fixes
after thorough data analysis and risk assessment. Transparent communication with
the team emphasized the long-term benefits of improving product stability and
customer satisfaction. Monitoring metrics validated the decision's positive
impact over time. Ultimately, the unpopular decision strengthened our product's
foundation and enhanced user trust.

Tell me about a time when you made an unpopular decision

Practice this question with AI

Go Premium

Practice More Questions

Community Answers

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Unlock Full Access

Everything You Need to Ace DS Interviews