Conflict Stories 2 of 5: Critical Elements for Choosing Your Conflict Story
The simple framework for choosing interview-worthy stories
This is the second in a series of posts on telling conflict stories, derived from the content in my upcoming book, Mastering Behavioral Interviews.
Want to get early access to the book and follow along with the writing process? All you have to do is subscribe to the substack!
Willing to be a beta reader in exchange for having your name printed in the book? Apply here and I’ll keep you in the loop on how to help with the book.
You've identified several workplace conflicts from your career—maybe an implementation disagreement with a senior engineer, pushback from product on technical debt work, or resistance when you tried to introduce better testing practices. If you need help identifying some stories, check out my first post.
Which story should you tell?
The story you choose can make the difference between demonstrating senior-level conflict resolution skills and accidentally positioning yourself as someone who gets bogged down in trivial disputes.
Here are the three critical elements that separate interview-worthy conflict stories from ones that will hurt your candidacy:
High stakes
High (and high quality) involvement by you
You were right
Element #1: High Stakes
The conflict had meaningful consequences if left unresolved.
Low-stakes conflicts make you seem like someone who creates drama over minor issues. High-stakes conflicts show you understand what's worth fighting for and have the judgment to engage constructively when it matters.
What high stakes look like:
System reliability: "If we shipped without proper error handling, our payment system could go down during Black Friday."
Team productivity: "The technical debt was causing us to spend 60% of our sprint capacity on bug fixes instead of new features."
User experience: "The proposed API changes would have broken backwards compatibility for 10,000+ existing integrations."
Business outcomes: "Using the heavyweight framework would have delayed our MVP by three months, missing our crucial market window."
What low stakes look like:
Code formatting preferences
Minor naming convention disagreements
Which text editor the team should standardize on
Debates over commit message formats
The litmus test: Would a senior engineer or manager care about this conflict? If the answer is "probably not," find a different story.
Element #2: High (and High Quality) Involvement
You were a central player who actively drove the resolution and you demonstrated strong resolution skills.
Being peripherally involved in someone else's conflict doesn't showcase your skills. Nor does being involved deeply but not contributing to the resolution.
What high involvement looks like:
You initiated the difficult conversation
You proposed the compromise or alternative solution
You gathered data or built prototypes to inform the decision
You facilitated meetings between conflicting parties
You escalated appropriately when direct resolution wasn't working
What low involvement looks like:
You were in meetings where others discussed issues
Your manager resolved the conflict for you
You went along with whatever was decided
You complained to others but didn't address it directly
The involvement spectrum:
Observer: "There was a big disagreement on my team about..." ❌
Participant: "I was part of a discussion where we disagreed about..." ⚠️
Driver: "I disagreed with the approach and worked to find a better solution..." ✅
Tip: Sometimes the key is how you tell the story, what actions you showcase. In this example, the conflict and outcome is the same but what actions you highlight are different.
❌ "My team had a big argument about which database to use. Eventually my manager made the decision."
✅ "When my teammate proposed MongoDB for our analytics pipeline, I built a performance comparison showing PostgreSQL would be 3x faster for our query patterns and presented it to the team, where the manager made the final call."
Element #3: You Were Right (Or Partially Right)
Your position was ultimately validated by events or consensus.
This might seem obvious, but many candidates choose stories where they were wrong, thinking it shows humility. While self-awareness is valuable, conflict resolution questions are specifically assessing your judgment and persuasion skills. Leading with a story where you made a poor call undermines both.
Why being right matters:
Validates your technical judgment: Shows you can identify real problems and solutions
Demonstrates effective advocacy: Proves you can persuade others when you have a good case
Reduces interviewer risk: Makes them confident you won't create unnecessary conflicts at their company
What "being right" looks like:
The solution you advocated was ultimately adopted
Your concerns about the alternative approach proved accurate
The compromise you proposed worked better than either extreme
You successfully changed someone's mind with data or reasoning
Handling nuanced outcomes:
Sometimes conflicts don't have clear winners. You can still use these stories if:
Your core insight was validated even if the exact solution differed
You were right about the problem even if the final solution was collaborative
Your approach to the process of resolution was effective regardless of the technical outcome
Red Flags to Avoid
Even stories with high stakes, involvement, and correctness can backfire if they contain these elements:
Obvious cultural mismatches: If your story involves rigid hierarchy when the company values flat structures
Unresolved endings: If relationships were damaged or the conflict still festers
Disproportionate effort: If you spent weeks fighting over something that could have been decided quickly
Remember: the goal isn't to prove you're always right or that you love fighting. It's to demonstrate that when disagreements arise—and they will—you have the judgment to pick your battles wisely and the skills to resolve them constructively.