Last quarter I ran a mock with a candidate prepping for a senior-IC loop, and the conflict question sounded like this:
Interviewer (me): Tell me about a time you disagreed with a peer.
Candidate: There was an engineer on my team who kept pushing back on my designs. He was not very experienced and he had really strong opinions for someone who had been there six months. I tried to be patient with him, but eventually I had to escalate to my manager. We ended up going with my approach.
I stopped him there. We had ninety seconds of feedback before the next round, and I told him that the answer he had just given would have ended the round at almost any company I have interviewed for. Not because his approach was wrong. Because the shape of the answer was wrong. He had told a story in which he was the protagonist, the other engineer was the antagonist, and the resolution was the antagonist losing. Interviewers reading that pattern, in my experience, score it as low collaboration, low empathy, and possibly low self-awareness.
This article is the shape I taught him to use instead, what each section is doing, and the most common failure modes I see in candidates running other shapes. The change took about twenty minutes of practice. He went on to pass the loop.
What the question is actually grading
The "tell me about a conflict" question is not grading whether you have ever had a conflict (everyone has) or whether you won the conflict (winning is irrelevant). It is grading three specific things:
- Can you describe the other person's position fairly, without strawmanning?
- Did you investigate their position with curiosity before pushing your own?
- Did the resolution leave the working relationship intact, or did it burn it?
If you score on all three, the rest of the story does not matter much. You can have lost the disagreement, you can have changed your own mind, you can have reached a compromise that was nobody's first choice. Any of those land fine. What does not land fine is a story where the other person is described in a way that makes them sound unreasonable, or where the candidate did not seem to seriously consider that they might have been the one who was wrong.
Most candidates default to a story shape that fails on point 1, because the candidate's natural narration of the conflict places themselves at the center. The shape I teach inverts that.
The shape
The load-bearing section is section 2. Ninety seconds of generous, specific description of the other person's position, told as if you were them, before you ever describe your own position. This is uncomfortable on the first try because most people have not actually thought through the other side carefully. Practicing this section is most of the work.
The ratio matters. Roughly a third of the answer is on the other person, a sixth is on your own position, a third is on the bridging work, and the final tenth is the resolution and reflection. The ratio signals that the candidate spent meaningful time thinking about the other person, which is what the interviewer is grading.
What "steelmanning" actually sounds like
The word steelman is over-used in tech writing and the meaning has gotten fuzzy. What I mean by it, in this specific context, is that you can describe the other person's position in their own terms, with their best evidence, in a way they would nod along to.
A non-steelman version of section 2 sounds like:
She thought we should use Postgres because she did not know much about NoSQL. She was used to relational databases from her last job and she was not really open to alternatives.
That is a strawman. It frames her position as ignorance plus stubbornness, and the interviewer hears it that way.
The steelman version sounds like:
She had spent three years at her previous company watching them migrate off MongoDB to Postgres after a series of operational issues with sharding. Her concern was that we were two engineers trying to operate a system that needed strong consistency guarantees on financial data, and that the operational maturity of Postgres at our team's scale was the right tradeoff against the schema flexibility I was advocating for. Her position was specifically that the cost of running NoSQL operationally would dominate the cost of doing schema migrations. With our headcount, that was a defensible position.
The second version foregrounds her reasoning with specifics: a previous experience that informed her, what she was specifically worried about, what she was optimizing for, and an acknowledgement that her position was defensible on its own terms. The interviewer reads that and immediately scores higher on collaboration.
The trick I teach is: write the other person's position out as a paragraph in their voice during prep. Not in your voice talking about them. In their voice. "My concern with the migration is..." "What I have seen go wrong before is..." If you cannot do that, you do not understand their position well enough to talk about it in the interview.
The bridging work
Section 4 is where most candidates accidentally make themselves the hero. The mode that fails is to describe the bridging work as a list of moves you made that the other person eventually accepted. The mode that works is to describe the bridging work as a series of two-way exchanges where both sides moved.
The failed version sounds like:
So I scheduled a meeting where I presented the data on NoSQL operational maturity, and I walked through the schema migration costs we would face with Postgres. By the end of the meeting she agreed with me.
The working version sounds like:
I asked if we could spend a week each running a small spike on each option. We agreed on three concrete tests we would each run, and what evidence would change either of our minds. After the spike, my benchmarks on schema migration cost were less compelling than I had expected, and her operational concerns about NoSQL turned out to be partly addressable with a managed service. We ended up with a hybrid: Postgres for the financial data, where her concerns were strongest, and a NoSQL store for the event log, where my concerns were strongest. Neither of us got our first choice exactly, but the architecture we shipped was, in retrospect, better than either of our original positions.
The second version describes a process where evidence was gathered, both positions evolved, and the outcome was a synthesis. That is what most actual conflict resolution looks like in practice, and it is what the interviewer wants to hear, because it is what they want to see you do on their team.
What if you actually were right and they were wrong
A fair objection: what if the other person genuinely was being unreasonable? What if the conflict was not a thoughtful technical disagreement but a colleague who was just blocking everything for political reasons?
My honest answer is that those stories rarely play well in interviews, even when they are true. The interviewer cannot verify your account of the other person's behavior, and the more egregious the colleague's behavior in your telling, the more the interviewer's calibration drifts toward "this candidate may be uncharitable about their colleagues". This is a well-known judgement bias and it does not unwind during a forty-five minute interview.
The practical advice: pick a different story. You almost certainly have other conflict stories from your career, and a story where the other person had defensible reasoning will land better than a story where they did not, even if the second story is true and the first is not the most dramatic thing you have lived through. The interview is not the place to vent. The interview is where you are demonstrating that, even in disagreements, you can be charitable about your colleagues. Pick a story that lets you do that.
The reflection at the end
Section 5 is short, but it is doing something specific. The thirty-second resolution should include a sentence about what changed in your view of the other person, not just what changed in the technical outcome. Something like:
What I took from it was that her instinct to weight operational cost was something I had been undervaluing on my own designs. I have run that consideration through every design I have made since.
That sentence does two things. It signals that you learned something from a peer (a collaboration positive). It also signals that you are willing to be wrong on a particular axis, which is a self-awareness positive. In a forty-five-minute interview, that one sentence is high-leverage.
A small dialogue I have heard work
The candidate from the opening of this article re-told his story with this shape. The version he eventually delivered, paraphrased:
Last year a junior engineer on my team and I disagreed for several weeks about a refactor I was proposing. His position was that the refactor was high-risk relative to its benefit, and he could point to two examples on our team in the last year where similar refactors had broken production for half a day. He had been on-call during one of them and was acutely aware of what the operational cost looked like. My position was that the existing structure was making feature work slow, and that the refactor would unblock six months of pending work. We ran a one-week experiment where I refactored a small piece of the codebase, and we tracked both the migration time and the disruption to ongoing feature work. By the end, my refactor was slower than I had estimated, but his concern about a half-day outage did not materialize because we caught the issue in a canary. We ended up doing the refactor, but more incrementally than I had originally proposed, with checkpoints he had asked for built into the rollout. The thing I took from it was that I had been treating his caution as conservatism, and it was actually pattern-matching from concrete on-call experience I had not had. I have asked junior engineers' caution-flags more seriously since.
Four minutes, weighted correctly. He passed the round.
The shape is portable across companies
This shape works at the four companies I have interviewed at and the half-dozen others where I have heard from friends about their behavioral rounds. The exact phrasing of the question varies ("a time you disagreed", "a time you worked with someone difficult", "a peer who frustrated you"), but the underlying grading is consistent: can you be fair about the other side, did you investigate before pushing, did the relationship survive. The shape above scores well on all three. The shape most candidates default to does not.
If you remember one thing from this article: the section on the other person's position is longer than the section on your own. If your draft has those backwards, the answer is sideways. Flip the ratio and the round shifts.