Please tell me about 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

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: 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

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

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.

Please tell me about a time when you disagreed with a team member.

Practice this question with AI

Go Premium

Community Answers

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Try Free AI Interview

Google

Product Manager

Meta

Product Manager

Meta

Engineering Manager

Amazon

Data Scientist