Share a time when you disagreed with a team member.

Question

Anonymous · Accepted Answer

Situation: I was working on the design on this new microservice that takes a
text string and calls OS for identifying the corresponding translation. My
approach was to make this a batched API to pass in multiple segments at the same
time. There was a conflict with one of the other engineers who suggested that we
should keep it simple and not handle the batching at the OS level but let the
client make concurrent calls. Action: I worked with him to understand his point
of view. He mentioned that it would be better to keep the API contract simple
and to handle this through concurrent thread calls from the parent service. I
explained how lambda has this limitation on no. of threads per instance and the
network overhead we might incur while maintaining these connections. He still
wasnt convinced as felt we would have to do the same while calling the OS
instance internally from this API. I then explained to him that the plan wasnt
to multi-thread calls to the OS but to leverage the query capabilities to batch
query these segments. When I clarified that this was the plan, he was able to
see the benefit of this approach over his suggestion. Result: We landed on a
conclusion that we would do a hybrid approach of sending multiple concurrent
batches of requests with a fixed batch limit. We landed on an optimal batch
limit based on quick performance testing.

Anonymous · Answer

When I was Senior Logistics Manager at Ambev's Extrema site — the company's
largest warehouse at 60,000 square meters — the unit was traditionally seen as a
primary supplier for one specific channel. But based on my experience working
across other regional units, I noticed that a secondary channel had
significantly higher volumes elsewhere, and our site had idle capacity in its
delivery schedule that no one was leveraging. The reason no one had seen this
was simple: the unit had always been labeled as a supplier for the primary
channel, so the secondary channel was overlooked. No one had connected the
distribution network data with the tax incentive opportunity.
My objective was to capture R$2.7 million in tax incentives by tripling the
supply volume from my unit — from 31,000 to 95,000 hectoliters — within 6
months.
I started by analyzing the distribution network for these clients: who was
currently supplying them, what volumes, and which SKUs. Then I assessed my own
inventory and inbound supply plan to understand what I could absorb immediately
without network changes. Next — and this was the critical step — I redesigned
the supply network for all other origin centers, since they would lose volume.
This required very direct communication with the site managers from those units.
During my project presentation, some of them pushed back because they were only
looking at the freight cost increase within their own P&L — about R$500K in
additional transportation costs. I presented the data showing the company would
net over R$2.5 million in tax incentives, and I proposed absorbing the
additional freight costs into my own P&L to remove the objection and accelerate
the decision. That shifted the conversation — everyone aligned once they
understood the total company benefit and saw that I was willing to own the cost.
I then rolled out the plan in phases: I presented the model to the commercial
team and onboarded 3 out of 10 possible clients in the first two weeks as a
pilot to validate the operation before scaling.
I onboarded all 10 clients by the end of month one. I doubled the volume within
two months. By month six, I had delivered 103,000 hectoliters — 8.4% above the
target. Financially, I captured R$2.7 million in tax incentives for the company,
net of the R$500K freight cost that I absorbed in my own budget.

Anonymous · Answer

Situation: Users were experiencing significant delays and errors when
downloading multiple reports in bulk, causing frustration and inefficiency.
Additionally, failures in bulk downloads left users unsure which reports had
issues, further adding to their confusion. During this process, I had a
disagreement with a team member about the best way to address these issues.

Task: Improve the bulk download process to ensure timely completion, clear
communication, and effective handling of any failures, while resolving the
disagreement with my team member.

Action:

Identified the Issue: One of my team members disagreed with the idea of setting
a cap on the number of reports for bulk download, arguing that it might limit
the user's ability to download all necessary reports at once. They believed
users would prefer having the flexibility to download large numbers of reports
in one go.
Communicated Concerns: I explained that without a cap, the system would likely
continue to experience delays and errors, negatively impacting the user
experience. I proposed a compromise where we would set a cap initially and
monitor user feedback to ensure it did not negatively impact user needs.
Quick User Research: Conducted informal research among peers to gather insights
on their preferences and challenges with different page record limits.
Set Limits: Based on the research and team discussions, implemented a cap of
fewer than 100 reports per bulk download to maintain processing efficiency.
Clear Alerts: Updated notifications to inform users that bulk downloads might
take longer, setting realistic expectations.
Progress Indicators: Introduced a progress bar to provide real-time download
status, inspired by Microsoft's approach to enhance user transparency.
Notification System: Implemented alerts to notify users of specific report
failures during bulk downloads.
Detailed Log: Included a detailed log in the downloaded file to identify failed
reports, inspired by ESG’s bulk deletion notifications.
Result:

Efficient Processing: The cap ensured downloads were completed within expected
timeframes, reducing errors and delays.
User Expectations Managed: Clear alerts reduced frustration by informing users
about potential delays.
Enhanced User Experience: The progress indicator kept users informed throughout
the download process, improving satisfaction and transparency.
Clear Communication: Users were promptly informed of any download issues,
reducing confusion.
Actionable Insights: The detailed log helped users identify and address specific
problems, making the process more efficient.
Improved User Experience: These measures streamlined the bulk download process,
enhancing reliability and user satisfaction.
Team Alignment: The compromise and subsequent monitoring ensured the cap did not
negatively impact user needs, and the team member agreed that it was a
beneficial step.
Conclusion: By addressing both the delays and errors in bulk downloads and the
issues related to report failures, I improved the overall bulk download process.
Implementing caps, progress indicators, notifications, and detailed logs ensured
a more efficient, transparent, and user-friendly experience. The process also
demonstrated my ability to handle disagreements effectively, communicate
persuasively, and make data-driven decisions that enhance user satisfaction.

Anonymous · Answer

Situation:
On a recent web project, my teammate and I disagreed on how to handle API state
management in React. I wanted to use React Query for its built-in caching and
revalidation; they preferred Redux Toolkit because it kept everything in one
store.

Task:
We needed to decide quickly, since the choice would affect how other parts of
the app were built. My task was to make sure our decision didn’t slow the
project down or create unnecessary complexity later.

Action:
I suggested we each build a small prototype — one with Redux, one with React
Query — and compare development speed, code readability, and performance. We
reviewed both together, looking at real metrics rather than opinions. During
that process, I also asked what their main concerns were — turns out they valued
Redux’s debugging tools more than the architecture itself.

Result:
We ended up using React Query for data fetching but kept Redux for user session
and UI state. It was a hybrid approach that satisfied both priorities. Later,
our manager highlighted it as a model example of collaborative problem-solving
during sprint review.

Anonymous · Answer

S: My design manager wanted to prioritize aesthetic parity between OpsGenie and
Jira modules before we merged experiences.
T: I believed parity could wait; consistency in workflow mattered more for users
transitioning between tools.
A: I gathered evidence from incident leads who struggled with navigation
friction. I shared a lightweight prototype focusing on cognitive flow rather
than color or typography.
R: After review, leadership shifted priority to functional unification first.
Post-launch NPS rose +18 points among incident managers. The debate strengthened
our mutual respect and taught me how to use evidence over emotion.

Anonymous · Answer

Situation: During the first calibration of Non-Maturity Deposit (NMD) models, I
was working with a senior colleague and a consultancy firm to implement these
models. At that time, market rates were rising, and the consultancy firm
suggested calibrating a key parameter, the "beta," to be highly sensitive to
market rates. My manager agreed, but I disagreed, as I believed this high
sensitivity could lead to inaccurate estimations in future calibrations.
Action: I engaged in discussions with my manager and the consultancy firm to
fully understand their reasoning. They argued that a more sensitive beta could
improve management of metrics like Delta EVE and Delta NII, which was valid.
However, I pointed out that we lacked sufficient evidence to support such a high
beta and that it might cause issues in future estimations. To address the
disagreement, I conducted a sensitivity analysis, testing the model under
various market rate scenarios.
Result: The sensitivity analysis helped us reach a compromise. We agreed to
lower the beta, ensuring more stability in the model's performance. This
adjustment allowed for a smoother transition of the parameter, ultimately
improving the model's reliability while maintaining good risk management
practices.

Anonymous · Answer

Situation:I was working on the design of a new microservice responsible for
taking text strings and calling an external service (OS) to retrieve
corresponding translations. My initial approach involved batching the text
segments into a single API request to increase efficiency. However, one of my
colleagues strongly disagreed with this approach, advocating for simpler API
design, where the client would make concurrent calls rather than handling
batching internally.
Action:Recognizing the need for open communication, I took the time to
understand his perspective. He explained that keeping the API simple would
reduce complexity and suggested relying on the client to manage concurrent calls
via threading. I acknowledged his viewpoint but raised a concern about potential
limitations with Lambda, particularly the restrictions on the number of threads
per instance, and the increased network overhead from multiple concurrent
connections. He countered that the same network overhead could occur internally
when our API calls the OS service.
At this point, I realized there might have been some misunderstanding regarding
my approach. I clarified that instead of managing multiple threads, my plan was
to batch the requests within a single call, leveraging OS's ability to handle
batch queries efficiently. Once this clarification was made, he understood the
benefit of my approach, and we were able to have a more productive discussion
about the trade-offs.
Result:We arrived at a compromise that involved using a hybrid approach. Instead
of forcing the client to manage threading or batching, we decided to send
multiple concurrent batches with a fixed batch size. After running performance
tests, we identified an optimal batch limit that balanced simplicity and
efficiency. The solution not only enhanced performance but also improved our
collaboration and mutual respect for each other's perspectives going forward.

Anonymous · Answer

Our company approved a budget for the training department to conduct a 2 day in
house training for new representatives to the organization. For my entire tenure
at the company I  was responsible for training new reps on anatomy, pathology,
procedure, and products. Our manager was new to the training team and came
directly from sales. Our manager felt it was really important to have one of the
two days dedicated specifically to sales and the selling process. Our sales
representatives are responsible to sell  8 different portfolios, over 7,000
SKUs, in 4 different joint spaces, so there was more than 2 days worth of
anatomy, pathology, and products to review. So we sat down and individually came
up with an agenda and presented it. As we presented we provided the "why" behind
the content and structure. After we both presented we first identified all the
topics by giving them a 1,2,3 based on need of importance.  All number ones were
considered necessary and we gave them a time frame. The number ones took up
nearly 70% of the two days. We then moved to number twos and when we gave them a
time frame we also reranked them in order of importance.
When we finished we had a few number twos left over that we agreed we could try
to squeeze in based on time. We also agreed that the number two and threes would
be be implemented during our extensive 8 day training class the trainees would
attend a few months later. This extensive training class is geared more towards
selling the product and is an extension of their anatomy and product knowledge.

Anonymous · Answer

Our company approved a budget for the training department to conduct a 2 day in
house training for new representatives to the organization. For my entire tenure
at the company I  was responsible for training new reps on anatomy, pathology,
procedure, and products. Our manager was new to the training team and came
directly from sales. Our manager felt it was really important to have one of the
two days dedicated specifically to sales and the selling process. However, we
disagreed on the importance of dedicating one day to sales training. Our sales
representatives are responsible to sell  8 different portfolios, over 7,000
SKUs, in 4 different joint spaces, so there was more than 2 days worth of
anatomy, pathology, and products to review. 
So we sat down and individually came up with an agenda and presented it. As we
presented we provided the "why" behind the content and structure. After we both
presented we first identified all the topics by giving them a 1,2,3 based on
need of importance.  All number ones were considered necessary and we gave them
a time frame. The number ones took up nearly 70% of the two days. We then moved
to number twos and when we gave them a time frame we also reranked them in order
of importance.
When we finished we had a few number twos left over that we agreed we could try
to squeeze in based on time. Otherwise the number two and threes would be be
implemented during our extensive 8 day training class the trainees would attend
a few months later. We ranked the topics based on their importance and allocated
time accordingly.

Anonymous · Answer

Our company approved a budget for the training department to conduct a 2 day in
house training for new representatives to the organization. For my entire tenure
at the company I  was responsible for training new reps on anatomy, pathology,
procedure, and products. Our manager was new to the training team and came
directly from sales. Our manager felt it was really important to have one of the
two days dedicated specifically to sales and the selling process. Our sales
representatives are responsible to sell  8 different portfolios, over 7,000
SKUs, in 4 different joint spaces, so there was more than 2 days worth of
anatomy, pathology, and products to review. So we sat down and individually came
up with an agenda and presented it. As we presented we provided the "why" behind
the content and structure. After we both presented we first identified all the
topics by giving them a 1,2,3 based on need of importance.  All number ones were
considered necessary and we gave them a time frame. The number ones took up
nearly 70% of the two days. We then moved to number twos and when we gave them a
time frame we also reranked them in order of importance.
When we finished we had a few number twos left over that we agreed we could try
to squeeze in based on time. Otherwise the number two and threes would be be
implemented during our extensive 8 day training class the trainees would attend
a few months later.

Anonymous · Answer

Our company approved a budget for the training department to conduct a 2 day in
house training for new representatives to the organization. For my entire tenure
at the company I  was responsible for training new reps on anatomy, pathology,
procedure, and products. Our manager was new to the training team and came
directly from sales. Our manager felt it was really important to have one of the
two days dedicated specifically to sales and the selling process. Our sales
representatives are responsible to sell  8 different portfolios, over 7,000
SKUs, in 4 different joint spaces, so there was more than 2 days worth of
anatomy, pathology, and products to review. So we sat down and individually came
up with an agenda and presented it. As we presented we provided the "why" behind
the content and structure. After we both presented we first identified all the
topics by giving them a 1,2,3 based on need of importance.  All number ones were
considered necessary and we gave them a time frame. The number ones took up
nearly 70% of the two days. We then moved to number twos and when we gave them a
time frame we also reranked them in order of importance.
When we finished we had a few number twos left over that we agreed we could try
to squeeze in based on time. Otherwise the number two and threes would be be
implemented during our extensive 8 day training class the trainees would attend
a few months later. We ranked the topics based on their importance and allocated
time accordingly. However, we disagreed on the importance of dedicating a whole
day to sales training.

Anonymous · Answer

Last year, I consulted for a company called ****. They had built a pilot
solution to track the performance of ****'s container yard and were considering
expanding it to the rest of the country.

They had to retain a large volume of geoposition data for analytics, and the
system wasn’t scaling well. That was my main goal as an external consultant/tech
lead. As soon as I started, I noticed that the main backend engineer wasn’t very
receptive to my ideas. He had designed most of the features, so it seemed that
he was taking code suggestions personally.

After about a week of push-back, I had a call with him. I started by letting him
know that I appreciated his feedback and the work that he had already put into
the system. I wasn’t there to say that he did anything wrong. My only goal was
to scale the system. In fact, I think he did a pretty good job getting things
from the ground up. Most software engineers are not able to build an entire
system from scratch, and he actually did it!

After that call, things were a lot smoother, and we were able to scale the
services.

Anonymous · Answer

Once I had a suggestion to have PaaS resources onboarding process identified and
implemented and suggested the same to my engineering manager, the engineering
manager added his opinion on this as not a priority. I had to disagree as any
resources built by our team needs to be supported and managed as well to
complete the life cycle and avoid incurring issues in the future. I had to
finally collect evidence to support the need for having onboarding in form of
number of incidents logged by customers seeking support on PaaS resources, the
mean time taken to resolve due to lack of the target resolver groups to work on
the incidents and the CSAT scores finally. And eventually the incidents turning
a P1 and being picked by the engineers amidst there ongoing priorities.

Anonymous · Answer

While building the Search feature for a 0-1 Product, I was faced with resource
constraints on the Engineering side due to a critical resource leaving the
company. I now needed to build the same functionalities with less developers. To
tackle this, my Engineering Manager suggested we reprioritize the backlog and
push out some of the capabilities to next release, However, since we had already
idnetified that all of these were critical for the MVP, I did not agree with
this and decided to look further if we can simpify some of the features. During
the discussion with our Storage team, I came up with a solution to leverage
Unicode analyser instead of language based which would give us 6 weeks which
would be ampy time to build the Search without impacting other features.

Anonymous · Answer

There's once a time we had disagreement on the product deliver quality and time
frame. The way I tackle these scenario is always take steps back until we reach
the common ground before move towards the part where we disagree. This way it
would be us working for the same solution not against each other. Then we
balance the priorities and acknowledge what are really right or wrong and what
are more of preference or trade-off. Eventually we will have several solutions
where we have preference but not against each other.

Anonymous · Answer

I disagreed with the business owner on a project where she insisted that end to
end testing is not required and I insisted that we need that due to all the
integrations involved.

Share a time when you disagreed with a team member.

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

Practice More Questions