Share a time when you had a disagreement with a member of your team.

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

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

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

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 had a disagreement with a member of your team.

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

Master Data Science Interviews