Tell me about a conflict that you had to manage.
Software Engineer
Engineering Manager
Frontend Engineer
Full Stack Software Engineer
Square
Instacart
Meta
Asana
Flexport
Answers
Anonymous
4 months ago
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
6 months ago
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.
Anonymous
6 months ago
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
6 months ago
- 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.
- 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.
- 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.
- R - I was able to convince him, and we were able to create the data model
- Follow up - what were the arguments that used?
- I told him that having separate tables will be easy to scale for the future
- If we need to change the granularity at some point it will not affect the table
- Easier to maintain
- 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.
Interview question asked to Technical Program Managers, Network Engineers, Data Scientists and other roles interviewing at Slice, Confluent, Nykaa and others: Tell me about a conflict that you had to manage..