Tell me about a time a teammate convinced you your technical position was wrong.
answer
- the position I held, and how firmly
- how the challenge reached me
- what I asked for before conceding
- conceded in public, by name
- what shipped, and what I changed
basics
~10 sTests persuadability: whether evidence moves you rather than seniority or volume, and whether you concede where the original argument happened. Show the challenge, what specifically changed your mind, and the credit you gave.
how to answer
5 beats- the position I held and how firmlyKeep it to a fifth of the airtime, and make the commitment real: say you had written it down or defended it in review. A position you barely held makes the update meaningless.
- how the challenge reached meDescribe who raised it and what they actually argued, in enough detail that the interviewer can judge it. Include your first internal reaction honestly, especially if it was dismissive.
- what I asked for before concedingThe strongest beat in this answer. Name the thing that would settle it — a reproduction, a benchmark, a spike — and who ran it. This is what separates evidence-driven updating from social capitulation.
- conceding, where the argument happenedWith the previous beat, roughly sixty percent of your airtime. Say where you conceded and roughly what words you used, and how the other person's contribution stayed attached to their name.
- what shipped and what I changedClose in twenty seconds or so with the outcome and one number, plus the habit it left you — ideally a rule about how you respond to challenges rather than a resolution to be humble.
your answer
4 story prompts- Pick a position you had already defended once in writing, so conceding cost you something.
- Choose a challenger junior to you if you have one; it is the stronger version.
- Be able to name in one sentence the exact evidence that moved you.
- This can be your being-wrong story told from the other person's entry point.
draft and rehearse your own answer in a learn session
go deeper
Interviewers use this to test whether you update on evidence and whether you are safe to disagree with. They are checking that a less senior voice can actually move you, that you concede in the forum where you argued, and that credit lands on the person who was right. It predicts how debate goes on their team.
I was a maintainer on an open-source backend project going through a storage migration, and I owned the backpressure design for the new driver: when a sink slowed down, producers would block on a shared semaphore. I had written the proposal and had already answered two rounds of review comments defending it. A contributor who had been around maybe six weeks said in the thread that the shared token would deadlock under fan-out, because one slow sink would hold what the fast sinks needed and the retry loop would keep re-queuing behind it. My honest first thought was that they had misread the ordering. Rather than reply with that, I asked them to show me. They ran a two-day spike: a synthetic fan-out with one deliberately slow sink. It stalled in under a minute, for precisely the reason they had written in the thread. I replied in the same thread, not privately, that my design was wrong and that per-sink budgets were what we should merge, and I asked them to open the pull request instead of folding their idea into mine. On the reference deployment, burn under fan-out went from 4.1x during the stall window to under 1x. My takeaway is a rule: when my instinct is that someone misread it, that is the cue to ask for a reproduction, not to explain.
The move that carries this is converting a dismissive instinct into a request for evidence, then conceding in the same public thread and handing over the pull request. Naming the deadlock argument specifically shows real engagement. Merging the idea under their own proposal would have undone the whole signal.
I ran the release train for an open-source backend project through its migration, and I had published a compatibility guarantee: adapters written against the old interface would keep working for two trains after the new one landed. I had defended that window publicly, twice, against maintainers who wanted it longer. Another maintainer, who also operates thirty-four downstream deployments, wrote to the list with something I could not argue away. Their deployments move on a quarterly change freeze, so two trains was, in practice, one window they could take — and missing it stranded them on an unsupported interface. Two other maintainers said their users sat in the same position. I had assumed everyone shipped on our rhythm, and I could not see that assumption until someone wrote it down. I amended the policy: four trains plus a written end date, and every deprecation now carries a short section naming who cannot take the window, filled in by someone other than the author. I posted that under my own name and said the original window came from our release cadence rather than from operator reality. Six trains later, the tracked deployments had moved off the old interface with no emergency backports, and burn attributable to interface migration stayed in single digits per train. The section outlived the argument, which was the point.
Seniority shows in retracting a position that had been defended publicly twice and then changing the process rather than only the number — a required section someone else must fill in. Naming the invisible assumption is what makes the update credible. Quietly extending the window would have read as a concession, not a correction.
It is enough that you asked for the reasoning instead of assuming the more experienced person was simply right. Say what you tested or read that made it click; deference alone is not persuadability.
Pick a position you had already defended at least once, so conceding costs something. The interviewer is listening for what you asked for before you changed your mind — a benchmark, a reproduction — and for where you said so.
The strongest version has someone junior to you changing your mind, and shows you making that safe: asking for the reproduction rather than explaining why they misread it, then handing them the work. Say what it changed about how you run reviews.
At this scope you had a published position with followers, so updating it costs other people their footing. Show how you retracted without stranding them, and what you built so challenges reach you earlier — review norms, decision records, someone explicitly tasked with dissent.
saying these in an interview costs you the question
- Conceding to rank or persistence instead of to evidence
- Claiming open-mindedness without naming what specifically changed
- Every persuader in your stories is more senior than you
- Conceding privately while continuing to relitigate in the thread
- Never stating what the other person's argument actually was
- Taking the idea forward as your own once you accepted it
- Would the same argument have changed your mind coming from someone junior?This probes whether you update on evidence or on rank, so answer with behaviour rather than assertion. If your example already involves someone less senior, point at it. If not, name a concrete practice — asking for a reproduction regardless of who raises it — and give a second, briefer instance.
- What exactly convinced you?Have one sentence ready that names the specific artifact or observation: the benchmark number, the failing reproduction, the case your assumption did not cover. Vagueness here reads as a story where you conceded to social pressure and reconstructed a technical reason afterwards.
- How did you make sure they got the credit?Say where the credit was visible — the same thread, the commit, the design record, a mention to their manager — and whether they carried the work forward. Absorbing a good idea into your own proposal and shipping it under your name is the failure mode this probe hunts for.