Tell me about a time you disagreed with a coworker on a technical decision.
answer
- name the decision and the stakes
- state their position fairly first
- the evidence you went and got
- how the call actually got made
- relationship after, with one proof
basics
~20 sTests whether you separate the idea from the person. Answer with one concrete disagreement, evidence you went and got instead of opinions you asserted, a decision that actually got made, and a relationship still intact.
how to answer
5 beats- the decision on the table and why it matteredKeep setup to fifteen or twenty percent of your airtime. Name the actual decision, the risk or deadline riding on it, and your working relationship to the coworker, so the interviewer knows this was a peer and not a chain of command.
- your position and theirs, stated fairlyGive their view in a form they would recognise and endorse, and concede the part of it that was genuinely right. This is the cheapest credibility in the answer, and skipping it makes everything after it sound like a victory lap.
- the move you made to break the deadlockThis is the bulk of the answer, roughly sixty percent. Say what you did rather than what you believed: pulled the defect history, ran a timeboxed spike, wrote a two-column comparison, moved it out of a comment thread into a whiteboard. Agreeing on the deciding measure before you gathered data is the strongest version.
- how the decision was made and what it changedName who decided and on what basis, then give one number for the outcome. Result and reflection together should be about a quarter of the answer, so do not let a long setup crowd this out.
- the relationship afterwards, with proofClose on one concrete sign the person still works well with you rather than an adjective. If part of the final decision was theirs, say so plainly, since a merged outcome reads stronger than a clean win.
your answer
5 story prompts- Pick a disagreement where you were not obviously right at the start.
- Choose one where you can name the evidence you went and got.
- Make sure the story ends in a decision someone actually implemented.
- Have one concrete fact ready about where that relationship stands today.
- This can be the same story as your influencing answer, re-angled.
draft and rehearse your own answer in a learn session
go deeper
Interviewers use this to test conflict resolution and intellectual honesty: can you hold a position, represent an opposing one accurately, and let evidence rather than volume or tenure settle it? A strong answer shows one real disagreement, the specific move that broke the stalemate, a decision that got made, and a working relationship that survived it.
About four months into my first testing role at a large insurance-software group, I disagreed with the engineer who had been my onboarding buddy about how to cover a new claims-submission flow. He wanted all of it driven through the browser, because that is how the rest of our pack worked. I thought most of the risk sat in the API contract underneath. I did not want to turn it into the newcomer arguing with the person teaching me, so I asked him to walk me through why the browser pack had grown that way. He was right that the UI had caught things nothing else caught. Then I asked whether I could spend two days on the defect history. Of the twelve defects that escaped to production on that area over the previous three releases, nine were contract or validation problems a browser test would only have found by accident. I brought that to our next pairing session as a question rather than a verdict: would it be worth trying API-level checks for the validation cases and keeping browser tests for the two journeys a user actually sees? He agreed to try it on one story. Escaped defects on that flow went from twelve across three releases to three across the next three, and the pack for it dropped from forty-one minutes to nine. We still pair. He asked me to write the approach up for the guild of eight of us.
The signal sits in two moves: asking why the existing approach existed before pushing on it, and answering the disagreement with defect history instead of preference. One flow is appropriate scope at this level. It would downlevel if the outcome had no number, or if the coworker were made to sound foolish.
On an enterprise billing platform I led testing for one squad, and a peer lead in the squad beside us wanted a central quality pod to write all the automated checks for both squads' new joiners. I wanted the new engineers writing their own, with us reviewing. We had been circling it in a document thread for a fortnight and the comments were getting sharp. I asked for half an hour at a whiteboard instead. His real worry turned out not to be ownership at all: he had inherited a pack full of checks nobody trusted, and he did not want four new joiners rebuilding that. That is a good reason and I said so out loud before I argued anything. So I proposed we try both rather than debate both. For eighteen days his squad ran the central-pod model and mine ran author-plus-review, and we fixed in advance what we would look at: escaped defects per release, and how long a failing check took to diagnose. His model produced tidier checks, no argument. Mine produced fewer escaped defects, just over six per release before and a little over two after, because whoever wrote the check understood the failure. We merged them: authors write, the pod reviews their first three. He and I have run the joiner rota together since, and he is the person I send strong candidates to.
Feature and squad scope, and the collaboration mechanics carry it: the disagreement moved out of a comment thread, the other lead's real concern was named aloud before any counter-argument, and the deciding measure was agreed before the trial ran. Ending in a merged practice rather than a win is the strongest part.
Own-task scope is fine: a disagreement about your own test, ticket or code path. Show that you asked questions before pushing back, brought something concrete, and worked the outcome once it was decided.
Expect feature scope and a peer you work with daily. The mechanics are the signal: how you surfaced the disagreement, what evidence or spike you produced, and how you kept the work moving while it was unresolved.
Choose a disagreement whose outcome touched the team or production, and say what changed afterwards so the same debate did not have to be had again: a written trade-off, a check in the pipeline, a changed default.
Take a disagreement with cross-team blast radius and show a repeatable mechanism, not a one-off resolution: how decisions of that class get made now, and how the peer came out of it with more standing, not less.
saying these in an interview costs you the question
- Picking a disagreement so trivial it carries no stakes
- Framing the whole story as proving a coworker wrong
- Describing the other position as obviously unreasonable
- No decision at the end, the debate just quietly faded out
- Saying we throughout so your own actions disappear
- Questioning the coworker's competence or motives
- What was the strongest argument on their side?Answer this one generously and specifically. Name the real risk or constraint they were protecting, and concede the part of it you still think was right. Candidates who cannot produce a strong version of the other position reveal that they never understood it, which retroactively weakens everything they just said about resolving the disagreement.
- What would you do differently if that came up again?Pick something procedural rather than confessional: raise it earlier, move it out of a comment thread sooner, agree on the deciding measure before gathering data. Avoid both extremes, the answer that says nothing and the answer that disowns your position entirely. One concrete adjustment, briefly explained, is enough.
- How is your working relationship with that person now?Have one small verifiable fact ready: you still pair, they asked you to review something, you recommended them. Vague reassurance that things are fine reads as a hole in the story. If the relationship genuinely cooled, say what you learned about how you raised it rather than pretending otherwise.
## One prompt, several wordings This is the most reliably asked collaboration prompt in the industry, and it arrives in several wordings that all want the same evidence: - "tell me about a technical disagreement" - "describe a time you and a teammate saw a problem differently" - "when did you have to push back on a peer's design" - and the softened "how do you handle it when someone disagrees with your approach". Treat them as one prompt. The last wording is a trap worth noticing: it invites a policy answer ("I always listen first"), and the interviewer is still waiting for an episode. Answer the policy question with a story anyway. ## What is actually being scored Interviewers on this question are usually filling in three boxes. 1. **First**, do you distinguish the idea from the person, which they detect from how you describe the coworker when you are not on the spot to be nice about them. 2. **Second**, what settles disagreements for you, which they detect from what you did next after the two positions were on the table. 3. **Third**, whether working with you is expensive, which they detect from the aftermath. Almost every weak answer fails on the second or third box while spending its airtime on the first. ## The weak shape versus the strong shape The **weak answer** sounds like this: a coworker wanted to do it a worse way, I explained my reasoning several times, eventually they came around, and the project succeeded. Nothing in it is checkable. There is no cost, no moment of uncertainty, and no mechanism, and the phrase "they came around" is doing all the work. The **strong answer** inverts the ratio: little time on who thought what, most of it on the move that broke the symmetry. That move is almost always one of four things. - You went and got data that neither of you had. - You timeboxed a spike or prototype so the debate became an observation. - You changed the venue, out of a comment thread and into thirty minutes with a diagram. - Or you found the deciding question you both agreed on in advance, so the answer bound both of you. ## Evidence types, roughly in ascending order of persuasiveness 1. A reasoned argument is the floor. 2. A relevant number you looked up is better. 3. A number you produced by running something is better still, because it proves you would rather be corrected than be right. 4. And the strongest is an **agreed measure fixed before the experiment ran**, which is the difference between evidence and ammunition. ## How the bar shifts - A **junior** answer can be entirely about one ticket, and it earns its points for the questions asked before the push-back. - A **middle** answer is expected to show the collaboration machinery working on feature scope. - A **senior** answer needs an outcome someone outside the two of you felt, plus the prevention that followed. - A **principal** answer is judged on whether the resolution generalised into how such calls now get made. ## Two closing details that cost nothing Say out loud the part of their position you still think was right, because that single sentence is the cheapest credibility in the whole answer. And end on the relationship with a fact rather than an adjective: the person you disagreed with later asked you for something. That is what an interviewer means when they say someone is easy to work with.