In Interviews, Talking About Conflict Isn't About 'I Won'—It's About 'How We Won Together'

Behavioral interviews often include a classic question:

“Can you tell me about a time you had a conflict with someone?”

When many people hear the word “conflict,” their minds immediately jump to arguments, table-pounding, and confrontational scenes. So when they tell their stories, they either emphasize “I won in the end” or “how magnanimously I gave in.”

But real workplace conflict is often quiet.

It’s the tug-of-war between two solutions, the misunderstanding behind different goals, the friction between “you think it’s reasonable” and “I think it can actually be implemented.”

What interviewers really want to hear is not that you won the argument, but how you carried the disagreement forward and kept everyone on the same boat.

Technical conflict: not who won, but how we found a new path

That time, we were building a batch data scoring system that needed to calculate scores for thousands of financial entities and publish the results to multiple systems.

One engineer proposed an architecture design: use Kafka with distributed locks for coordination control in the internal processing.

It was a workable solution. But I had many doubts: if something went wrong, the retry logic would be very complex, and the lock mechanism could easily introduce deadlocks and uncontrollable delays. Maintenance costs would be high, and future scalability was also questionable.

My first instinct was, of course, to “change the solution,” but I knew clearly that the more complex the system, the less you can push things forward by “persuading others.”

So instead of directly rejecting it, I led everyone to break down the discussion around key points: What do we care about most? Can we accept partial task delays? What level of failure recovery does the system need to support? Which components can be asynchronous, and which must be sequential?

Each time we focused on dissecting one problem, and during that process I gradually proposed a hybrid design:

• Switch internal calls to gRPC and drop the lock mechanism;
• Keep Kafka, but only for inter-system event publishing;
• Move the risk scoring logic to a graph database, using declarative statements to express scoring rules, avoiding a process-oriented orchestrator.

At first, this solution wasn't the most familiar to everyone. But as we worked backward from the goals to the implementation path together, many of the points we had argued about were no longer about who was right or wrong, but about whether they could actually solve the problem.

We ended up using this structure. Processing time dropped from over ten hours to under two hours, and it later evolved smoothly into real-time computation.

But more importantly, I think that design process built a subtle yet solid trust among a few of us.

Everyone knew that even if we initially disagreed, each person could be seen and heard in the process, and together we found a new path that wasn't a compromise but a co-creation.

Later, I summarized this approach for myself: “The solution to technical conflict isn't about who wins, but about whether someone can help the team bypass that either-or line of confrontation.”

That is “I disagree, but we won together.”

Non-technical conflict: not about who's reasonable, but about who's willing to carry it together

Another conflict had nothing to do with technical solutions.

We were pushing forward a cross-team collaboration project, and the other team had originally promised to deliver data by a certain date. Three weeks passed, and nothing happened.

Everyone on the project was waiting for their delivery, but I could sense it wasn't just a “schedule delay.” Because every time we followed up on progress, they were very polite but always avoided discussing details.

I decided to stop pressing for progress and instead proactively reached out to the counterpart to talk one-on-one, asking what he was most worried about.

He hemmed and hawed and said: their team was actually right in the middle of layoffs, and many internal processes were stuck. Although this project was important, it didn't directly affect their business metrics, so it had been placed in the “can be postponed” category.

To put it bluntly, they wanted to cooperate, but they just couldn't move it forward.

After understanding that, I reframed our team's project goal as “the other team's data integration is one of the key risks to the project MVP's success,” wrote it into the weekly status report, and confirmed with the project manager whether we could bring in the product manager to help with the decision.

This step both helped us gain higher-level attention and gave the other team a way out: “I'm not pressuring you; I'm helping you lay the problem out on the table.”

Two weeks later, the other team allocated resources, and the first batch of interfaces was finally connected.

This story has no architecture, no code, and even sounds a bit trivial.

But it made me see the real resistance behind the surface conflict. I didn't stand on the position of “I'm reasonable, you're delaying.” Instead, I found a way for the other party to re-engage. I didn't persuade anyone; I helped a teammate who had already backed away from the table step back up to it.

The surface of conflict is often “non-cooperation,” but what you really need to solve is building trust and building connection.

How can AI help us see the invisible reasoning process in conflict?

When I practice these stories, what I use most isn't a polishing prompt, but a questioning prompt.

Especially in conflict scenarios, I want it to help me ask about the judgment points I haven't explained clearly myself.

Here is the prompt I use most often. You can use it directly:

Here’s my conflict resolution story. Please: – Identify where I made a decision but didn’t explain why. – Ask me 3 questions that test how I handled uncertainty and opposing views. – Suggest how to clarify any reasoning that may sound like assumption or authority-based, not trust-building.

The point of this prompt isn't to get template feedback from AI, but to have it help you find the reasoning process you've overlooked.

After each practice, I ask myself three questions:

• Did I truly explain “how I judged what the other person cared about at the time”?
• Did I use actions to express “I don't want to win, I want to win together”?
• Where was the trust that made the other person willing to continue working with me built?

If I can't answer all three, then my story isn't good enough yet.

Conflict isn't about proving right or wrong, but about building confidence to move forward together

Looking back at all the conflict stories I've prepared, whether technical or collaborative, there's one common thread: conflict doesn't test how strong I am, but whether I can make people feel at ease.

A good conflict story lets people hear three things:

1. Do you have reasoning ability—can you see the real point of resistance amid disagreement, rather than just staring at surface inconsistencies?
2. Do you have a collaborative mindset—not pushing forward by winning, but gathering strength through shared goals?
3. Have you built trust—not just everyone dispersing after success, but people still willing to listen to you before things are done?

In interviews, talking about conflict isn't about “I won.” It's about making people believe: even if we disagree again next time, I'm willing to win with you again.

Because conflict isn't where trust is consumed; it's where trust begins to be built.