Can you describe a time when you had to make a decision that was unpopular with your boss or supervisor, and how you navigated that situation?

Question

Anonymous · Accepted Answer

Once while running shift, I was given a challenge on cutting down on hours to
cut cost. So therefore I was voluntarily cutting associates down. After doing so
I had my manager scrutinize my decision to let go of people early and was told
that I had made a bad decision.

Anonymous · Answer

In my previous role as a project manager, I once decided to delay a product
launch by a month. The development team encountered unforeseen technical issues,
and despite the pressure from stakeholders to meet the original deadline, I
chose to prioritize the quality and stability of the product. This decision was
unpopular among the sales and marketing teams who had campaigns aligned with the
initial launch date. However, the extra time allowed the team to resolve
critical bugs and improve overall performance, leading to a successful launch
and positive customer feedback, ultimately validating the decision.

Anonymous · Answer

n one project, we were under pressure to release a feature quickly, and most of
the team wanted to skip certain performance optimizations to meet the deadline.
I made the decision to delay the release slightly to refactor critical parts of
the Java backend and implement proper caching and database indexing. Initially,
it was unpopular because it felt like slowing down progress, but I explained the
potential long-term impact of ignoring performance issues. After implementing
the changes, the system handled 3x the load without issues, and we avoided
costly production incidents. This experience reinforced that as a senior
developer, sometimes the right decision isn’t the easiest or most popular, but
it’s about ensuring reliability and scalability for the product.

Anonymous · Answer

In my engineering design course, I led a group project where we had to develop a
prototype. Early on, the team disagreed about how much time we should spend
refining the design versus testing quickly. Most wanted to keep adding features,
but our deadline was tight, and our grade depended heavily on functionality.

As the team lead, I had to make the call on how to move forward, even though I
knew it wouldn’t be popular with some teammates.

I decided we would pause new feature ideas and focus on simplifying the design
so we could test earlier. I communicated this clearly to the group, explaining
that while it might feel like we were cutting corners, it was the best way to
meet the deadline and improve our grade. I also made sure to involve those who
disagreed by giving them ownership over specific testing tasks so they still
felt engaged.

At first, there was some frustration, but as testing revealed issues we hadn’t
anticipated, the team realized the decision paid off. We had time to fix
problems, and ultimately our grade improved from where it was trending—a strong
result that everyone was proud of. The experience taught me how to make tough
calls, explain the reasoning behind them, and bring people along even when they
initially disagree.

Anonymous · Answer

“One night flying into Newark, we were on final approach after a long day with
gusty winds, turbulence, and low visibility. The captain was flying, and I was
pilot monitoring, keeping an eye on airspeed, alignment, and anything that might
require a callout. Everyone was ready to be on the ground — the passengers, the
crew — it had been a long day, and the momentum was to just get the airplane
landed.

As we crossed the runway threshold, the airplane hit a strong burst of
turbulence and refused to settle. In that split second, I knew what had to be
done, but I also knew it wouldn’t be the popular choice. A go-around meant a
delay, frustrated passengers, and possibly second-guessing from the crew. But
safety has to come first, so I immediately called ‘Go-around.’ The captain
executed it smoothly, and we climbed away, briefed again, and landed safely on
the second attempt.

Afterward, the captain thanked me for speaking up and said he completely agreed
with the decision. It reinforced for me that as pilots, we can’t let convenience
or the desire to finish cloud our judgment. Sometimes the right call isn’t the
popular one, but it’s always the right call when it keeps everyone safe.”

Anonymous · Answer

In my previous role as a project manager, I once decided to delay a product
launch by a month. The development team encountered unforeseen technical issues,
and despite the pressure from stakeholders to meet the original deadline, I
chose to prioritize the quality and stability of the product. This decision was
unpopular among the sales and marketing teams who had campaigns aligned with the
initial launch date. However, the extra time allowed the team to resolve
critical bugs and improve overall performance, leading to a successful launch
and positive customer feedback, ultimately validating the decision.

Anonymous · Answer

While I was working at the insurance company, I was implementing an application
that would let users submit an application to the underwriters for receiving
quotes.This was mainly for users that not approved in the first round of
application but were referred for underwriter referrals.This application would
receive sensitive data from the users to determine their eligibility. During the
implementation of this  new software application, we encountered a critical
security vulnerability related to authentication and session management. Our
team had initially planned for a smooth rollout, but this issue disrupted our
timeline.
Action:
 * Discovery: While conducting thorough testing, our QA team identified the
   vulnerability. Essentially, the application was not properly invalidating
   user sessions after logout, leaving the door open for session hijacking.
 * Impact Assessment: We quickly assessed the potential impact. If exploited,
   this vulnerability could allow unauthorized access to sensitive user data or
   even compromise the entire system.
 * Revised Priorities: Recognizing the severity, I immediately shifted our
   priorities. Instead of proceeding with feature enhancements, we focused
   solely on fixing the authentication flow.
 * Collaboration: I worked closely with developers, security experts, and
   stakeholders. We implemented proper session management, including secure
   session tokens, session timeouts, and robust logout mechanisms.
 * Communication: I kept all stakeholders informed about the situation. We had
   to adjust the project timeline, which meant communicating the delay to upper
   management and end-users.
 * Risk Mitigation: Beyond the immediate fix, we also reviewed other parts of
   the application for similar vulnerabilities. This proactive approach helped
   prevent future issues.

Result:
 * Successful Mitigation: By addressing the vulnerability promptly, we ensured
   that user sessions were secure. The revised authentication process was
   thoroughly tested and validated.
 * Project Impact: Although the change disrupted our original timeline,
   stakeholders appreciated our commitment to security. Their trust in our team
   remained intact.
 * Process Improvement: We incorporated stricter security checks into our
   development workflow, ensuring that such issues would be caught earlier in
   future projects.

Anonymous · Answer

When I was working on a project to conversational decision trees, our team was
following a feature branch based development. We had multiple pods working on
different feature delivery for our monthly release. We were frequently facing
merge conflicts when we were trying to merge the feature branch to master. I
strongly felt that this was a lot of effort spent due to the way were handling
our dev process + bugs introduced when resolving conflicts. I did some research
on my end. There were two approaches that came to my eye. One using to branch
develop + master to handle both the dev and release process and the other was to
use one main trunk and use tags for releases. I had proposed the trunk based dev
approach with all prs getting merged into the main trunk, as this avoided the
overhead of maintaining two branches. This would help us dealing the addressing
merge conflicts as we handle smaller sized merges but the team was initially
resistant to move to the new approach. On trying to understand their concern, it
was to make sure only the right features make it to prod. We together came up
with using feature flags for addressing this. This was a change that was well
appreciated later on for its ease of adoption.

Anonymous · Answer

When I was working as a business assciate at a financial services firm, I saw
that >50% of our customers were not submitting their due diligence requirements.
To resolve this concern, the existing process set in place was to send these
customers 3 reminders and then if they do not respond then leave it as is.

I had an idea that I proposed which was considered unpopular. I proposed to
charge them $100 fee after 3 reminders are set and they did not submit the
requirements. This received a lot of negative feedback from leadership but I
pulled data of the revenue of our customer base and presented that all our
customers are banks, trusts and brokerage firms who make well over >$10M in
revenue per year and $100 is <1% of their revenue. They approved a test trial of
4 months to see where this goes and we saw a >80% improvement in compliance
reporting within the 2nd reminder.

Anonymous · Answer

At my previous job in an accounting office, my role involved gathering and
verifying documents from around 500 customers. This required constant
communication with insurance companies, banks, and customers to track missing
paperwork. Our team of five—including the accountant, the account manager, a
secretary, another worker, and me—had to stay updated on each case. However, we
relied on WhatsApp for communication, which was inefficient because updates were
scattered, and no one had access to each other’s work unless shared manually
through messages. I needed to find a way to improve collaboration and document
tracking so that we could work more efficiently without constant back-and-forth
messaging. I introduced an app with software that centralized all our
work—allowing us to access shared notes, documents, emails, and even communicate
through a built-in chat. Initially, my team was hesitant, fearing it would
create confusion since anyone could edit each other’s notes. To address their
concerns, I set up guidelines for how we would use the tool, provided a short
training session, and demonstrated how it could actually make our work more
organized. Although my colleagues were skeptical at first, within a few weeks,
we noticed a significant improvement. We spent less time updating each other
manually, our response times to customers became faster, and overall efficiency
increased. Eventually, even those who resisted at the beginning admitted that
the new system helped us work more smoothly.

Anonymous · Answer

I once had to prevent the launch of a feature that took 6 months of deliberation
and 4 months of building. It was an entity extraction feature that had to work
realtime, and use the latest NLP models. We had extensive discussions, lots of
use cases, and design sessions. It required coordination across multiple
functions to build. Finally, when it released, we started testing it. My QA and
I discovered several ways in which the feature was just not delivering the value
we had envisioned it would. Accuracy was down, and the user experience at design
time was in fact worse than before. I had to convince senior leadership that
releasing this feature would cause further pain to our users (it was an
enterprise product and the users were the solutions team). There was resistance
because lots of development work had gone into it, and especially by a team that
I did not even have hold over. Finally, we did not release the feature to actual
customer deployments.

Anonymous · Answer

When I was working on a project to conversational decision trees, our team was
following a feature branch based development. We had multiple pods working on
different feature delivery for our monthly release. We were frequently facing
merge conflicts when we were trying to merge the feature branch to master. I
strongly felt that this was a lot of effort spent due to the way were handling
our dev process + bugs introduced when resolving conflicts. I did some research
on my end and proposed a trunk based dev approach with all prs getting merged
into the main trunk. This would help us dealing the addressing merge conflicts
as we handle smaller sized merges but the team was intially resistant to move to
the new approach. On trying to understand their concern, it was to make sure
only the right features make it to prod. We together came up with using feature
flags for addressing this. This was a change that was well appreciated later on
for its ease of adoption.

Anonymous · Answer

When working at Flutter different teams were using different continuous
integration systems. This was a consequence of not having a centralized
Engineering Productivity team however when the Engineering Productivity team was
created having to support multiple CI systems was splitting resources that could
be used to solve scalability or reliability problems.
I proposed consolidating all the Flutter Teams development workflows to use a
single continuous integration. The proposed system was highly scalable and
reliable but it was slightly more difficult to use. Even though the benefits
were many, some teams opposed the change and I had to offer concessions to
unblock the program. I had to negotiate and offered a transitional change
keeping the two different infrastructures running at the same time with an
eventual deprecation on one of them. This increased the maintenance burden in
the short term but allowed me to continue the standardization process with an
eventual convergence to single infrastructure.

Anonymous · Answer

For several reasons (unlisted here for brevity) I needed a team to participate
in the operational up-keep and on-call rotation for a old large stateful backend
service. This was initially unpopular with the team because it was a departure
from what they expected: which was that they'd go on-call only for the new
backend that they'd built if and when it is productionalized.
I spoke to the team individually to ensure I learnt all the reasons for their
lack of support and addressed each of them over a period of 3 months. 
Other actions taken:
1. Explain benefits of learning how to operate large services
2. Spell out the opportunity to study the code of a $1B data service.
3. Show them why it's beneficial to work with in-house experts (Senior, Staff
engineers on the team whom they'd previously not had exposure to).
4. Promise to make on-call better. And stick to it. Quantify the betterment. We
reduced operational load from 60+/week to <7 when they went on-call
independently.
5. Provide training deliberately.
6. Promise to be open to changes and genuinely listen and incorporate feedback.
Result:
The two sites where brought together under the wider organization. Tenured folks
in BarLand were able to share their operational expertise and 15+ years of
lessons gathered about customer usecases with the FooLand team. FooLand brought
in fresh perspective to the old backend and learnt valuable lessons on why it
had evolved the way it had. They also got a better understanding of ways to
conduct at-scale tests and learnt more about their own system while teaching
their colleagues.

Anonymous · Answer

For several reasons (unlisted here for brevity) I needed a team to participate
in the operational up-keep and on-call rotation for a decade-old large stateful
backend service. This was initially unpopular with the team because it was a
departure from what they expected: which was that they'd go on-call only for the
new backend that they'd built if and when it is productionalized.

I spoke to the team individually to ensure I learnt all the reasons for their
lack of support and addressed each of them over a period of 3 months (individual
actions omitted for brevity).

Result: 
The two sites where brought together under the wider Backend Organization.
Tenured Kinesis folks in Seattle were able to share their operational expertise
and 10+ years of lessons gathered about streaming usecases with the Vancouver
team. Vancouver brought in fresh perspective to the old backend and learnt
valuable lessons on why it had evolved the way it had. They also got a better
understanding of ways to conduct at-scale tests and learnt more about their own
system while teaching their colleagues.

Context:

When I joined the BE team as the Engineering Manager, I had only one direct
report and 7 open reqs. My goal was to hire folks for the BE and ensure it was
brought back to operational stability. I studied the situation and worked with
the PE that was also brought in to this project alongside me to identify the
best path forward. After doing my due-diligence to identify what the causes were
for getting into this unhealthy state, I presented a Get-Well-Plan to
leadership. The main points were: 
1. Seattle BE cannot be responsible only for the old backend that was on a
deprecation path. 
2. The Vancouver team building out the new backend cannot successfully do so
without gaining invaluable hands-on experience in operating a large scale
distributed system.

Actions Taken:

1. Explain benefits of learning how to operate large services 
2. Spell out the opportunity to study the code of a $1B foundational data
service. 
3. Show them why it's beneficial to work with in-house experts (sr enggs, PEs on
the Kinesis team whom they'd previously not had exposure to). 
4. Promise to make on-call better. And stick to it. Quantify the betterment. We
reduced sev2s from 60+/week to <15 when folks started reverse shadowing and <7
when they went on-call independently. 
5. Provide training deliberately. 
6. Promise to be open to changes and genuinely listen and incorporate feedback.

Anonymous · Answer

When I need to make a unpopular decision - I try to anticipate the pushback I
can get and see how I can mitigate that.. At Auctane, I noticed that there was
no unit tests on the legacy code, I knew I had to improve on the engineering
standards. When we had a plan to migrate to monlotith  - I proposed we add unit
tests in our sprint cycle, I got a push back from the established team members
as they did not want to change thier approach to development. So I apporached
new devs on the team, they were onboard with this idea, after 2 sprints the team
saw the code with unit tests were less buggy and more modular. This encouraged
others to adopt units test while development phase well. In the end our team
achived at least 75% code coverage.

Anonymous · Answer

·         During my PTY, my project was majorly PCR based and I took lead on the
PCR lab. There was a contamination issue with bacteria being brought into the
space, as well as clutter with reagents being left out and machines on.

·         As the unofficial lead of the PCR lab I realised that other users
needed reminding and clarify how to use the reagents and space efficiently.

·         I had a meeting with everyone who uses the space to discuss the issue.
And emphasis it is a clean working space.

·         I suggested re-training  where I held one on one sessions with
everyone who uses the space.

Although it was unpopular to start, within a couple of weeks we had no more
contamination, the lab space was cleaner with everything properly stored after
use and no need to repeat experiments.

Anonymous · Answer

I once had to prevent the launch of a feature that took 6 months of deliberation
and 4 months of building. This was because my QA and I discovered several ways
in which the feature was just not delivering the value we had envisioned it
would. I had to convince senior leadership that releasing this feature would
cause further pain to our users (it was an enterprise product and the users were
the solutions team).

Anonymous · Answer

Critical project that was delayed. Product was unhappy with the delay. I
explained the reason for delay was cleaning up a tech debt that would help in
expanding to new sites. Additionally, promised the team to provide a weekly
email updates showing the progress made. As a result we were able to complete
the tech debt and the original project improving our architecture and developer
pain and enabling us for expansion.

Anonymous · Answer

Once I decided to delay software enhancements my end-users were expecting
because the system wasn't 100% ready. I could've launched and let IT flush out
the bugs over the next two weeks. But we would've risked immediate invoice
adjustments. I explained the delay to the users and let them know when I could
deliver the enhancements.

Anonymous · Answer

At Motorola, we were building IoT devices and the V1 version we sent to our
clients and the update process for the IoT device fumbled. This meant that some
of our clients had no way to recover the IoT device and function normally. This
had a huge customer impact and I realized this and I took ownership of that and
we went back to the drawing board, reworked the way we would update our IoT
device. Reworked the way we updated our IoT device and we had to ship a new set
of boxes for the customers to install. This led to some downtime for the
customers in the short run, but it was also the right thing to do so that we can
achieve the long-term stability of the devices.

Anonymous · Answer

החלטה לא פופולרית שעשיתי במהלך העבודה שלי בבנק הייתה לפטר מנהל מוצר שעבד תחתיי
למרות שהיה אדם ממש נעים, חברותי ואנשים אהבו לעבוד איתו. למרות שההחלטה הייתה מאד
לא קלה, היא הייתה מאד נכונה. אותו מנהל מוצר לא היה מתעמק במוצרים שלו ובדרישות
שכתב, הוא לא היה מבין את הדברים לעומק והיה נשאר בלבל מאד שטחי. על כן, המוצר שלו
לא התקדם בהתאם ליעדים שהוגדרו לו וזה גרם למעורבות ניהולית מאד גבוהה מצידי.
ניסיתי להדריך וללמד אותו מה נדרש ממנהל מוצר, לתת לו דוגמאות מהעבודה היומיומית
כדי לראות כיצד ניתן להשתפר ובסופו של דבר לאחר תקופה ממושכת של חוסר שיפור, החלטתי
שאין ברירה להחליף אותו. במקום יציב כמו הבנק, זו לא החלטה טרוואלית וזו החלטה שהיה
קשה להעביר במשאבי אנוש אך לאחר שהרגשתי שעשיתי הכל כדי לגרום לו להשתפר, הבנתי
שלהמשיך להעסיק אותו פוגע במוצר, בעמידה ביעדים וכפועל יוצא, בארגון.

Anonymous · Answer

For several reasons (unlisted here for brevity) I needed a team to participate
in the operational up-keep and on-call rotation for a old large stateful backend
service. This was initially unpopular with the team because it was a departure
from what they expected: which was that they'd go on-call only for the new
backend that they'd built if and when it is productionalized.
I spoke to the team individually to ensure I learnt all the reasons for their
lack of support and addressed each of them over a period of 3 months (individual
actions omitted for brevity).
Result:
The two sites where brought together under the wider organization. Tenured folks
in BarLand were able to share their operational expertise and 15+ years of
lessons gathered about customer usecases with the FooLand team. FooLand brought
in fresh perspective to the old backend and learnt valuable lessons on why it
had evolved the way it had. They also got a better understanding of ways to
conduct at-scale tests and learnt more about their own system while teaching
their colleagues.

Additional context, actions taken:
1. Explain benefits of learning how to operate large services
2. Spell out the opportunity to study the code of a $1B data service.
3. Show them why it's beneficial to work with in-house experts (Senior, Staff
engineers on the team whom they'd previously not had exposure to).
4. Promise to make on-call better. And stick to it. Quantify the betterment. We
reduced operational load from 60+/week to <7 when they went on-call
independently.
5. Provide training deliberately.
6. Promise to be open to changes and genuinely listen and incorporate feedback.

Anonymous · Answer

At Auctane, we were following a out dated deployment process. That is inspite of
we moving to monloith services.. we followed a single . It caused a big
bottleneck in our release time frame and I challenged the need for such a train
- as one of the philosophy in Microservice is independently deployable. The team
was relectant to make changes to the process (for e,g we needed to create a
seperate github repo, come up with a artifactory repo) - the team was initially
reluctant to make changes but I convinved the team that this was a good move in
the long run as it would eliminate unnecessary process and speed things. Even
though the team did not agree initially, they saw the value after we migrated to
new process. My philiopy was short term pain for long term gain.

Anonymous · Answer

There was a quarterly project that was supposed to highly critical for testing
and any Issue would be causing a High priority bug.
I assigned the project a new member of my team she was experienced in NON IT
roles but it was her first quarter as QA. I encouraged her to take up the
opportunity and asked her to reach to me for any doubts.
Since she was curious from the start. I was shadowing her test case preparation
and scenario shortlisting along with her as well as answering her doubts on the
platform. My Mangers warned that we might miss some critical scenarios because
of this. Then I would be held responsible.
By the end of the quarter with this high stakes condition she was able to find
more number of Bugs and underlying defects as well which were certified as
tested by exiting members of different scrum team

Anonymous · Answer

We had a large renovation at a labritory scheduled and partway through to job it
was brought to my attention that there was an issue with us disrupting some of
the labritories work. I needed to find a way to complete the work and not
disrupt the client. I descided to change the hours of work for my workers from
days to nights. this was very unpopular but had to be done. I gathered all the
workers together and explained why we needed the change and that it would
benifit us as well by removing obsticles. after a few nights work most of the
workers agreed this was a good idea as it helped speed up our work and shortened
the projects time line

Anonymous · Answer

A client request a dead line I felt was not unachievable. after listening to the
clients concerned,  I explained why the time line was not achievable, due to the
plans being approved by the local planing and zoning department.  The end result
was the client understood the issues and adjusted their expectations.

Anonymous · Answer

At a retreat, I once hosted a sardine tasting event with 30+ unique tins of
sardines.

S -- I wanted to host a memorable event, sharing something I treasured.

T -- I thought sardines would be interesting, as they appealed to the adults and
children alike.

A -- The first run had low attendance, so I scheduled another one for later in
the day. This culminated in four sardine tastings at the camp.

R -- My persistence drew much popularity, and praise from the children and adult
attendees alike.

Anonymous · Answer

I had to migrate some CI/CD tests which run on older devices to run on newer
device. There were already newer device tests added to our end to end pipeline
to be part of CI/CD. My initial idea was to keep them running and not migrate
them.

Later after migrating ~10 suites I was completing the migration program document
and figured that we would have to disable older CI/CD tests once we have newer
device tests which would end the program.

Then I changed my script to migrate anything that is in newer device also so it
would make the disabling process smoother and not human resource intensive.

Anonymous · Answer

Back in December 2024 the decision from the City to descope or "defer" the
station to a later date, I had a team meeting to communicate the decision and
start looking at a full Value engineering. Some of the team members were upset
that after all these years working on designs we were not going to deliver but I
stood strong and reassured that our roles and jobs were kept and that in the
government this is not atypical and that we are still delivering a large scale
project that will keep us busy for the forthcoming years. I maintain that I was
available if anyone needed to discuss this further and make sure that all their
questions were answered in the most transparent way

Anonymous · Answer

As a QA leader I had to choose between run a full check of a new functionality
that wasnt very popular or use or let the change pass over with the aprove of
the PM for some time saving. I choose run the full check, take a few days more,
but when the functionality goes to production it works well, without any bugs.

Anonymous · Answer

Stopped a "pet project" that has high emotional investment but poor Return on
investment. The delivery speed of the critical project improved

Anonymous · Answer

Prioritising clean ups and bug fixes for the current feature over starting the
new feature.

The developers and product owner were keen on starting a new feature because it
provided more customer impact

Can you describe a time when you had to make a decision that was unpopular with your boss or supervisor, and how you navigated that situation?

Practice this question with AI

Go Premium

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

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

Unlock Full Access

Practice More Questions