Tell us about a time when you made an unpopular decision.

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

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

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

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

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

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

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.

Tell us about a time when you made an unpopular decision.

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

Try Our AI Interviewer