Coaching Senior Engineers Who Disagree
Final Prep · People Management — how to lead strong, opinionated seniors who push back on your direction, and turn that friction into better decisions without losing them.
This question tests whether you can lead people who are, in their domain, better than you — and whether you know that leading them is not the same as out-arguing them. A senior engineer who disagrees is not a discipline problem; they are usually your best early-warning system. The interviewer wants to see that you can earn technical respect, genuinely seek to understand before you persuade, argue from data and shared goals rather than your title, give autonomy on the how, and know the difference between a call you defer on and a line you hold. The shape of the answer is CARL — Context, Actions, Results, Learnings — with most of your words on the actions only you could have taken.
What this question is really testing
On the surface it is a conflict question. Underneath, it is a question about secure leadership: can you be challenged by someone strong without either caving to avoid conflict or pulling rank to win it? Both failure modes are disqualifying at the senior level. They are listening for someone who treats a talented dissenter as a partner in getting to the right answer, and who can still make and own the call when the disagreement doesn’t resolve.
How to answer- Earn technical respect first. Authority over a senior engineer is granted, not assigned. Show you did the reading, understood the system, and engaged with the substance — credibility is what makes the rest of the conversation possible.
- Seek to understand before you persuade. Ask what they see that you don’t. Strong seniors usually push back because they have context you lack; assume that first, and you often find they are right.
- Anchor on shared goals and data. Move the debate off “my opinion vs yours” and onto the outcome you both own — latency, reliability, cost, the deadline — and let evidence, not seniority, arbitrate.
- Give autonomy on the how. Be firm on the what and the why; give them room on the how. Ownership of the path is what keeps a strong engineer engaged and accountable.
- Disagree and commit — and know when to defer vs hold. When they change your mind, say so plainly. When the call is genuinely yours and reversible, often let them run their way and learn. Hold the line only where the stakes are one-way doors: safety, privacy, data integrity, a hard external commitment.
- Security — challenged by a strong person without caving or pulling rank.
- Genuine curiosity about the dissenter’s view, not performative listening.
- Data and shared goals as the arbiter, not hierarchy.
- Autonomy on the how, with clear ownership of the outcome.
- A crisp sense of when to defer (reversible, their call) vs hold (one-way door).
A worked example (CARL)
Context. On Ads Events Infra I owned the storage layer for the events pipeline — the write path that ingests every ad impression and conversion event before it is aggregated for billing and measurement. We were hitting a scaling wall on write throughput during traffic peaks, and I proposed we move a hot dataset onto a new tiered-storage design I’d been sketching. My most senior engineer — the person who had built and operated that path for three years — pushed back hard in the design review, in front of the team. His position: the tiering would help throughput but would blow our read-tail latency for the billing aggregation jobs, which had a hard freshness SLA. He thought we should attack write amplification at the compaction layer instead.
Actions. My first move was to not defend the proposal. I could feel the pull to protect my idea in front of the room, and I deliberately didn’t — I said this was exactly the objection we needed to work through and asked him to walk us through the read-path math. As he did, it became clear he had operational context I didn’t: the aggregation jobs had a fan-out read pattern that my design would have turned into a tail-latency problem, and he’d seen a near-identical failure mode two years earlier. So I reframed the conversation away from “tiering vs compaction” and onto the two things we both actually owned — write throughput at peak and read freshness for billing — and proposed we settle it with data rather than argument. I asked him to own a small design spike: prototype both approaches against a shadow-traffic replay and measure write throughput and read-tail latency for each. Crucially, I gave him the how — his prototype, his methodology, his call on the compaction variant — and I held only the constraint that whatever we shipped could not regress the billing freshness SLA, because that was a one-way door with finance and external reporting on the other side. I also made a point of telling him, in our 1:1, that raising the objection in the review was the right call and I wanted more of it, not less — I didn’t want him to read my reframing as a loss. The spike ran for about two weeks. It showed his compaction fix recovered most of the throughput with no read-tail regression, but that a hybrid — his compaction change plus a narrower version of my tiering on genuinely cold data only — beat both on cost without touching the SLA. Neither of us had proposed the hybrid at the start; it fell out of the data. I changed my mind on the aggressive tiering and said so explicitly to the team, and we committed to the hybrid together.
Results. The hybrid design shipped over the next quarter. Peak write throughput headroom roughly doubled, the billing freshness SLA held with margin to spare, and we took out a chunk of storage cost by tiering only the genuinely cold data. The senior engineer became the DRI for the whole effort and later drove the follow-on that generalized it to two more datasets. Just as important, the review culture on the team shifted — people saw that pushing back on the manager’s proposal got you ownership, not a black mark.
Learnings. The best thing I did was refuse to win the argument. If I had defended the original design on authority, I’d have shipped a billing incident and taught my strongest engineer to stop objecting. The durable lesson: with strong seniors, be rigid on the outcome and the non-negotiable constraints, and completely open on the path — and let data, not the org chart, break the tie.
Common follow-ups
What if you’re convinced you’re right and they still won’t commit?
How to answer- Separate reversible from one-way. If the call is reversible, strongly consider letting them run it their way — being right is cheaper to prove than to argue, and they own the result either way.
- If it’s a one-way door, make the call and own it. Explain the reasoning, acknowledge their view explicitly, and ask for disagree-and-commit — then take full accountability if it goes wrong.
- Set a checkpoint. Agree on the metric and the date you’ll revisit, so “commit” doesn’t mean “forever” — it means “until the data says otherwise.”
- Watch for a real pattern. One firm call is fine; chronic non-commitment is a separate conversation about how the team makes decisions.
How do you build credibility with a senior engineer who’s deeper than you in the domain?
How to answer- Don’t fake depth. Be honest about where they know more; seniors smell posturing instantly, and admitting the gap buys more trust than bluffing.
- Add value at a different altitude. Bring cross-team context, prioritization, unblocking, and clarity on the goal — leverage they can’t generate from inside the code.
- Do the homework anyway. Learn enough of the system to ask sharp questions and engage with the substance; that’s what earns technical respect.
- Amplify them. Sponsor their work upward and give them room to lead — credibility with a senior often comes from making them more successful, not from matching their depth.
How do you disagree with a senior in front of the team without undermining them?
How to answer- Critique the idea, protect the person. Keep it about the design and the tradeoff, never about their judgment or track record.
- Frame it as a shared problem. “How do we get both throughput and freshness?” invites collaboration; “that won’t work” invites a defense.
- Take sharp disagreements offline. Surface the tension in the room, but resolve a genuinely hard or personal one in a 1:1, not in front of an audience.
- Give them the last credible word. Let them refine or own the resolution so the team sees a senior respected, not overruled.
When does pushback become a performance or attitude problem?
How to answer- Distinguish dissent from obstruction. Healthy pushback ends in commit; the problem pattern is re-litigating decided calls or blocking without proposing an alternative.
- Name it directly and privately. Give specific examples in a 1:1, tie it to team impact and velocity, and be clear about the expectation.
- Check for a root cause. Chronic friction often signals a misaligned goal, an unaddressed grievance, or a growth need — diagnose before you discipline.
- Hold the standard. If it persists after clear feedback, it moves into the performance track like any other expectation — seniority isn’t an exemption.
- 1:1 notes — pull the running record of a specific disagreement, how it resolved, and the trust it built or repaired.
- Design-review docs and Phabricator — pull the design thread or review comments where the pushback happened and where the data settled it.
- GSD — pull the project the disagreement was about, and show the senior became the DRI on the resolution.
- Perf / calibration records — pull evidence that the engineer you coached grew in scope or rating afterward.
- Eng-satisfaction surveys — pull the manager and team-health signal that shows strong people felt heard, not steamrolled.