I want to hear about a conflict that you managed.

Question

Anonymous · Accepted Answer

At Toyota Motors North America, I encountered a significant conflict involving a
critical data pipeline performance issue. The team was split between two
strategies: one side wanted to overhaul the PySpark code for immediate fixes,
while the other preferred a cautious approach, fearing potential disruptions.
To address this, I proposed a hybrid solution that balanced both perspectives. I
led a data-driven investigation using AWS Databricks and Apache Airflow to
identify bottlenecks and optimize performance without extensive code changes. I
presented a proof-of-concept that demonstrated how targeted optimizations and
strategic enhancements could improve performance by 17% without compromising
system stability.
This approach not only resolved the conflict but also garnered support from both
sides, showcasing my ability to integrate technical insights with effective
communication. The successful implementation of this strategy reinforced the
importance of combining analytical skills with collaborative problem-solving.

Anonymous · Answer

Identify Problem: I noticed conflicts between M and T during meetings and
through lengthy, unresolved PR reviews. M and T were debating over the design of
a crucial component for our product integration and data integrity.
Action: To understand their perspectives, I spoke with M and T separately. M was
frustrated because T made significant design changes without team consultation,
believing his original design was sufficient. T, on the other hand, felt M’s
design lacked thorough research and documentation, posing risks to the project’s
success.
Solution: I brought them together for a discussion, emphasizing the importance
of focusing on the issue rather than personal grievances. During the meeting, I
encouraged both to consider stakeholders' needs and facilitated a structured
brainstorming session. We identified several key points:
Stakeholder Meetings: They agreed to meet with stakeholders to understand their
use cases and system integration requirements.
Design Session: They planned a detailed design session where they would present
and compare proposals, including the pros and cons of each alternative.
Seek feedback: They presented the proposal to  an architecture commit for
feedback
Decision Commitment: They committed to agreeing on a final design decision based
on the analysis and feedback.
Follow-Up: To ensure progress, I scheduled follow-up meetings to monitor their
collaboration and offer support. 
This approach not only resolved the conflict but also improved their working
relationship and communication. Ultimately, the team successfully designed the
component, got buy-ins from the bigger organization,  ensuring robust product
integration and data integrity.

Anonymous · Answer

1. S - In one of the dashboards      I was creating data model for the
    dashboard with the team. Basically, this      was going to be the source of
    truth for the upcoming dashboard and the      previous dashboards that we
    had done.
 2. T - It was combining data      from various sources and had a lot of
    calculations involved. My colleague      and I had very different ideas of
    how to create this model. He wanted to      have everything in one table. My
    idea was to have a little normalized data      and have it in separate
    tables mainly calculations.
 3. A - Because we were not agreeing to, I      listened to the reasoning behind
    the point. He wanted to have it in one      because it would be faster to
    query the data, since we use the same      calculations multiple times. My
    point was that since we are building it      for the future, and we might
    add multiple steps in the process, having      separate tables will
    guarantee that we do not disrupt the granularity of      the data.
 4. R - I was able to convince      him, and we were able to create the data
    model
 5. Follow up - what were the      arguments that used?
    1. I told him that       having separate tables will be easy to scale for
       the future
    2. If we need to change the       granularity at some point it will not
       affect the table
    3. Easier to maintain
 6. Impact - When I developed      this, I was able to see show that it was a
    correct decision. After some      time we got to know that they were adding
    a few more steps in the process      and hence we just needed to adjust the
    table calculations.

Anonymous · Answer

I had to facilitate a conflict between a Product Manager and other stakeholders
in the project. I had a conversation about it separately with each party
involved to try to understand the situation, causes of conflict and a potential
solution. It was crucial to get the perspective of both parties, essentially the
conflict was around the fact that the PM was extremely overwhelmed so didn’t
have the bandwidth to handle all questions and requests that were coming from
the ops teams that were trying to raise feature requests based on customer
feedback. I have later on suggested a dedicated process to raise feature
requests through JIRA, containing all the mandatory information and assessed
priority.

Anonymous · Answer

When managing the Dart & Flutter Security program I had to deal with friction
between an engineering lead and the Flutter security team.
The security team created a design document outlining the steps to improve the
security posture of the flutter code review processes. One of the proposals was
to remove force merge permissions from the github repository and the engineering
team lead shared strong opposition to that change because of the risk of slowing
down development workflows.
It turns out that a few days later the google global security team and github
pushed a change removing the force merge permission for google open source
projects. The next day the engineering technical lead joined the flutter
security weekly meeting yelling and blaming the team for implementing a change
that was not approved by engineering.
I had to intervene and ask the engineering lead to calm down. I explained that
the meeting audience was not appropriate to deal with the conflict and I offered
to create a meeting between him and me the next day to discuss the details and
meanwhile we will investigate what happened because the security team didn’t
change the repository configurations.
A tracking bug was created to update with the findings of the investigation. It
turned out to be a coincidence but it also turned out that the concerns of the
development velocity being impacted was not true as nobody was blocked during
the day.
My approach to address the conflict was to stop the meeting before it escalated
and rescheduling the next day when more information was available. Not only
stopped the conflict but it also fostered the involvement of the engineering
team in the security initiatives driving more collaboration.

Anonymous · Answer

I’m my current role, during a core-team meeting I noticed conflicts between 2
team members, the MM and the EE. They were debating about why to include one
component in the official BOM and discarding another one.
To understand their perspectives, I spoke with them separately in a friendly
environment. The MM was frustrated because the EE didn’t provide any data or
argument to discard the component that the MM suggested. This component had the
same performance, was pin to pin compatible, and cheaper. On the other hand the
EE explained he had bad experiences in the past with the component suggested by
the MM and he refused to validate and qualify it to do not waste his time.
So… After being clear about the situation, I brought them together for a
discussion and I emphasize to focus on the issue, not in personal discrepancies.
Do, during the meeting, I encouraged both to consider the Project requirements,
customers need and I worked with them brainstorming session.
Then, they agreed to meet with other stakeholders to get their inputs about
these 2 components, they commit on a validation plan including both components.
The one suggested by the EE as POR and the one suggested by the MM as alternate.
They also agree to allocate 60% of the mass production volume to the EE
component and 40% to the component suggested by the MM.
From my side, to ensure progress, I scheduled follow-up meetings with them to
monitor their collaboration and for sure, I offered my support. Finally, both
components are currently part of the product official BOM and these 2 guys
improved their working relationship and communication.

Anonymous · Answer

So before we shipped our app to production, we will do QA testing phase. We have
had multiple squad and QA as well. There were a problem where people from each
squad started to give QA APK directly and creating a confusion between QA
because sometimes they found some of the feature not working because it is still
worked on by other engineer. To takcle this, i created a standard way for all
squad to give apk after it is done merging to main branch. I created continues
integration and when Pull Review is done, it will run automatically and build
apk and send it to the QA through Firebase App Tester.

I want to hear about a conflict that you managed.

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

Master Data Science Interviews