Tell me about a time you convinced your team to change technical approach.
answer
- name the change and cost of inaction
- their objection, in their words
- evidence you built, not opinion
- small reversible pilot, exit criteria
- number after, and how it stuck
basics
~10 sTests whether you change minds with evidence rather than volume. Answer with one change you proposed, the objection you took seriously, a cheap reversible pilot, a measured result, and proof the change outlived you.
how to answer
6 beats- the change you wanted and what standing still costTwo or three sentences, no more — this and the next beat together are about a fifth of your airtime. State the current approach, the concrete pain it caused, and that you had no authority to simply decide.
- where the team actually stood before you pitchedSay what you learned by asking rather than assuming, and state the strongest objection in the objector's own words. A story in which nobody disagreed is a story with no influence in it.
- the evidence you built rather than arguedThis is the bulk of the answer, roughly sixty percent with the next beat. Describe the concrete artifact — a measurement of your own system, a prototype on real code, a side-by-side comparison — and the unglamorous work that earned you standing to propose anything.
- the small reversible bet you proposedGive the pilot's scope, its duration, and the kill condition you stated up front. Naming what would make you drop the idea is the single move that most reliably converts a skeptic, so do not skip it.
- what changed, measured, and what made it stickResult and reflection are the last quarter of your airtime. Give one before/after number, then name the mechanism that holds the change in place without you — a check, a template, a guide, a new owner.
- what you would do earlier next timeOne honest sentence. The best reflections are about sequence, not effort: asking about the pain before designing the fix, or bringing the skeptic in before the proposal went public.
your answer
5 story prompts- Pick a change you proposed to your own team, adopted or not, within the last two years.
- Choose one where a teammate actively resisted; a unanimous yes teaches the interviewer nothing.
- Write down the objection in the objector's words before you draft anything else.
- Have one before/after number ready, even a rough one you measured yourself.
- This can be your leading-without-authority story, re-angled onto how you changed minds.
draft and rehearse your own answer in a learn session
go deeper
This probes influence without authority: whether you can move peers who are free to ignore you. The interviewer is scoring evidence-building over assertion, willingness to hear an objection on its own terms, and ownership of the follow-through. A strong answer proves you can change how a team works and make the change outlast your attention.
I help maintain an open-source library, and our browser test suite had grown to forty-one minutes on every pull request. Contributors were waiting on it, and people had started merging on a mostly-green run, which is how two regressions got out in one release. I wanted us on a different runner with parallel workers. But there were eleven regular contributors with habits built around the old one, and two of them had written the harness. So I did not open with a proposal. I asked in the contributors channel what people hated most about CI, and the answer was not runtime at all — it was flakiness. That reframed the whole pitch. I spent a weekend porting the forty slowest specs onto the new runner in a branch, with a side-by-side job so anyone could compare their own pull request. Then I proposed a nine-day pilot: the new runner runs alongside the old one, non-blocking, and if flaky reruns are not down by the end, I delete the branch. I wrote that kill condition into the first line of the RFC, and I sent it to the original harness author privately before posting it. The pilot ended with suite runtime at twelve minutes and reruns down from nineteen a week to three. We cut over at the next release. To keep it from drifting back I added the runtime as a required check and wrote the porting guide so the next contributor would not have to ask me. What I would do differently is ask about the pain before designing the fix, not after.
The signal is in the reframe: the pitch changed after asking, which is what separates influence from advocacy. The private review of the harness author, the stated kill condition, and the required check as the durability mechanism carry the rest. Removing the number or the objector would downlevel it to an opinion story.
I was one of two release managers on an open-source project where the test suite had become the reason contributions stalled: sixty-three minutes at the median, and roughly a fifth of runs failed for reasons unrelated to the change. What I wanted — sharding plus a quarantine policy that auto-skips a spec after it flakes twice — was unpopular, because quarantine sounds like turning tests off. I did not argue that in a thread. I pulled six weeks of CI history and published a small dashboard showing which specs cost us the most reruns; the top seven accounted for most of the pain. That moved the conversation from principle to triage. Then I went to the two reviewers whose objection carried the most weight — they had blocked a similar idea before — and asked them to write the quarantine rules with me rather than review mine. Their condition was that every quarantined spec files an issue with a named owner and expires in three weeks. That condition made the policy better, and it made it theirs. We piloted on one directory, reversible in a single revert. Median suite runtime came down to nineteen minutes and the rerun rate fell under four percent. Quarantine never held more than five specs at once, because the expiry forced the fixes. The part I actually care about is what happened after I stepped back from releases. The policy lives in the contributing guide, a bot enforces the expiry, and one of the two people who opposed it now maintains it.
Co-authorship instead of persuasion is the engine here — handing the rules to the objectors and accepting their condition — plus durability evidence after the speaker left the seat. Publishing data to reframe a principled objection as triage is the senior move. Losing the after-I-stepped-back paragraph would downlevel it.
Scope your story to something you owned: a helper, a test pattern, a lint rule in your own area. Show that you asked before you advocated, and that you accepted a no gracefully when the answer was no.
This is your home rung. Carry a change across a feature or a repo: build the prototype, write the short proposal, name who objected and what you did about it, and show one before/after number.
Expect to be judged on durability, not the decision. Show how you sequenced the rollout, who you brought in as a co-author, what the change cost while it was in flight, and what enforces it now that you are not watching.
Talk about making the decision reachable rather than winning it: a forum, a written standard with an opt-out, a scoreboard, and adoption spreading peer to peer instead of through you.
saying these in an interview costs you the question
- Winning by escalation or seniority rather than by evidence
- No named objection from anyone who actually disagreed
- A proposal with no cost, risk or rollback ever discussed
- Result stated as "everyone liked it" with nothing measured
- Trashing the old approach or the person who chose it
- Adopted once, with no mention of whether it stuck
- Who disagreed the longest, and what changed their mind?Name a real person by role and steelman their position before you say how it resolved. The strongest version is that their objection improved your proposal — a condition they set that you adopted. Avoid "they came around once they saw the data" with no detail; say which number, and whether they still hold a reservation.
- What would you have done if the pilot had failed?Answer with the exit condition you set in advance, not a hypothetical you invented afterwards. Say what the rollback actually cost and who would have decided. If you had no exit condition, say so plainly and name it as the thing you now write down first.
- Is that change still in place today?Interviewers use this to separate a persuasive week from a durable outcome. Point at the mechanism — a template, a check, a guide, an owner — rather than saying yes. If it decayed after you left, say why; an honest post-mortem on your own change reads as senior, not as failure.
- What did the change cost the team while it was in flight?Have a real cost ready: reviewer time, a slower week, a period of running both paths. Candidates who claim a change was free sound like they never ran one. Then say how you kept the cost bounded and who you warned in advance.
## One campaign story, several wordings This prompt family arrives in several wordings, and they all want the same tape: - "How did you get buy-in for that?", - "Tell me about a time you drove adoption of a new tool or standard", - "Describe a technical decision you influenced but did not own", and - the negatively framed cousin "Tell me about a time you failed to convince people". Prepare **one campaign story** well and you can answer all four by changing which beat you dwell on. ## Persuasion or pressure What the interviewer is actually testing is whether your default move is **persuasion or pressure**. In most engineering orgs the people whose approach you want to change do not report to you, and they have their own backlog and their own scar tissue. So the evaluator listens for four things: 1. did you understand the objection before you argued against it, 2. did you make the change cheap to try, 3. did you measure anything, 4. and did the change survive contact with time. ## Weak versus strong A **weak answer** sounds like this: "Our tests were slow, so I researched a better runner and presented it at a team meeting, and everyone agreed it was a good idea, so we switched." Nothing in that sentence is falsifiable. There is no resistance, no cost, no number, and no evidence the speaker did anything harder than have an opinion. A **strong answer** of the same story: - names what people feared losing, - shows a prototype that made the abstract concrete, - proposes a bounded pilot with a stated kill condition, - and ends with a mechanism — a template, a bot, a documented guide — that keeps the change in place when attention moves on. ## Evidence types Evidence types, roughly in ascending order of persuasive force: 1. an argument, 2. a benchmark someone else published, 3. a measurement of your own system, 4. a working prototype on your own code, 5. and a pilot the skeptic ran themselves. Most candidates stop at the second rung. The candidates who get credit for influence almost always did something unglamorous and concrete — ported the ugliest module, sat in someone else's triage, fixed a bug in the code they were criticizing — before they made the ask. Say that part out loud; it is the part that reads as **earned standing** rather than assertion. ## Coalition matters as much as evidence Two moves recur in strong answers. 1. First, taking the loudest objector to the proposal before it goes public and asking them to set a condition — people defend what they co-authored. 2. Second, letting someone other than you present the result, so adoption looks like the team's decision rather than your campaign. Neither is manipulation as long as you are honest about the tradeoffs; both are the difference between a change that lands and one that gets relitigated every quarter. ## How the bar shifts The bar shifts by level in a predictable way. - At **mid-level** the interviewer is satisfied by a single successful campaign with a measured outcome and one named skeptic. - At **senior** they want sequencing and durability: why this pilot first, what you did about the people who never agreed, what enforces the change now. - At **staff and above** they want you to be less visible in your own story — you built a forum, a written standard, an opt-out that made joining safe, and a scoreboard, and then the adoption happened without you in the room. If your story at that level has you personally convincing each team, that is a scaling problem the interviewer will notice. ## Two traps 1. The first is the **triumphal ending**, where everyone agrees and the change is permanent and nothing cost anything; it reads as fiction. Name the holdout who never came around, and be fair about why. 2. The second is quietly telling a **conflict story** instead of an influence story — if the emotional center is a disagreement with one person, you are answering a different question. Here the arc is a campaign across several people over weeks, and the tone should be patient rather than combative.