Conflict Resolution

Why conflict stories matter

Every NZ tech interview at Senior+ level will ask some version of "tell me about a time you disagreed with someone" or "describe a conflict you navigated." They are testing three things: (1) you can disagree constructively, (2) you can resolve tension without escalating it, (3) you are self-aware about your role in conflicts.

The trap: many candidates either claim they never have conflicts (unbelievable) or tell a story that makes the other person look bad (red flag). The goal is to show that disagreement is normal, productive, and something you handle with maturity.

Types of engineering conflicts

Technical disagreements

Architecture choices, technology selection, implementation approaches. These are the easiest to discuss because they feel "safe" — it is about the code, not the people.

Example question: "Tell me about a time you disagreed with a teammate on a technical approach."

Strong story structure:

We were building a new notification service. My colleague wanted to use a fully event-driven architecture with Kafka. I believed a simpler approach with a job queue (Sidekiq) was more appropriate given our team size and the traffic volume we expected. The tension was real — we both felt strongly and had valid reasons.

I suggested we each write a one-page document listing our requirements, constraints, and concerns. When we compared them, we discovered our disagreement was actually about different assumptions: he was designing for 10x growth in 12 months (which product had hinted at), while I was designing for current load plus a 2x buffer. Once we aligned on the growth expectation with the product manager, we agreed on a middle path: start with the job queue, but design the interface so we could swap to Kafka later without changing calling code. We shipped in two weeks instead of six, and when traffic did grow 18 months later, the migration to Kafka took three days.

Why this works: Both people are reasonable. The disagreement came from different assumptions, not ego. The resolution was data-driven and collaborative.

Process conflicts

Code review standards, deployment practices, testing approaches, documentation expectations.

Example question: "Describe a situation where you and your team disagreed on how to work."

Our team had no agreement on code review turnaround time. Some engineers reviewed within hours; others let PRs sit for days. This created resentment — fast reviewers felt others were not pulling their weight, and slow reviewers felt pressured by pings. As the most senior IC, people looked to me to resolve it, but I did not want to impose my preference.

I raised it in our next retro as a systemic issue rather than blaming individuals. I asked everyone to write down their ideal review turnaround and their biggest frustration. The answers revealed that people were not being lazy — they had different understandings of priority. We agreed together on a 24-hour SLA for initial review (not approval), with a Slack reminder bot as a nudge. I volunteered to set up the bot and monitor the first month. Review turnaround stabilised at about 6 hours on average, and the resentment disappeared because everyone had the same expectation.

Interpersonal conflicts

Communication styles, work ethic differences, personality clashes. These are the hardest to discuss well.

Key principles:

• Never make the other person the villain
• Show empathy for their perspective
• Focus on what you learned about yourself
• Demonstrate that you sought to understand before being understood

Example:

I had a colleague who gave very blunt code review feedback. Comments like "this is wrong" or "why would you do this?" without explanation. I initially felt defensive and avoided requesting his reviews. But I noticed his code was excellent, and others seemed fine with his style.

I asked him for coffee and said I wanted to understand his approach to reviews. He explained that in his previous team, brevity was valued and detailed explanations were seen as patronising. I shared that I found the terse style hard to act on because I could not tell what was actually wrong. We agreed he would add a one-sentence "because..." to critical comments, and I would ask clarifying questions in-thread rather than guessing. Our working relationship improved significantly, and I learned that my assumption — that he was being rude — was wrong. He was being efficient by his standards.

Cross-team priority conflicts

When teams disagree on what matters most, usually because of competing goals or limited shared resources.

Example:

My team needed the platform team to prioritise a database migration that was blocking our feature launch. The platform team had their own roadmap and saw our request as lower priority. My initial instinct was to escalate to management, but I decided to try a different approach first.

I scheduled a 30-minute meeting with their tech lead. Instead of arguing why our work mattered more, I asked about their priorities and constraints. I discovered they were under pressure to reduce infrastructure costs by quarter-end. Our migration would actually help — the new database was 40% cheaper to run. I reframed my request: "this migration serves both our goals." They moved it up in their sprint, we provided the migration scripts to reduce their workload, and both teams hit their quarterly goals.

Resolution framework

A reliable framework for resolving any engineering conflict:

1. Listen — truly understand their position

Do not formulate your rebuttal while they are speaking. Ask clarifying questions. Repeat back what you heard: "So your concern is X, because of Y?"

2. Understand — find the root disagreement

Most conflicts are not what they appear on the surface:

3. Find common ground

There is almost always shared ground: "We both want the system to be reliable" or "We both want to ship by the deadline." Start there.

4. Propose a path forward

Offer a concrete suggestion. Good patterns:

• Time-boxed experiment: "Let us try your approach for two sprints and measure X"
• Hybrid: "What if we combine the strengths of both approaches?"
• Escalation with data: "Let us present both options to the team with trade-offs and decide together"
• Disagree and commit: "I still prefer X, but I understand the team chose Y. I will commit fully to Y."

5. Follow up

After resolution, check in. "How do you think that is working?" This shows the relationship matters to you, not just winning.

Discussing past conflicts safely

Rules for interview storytelling

1. Show respect for the other person. "They are a strong engineer with a different perspective" not "they were wrong."
2. Own your part. What did YOU contribute to the tension? Even just "I could have raised my concern earlier."
3. Focus on the process, not the personalities. How did you resolve it, not who was "right."
4. End with the relationship intact. "We work well together now" or "I learned to appreciate their perspective."
5. Show growth. What did this teach you about yourself or about handling disagreements?

Phrases that signal maturity

• "In hindsight, I think their concern was valid because..."
• "I realised my initial reaction was based on assumption, not fact"
• "We found that our disagreement was actually about different goals"
• "I learned that I tend to X under pressure, and now I consciously do Y instead"

Red flags to avoid

• "They were just wrong" — shows inability to see other perspectives
• "I had to escalate to my manager" — as the FIRST step (escalation is fine after trying direct resolution)
• "It was not really a conflict" — downplays the question; interviewers want a real example
• Spending 80% of the story explaining why YOU were right

NZ-specific context

New Zealand has a strong culture of "tall poppy syndrome" avoidance and consensus-seeking. In interviews:

• Show that you prefer direct conversation over escalation
• Demonstrate that you value relationships alongside outcomes
• Show awareness that different communication styles exist (Kiwi directness is different from American directness)
• If you come from a culture with more hierarchical communication, acknowledge that you have adapted to flatter structures

Practice questions

1. "Tell me about a time you disagreed with your manager"
2. "Describe a situation where two people on your team were in conflict"
3. "Tell me about a technical decision you regret"
4. "How do you handle it when someone pushes back on your code review feedback?"
5. "Describe a time you had to compromise on something you felt strongly about"