Prompt and Applicable Context
Tell me about a time you disagreed with a technical decision made by a teammate, lead, or cross-functional partner. Explain the competing options, the actual risk, how you challenged the proposal, who had final decision authority, and what you did after the call was made.
This behavioral question is common for software engineers and also applies to data, product, and engineering management roles. The interviewer is not merely asking which technology was better. The stronger signal is whether you can turn an opinion into a testable judgment under pressure, competing incentives, or a power difference while preserving a functional working relationship.
Use a real experience. You may anonymize the company, project, and colleague, but do not inflate an ordinary code-review comment into a major conflict or rewrite who made the final decision. STAR provides the narrative. The Action section must also expose the goal, evidence, decision criteria, decision rights, and your execution after the decision.
What the Interviewer Evaluates
First, was the disagreement real and consequential? A useful story has at least two viable options, with each side protecting a legitimate concern such as delivery time, reliability, maintenance cost, or compliance risk. If the other person was obviously foolish, you selected an easy opponent rather than demonstrating mature conflict.
Second, how did you challenge the decision? A strong answer goes beyond “I used data to persuade the team.” It identifies the evidence, the fact that could have overturned your own view, and whether you could state the other side's strongest concern accurately. That distinction separates truth-seeking from winning.
Third, did the decision process have boundaries? Name who advised, who owned the outcome, and when the decision had to be made. Debate cannot continue indefinitely, and authority should not suppress material evidence. If the final call went against you, stopping the campaign and becoming a reliable executor is a central signal in this question.
Finally, the interviewer tests your limits. Committing after a decision is not unconditional obedience. If new evidence crosses a pre-agreed safety, legal, data-integrity, or professional-ethics boundary, document the risk and escalate through the proper channel. A mature answer includes both commitment and a stop line.
Questions to Clarify Before Answering
- Does the interviewer want a technical disagreement or any workplace conflict? Prefer a story with a real technical tradeoff. For a broader prompt, a scope or cross-team priority dispute can work if it still ends in a clear decision.
- Which authority did you have? Separate recommendation, decision, and execution authority. Not owning the final call does not weaken the story; influencing sound judgment without formal authority can be the stronger example.
- What counts as a result? Production metrics are useful, but so are reaching a timely decision, ending circular debate, validating an assumption, or improving future reviews. Do not invent revenue or performance figures to fill a blank.
- Must your proposal win? No. A rejected proposal can still demonstrate high-quality dissent, willingness to update, and reliable execution. It often avoids the polished “I am always right” story.
- When should you not simply commit? Escalate security vulnerabilities, unlawful requests, threats to data integrity, or serious ethical issues. Describe the evidence, impact, and escalation path rather than turning an ordinary preference into a red line.
30-Second Answer Framework
“During [project and deadline], [decision owner] favored [option A]. I was concerned it would cause [specific risk], so I recommended [option B]. I first confirmed that our shared goal was [goal] and restated their concern about [constraint]. I then compared the options against [criteria] using [design record, experiment, or historical evidence]. [Decision owner] ultimately chose [final option]; I owned [execution step] and we agreed on [threshold for reopening the decision]. The result was [verifiable result], and I learned [specific correction].”
This opening establishes the disagreement, accountability, and ending. Keep the full answer to roughly two or three minutes. Spend most of that time on how you tested the judgment, responded to disconfirming evidence, and acted after the call.
Step-by-Step Deep Answer
Choose the story carefully. A suitable example meets four conditions: the disagreement affected a real outcome, both positions had a reasonable basis, you took observable action, and the process reached an explicit decision. A style preference, an objection you never voiced, or a manager ending discussion with no follow-through is too thin.
Keep Situation and Task brief. Establish the objective, deadline, your responsibility, the other person's responsibility, and the competing options. Do not spend a minute listing the stack. Retain only the technical detail needed for an interviewer outside that specialty to understand the risk.
Build the Action in this order:
- Align on the goal: State what the team was jointly protecting. Without a shared goal, each option is optimizing a different problem.
- Restate the objection: Describe the strongest version of the other person's constraint in terms they would accept. This proves that you listened.
- Separate facts from assumptions: Which inputs were production evidence, customer commitments, or hard deadlines? Which were estimates? Subject your own preference to the same test.
- Agree on criteria: Set the weight of delivery, reliability, long-term cost, reversibility, and other constraints before seeing the conclusion. Do not move the bar afterward.
- Run the smallest useful test: Use a time-boxed prototype, design review, incident history, or limited experiment. It should answer the question most likely to change the decision.
- Name decision rights: Who makes the call, and by when? Any security or compliance veto must also be explicit.
- Execute after the call: Restate the decision, record unresolved risks, and own a concrete task. Reopen the debate only when new evidence crosses an agreed threshold.
Do not default to compromise. Combining two incompatible architectures may preserve both cost structures. Prefer selecting against shared criteria or narrowing the commitment so the decisive assumption can be tested. If a hybrid is chosen, explain the independent constraint it solves instead of presenting it as a way for everyone to win a little.
The Result should answer at least three questions: what the decision produced, how you and the other person worked together afterward, and which belief changed. You do not need to prove you won. “My rollback concern was valid, but I had underestimated the cost of certifying two paths” demonstrates more judgment than “the outcome proved I was right.”
During practice, ask someone to press three points: “What evidence would have changed your mind?” “Who had the final call?” and “What did you do when your proposal was not selected?” The answers you cannot defend reveal the gaps. Verify the definition of every number and remove precision you cannot trace.
High-Quality Sample Answer
The following is a fictional example that demonstrates structure. Every project detail and number is placeholder data that must be replaced; do not present it as personal experience.
“Twelve weeks before a renewal audit (placeholder; replace it), the technical lead proposed a complete rewrite of our billing-rules service. I owned the migration plan and favored extracting rules gradually because the team did not fully understand the legacy edge cases. I worried that a single cutover would increase the failure surface. The lead worried that keeping two active rule paths would add audit and maintenance cost. He owned the final call, while I was responsible for a written migration-risk recommendation.
I scheduled a one-on-one and wrote our shared objective as ‘one verifiable source of rules before the audit deadline.’ I asked him to confirm that I had represented the dual-path cost accurately. I then wrote a one-page decision record comparing a complete rewrite with incremental migration on delivery time, validation scope, recoverability, and long-term maintenance. I initially weighted recoverability most heavily and proposed completing the first migration slice in four weeks (placeholder; replace it).
The lead pointed out that I had not verified the audit scope. I invited a compliance partner to the review and ran a two-day minimum test with two engineers (headcount and duration are placeholders; replace them). Compliance confirmed that two active rule engines would require two validation matrices. The prototype also put the complete rewrite at about nine weeks rather than the twelve we had first feared (placeholders; replace them). That evidence weakened my recommendation. The lead chose the complete rewrite. I explicitly accepted the call and took ownership of shadow comparisons and the cutover checklist.
During execution, I did not keep lobbying for incremental migration outside the review. I converted my remaining concern about rounding differences into a stop line: if results diverged by more than 0.2% in any 30-minute window, we would pause the cutover for the lead to review (placeholders; replace them). Shadow comparison found two rounding edge cases. After the fixes, the team launched by the audit deadline and had no severity-one incident in the first 30 days (count and duration are placeholders; replace them).
The experience showed that my rollback concern was useful, but I had initially underestimated compliance-validation cost. Since then, before challenging an architecture decision, I confirm the criteria, external vetoes, and final owner. That lets me dissent fully before the call and help the team move in one direction afterward.”
When substituting your own experience, discard the rewrite, audit, and numbers. Recover the actual options and evidence from design documents, tickets, meeting notes, and monitoring records. If the result is qualitative, identify who observed the improvement and what behavior changed rather than adding an attractive percentage.
Common Mistakes
- Making the other person technically incompetent → The story has no real tradeoff and shows little respect → Explain the legitimate goal they protected and how it changed your analysis.
- Saying only “I persuaded them with data” → The evidence may be irrelevant, and your view may be unfalsifiable → Name the source, comparison criteria, and evidence that would change your mind.
- Using rank to end the debate → The meeting ends without testing the concern → Even with decision authority, record the dissent, rationale, and review trigger.
- Always telling a story you won → It sounds polished by hindsight and does not prove you can accept a call → Prefer an example in which you updated your view or your first choice was not selected.
- Continuing to lobby after the call → The team pays for two directions and execution friction → Agree on evidence that reopens the decision; until then, execute fully.
- Combining options to keep the peace → A hybrid may add both kinds of complexity and maintenance → Choose against prior criteria; require any hybrid to solve an independent constraint.
- Treating commitment as absolute obedience → This ignores safety, law, data, and ethical limits → Name the stop line, documentation, and formal escalation path.
- Using “we” throughout → The interviewer cannot identify your influence → Separate what you proposed and tested, what the owner approved, and what the team executed.
- Inventing exact results → The answer breaks when metric definitions are probed → Use real records; without numbers, give a concrete and verifiable qualitative result.
Follow-Up Questions and Responses
Follow-up 1: What would you do if events later proved you right?
Address the impact first and skip “I told you so.” Identify the new evidence that crossed the agreed threshold, reopen the decision through the proper channel, and help own the repair. In the review, examine the original evidence and process instead of converting the result into personal superiority.
Follow-up 2: What if the final decision went against your recommendation?
Explain how you confirmed the call, recorded the residual risk, and accepted a concrete execution task. Commitment does not require pretending to agree. It means that without material new evidence, you do not create a second direction through delay or private lobbying.
Follow-up 3: When should you escalate above the decision owner?
Use the organizational path when the risk concerns safety, law, data integrity, or serious professional ethics and the normal owner has not acted on verifiable evidence. Write the facts, impact, urgency, and prior communication first. An ordinary architecture preference or personal frustration is not an emergency escalation.
Follow-up 4: How can you challenge a decision when no data exists?
Do not manufacture certainty. Compare known constraints, relevant precedents, reversibility, and worst-case impact, then design the smallest useful test. If critical evidence still cannot arrive before the deadline, state the assumptions and confidence level and let the person accountable for the outcome decide.
Follow-up 5: How do you disagree with someone more senior?
Speak in terms of the shared goal and decision criteria. Check privately whether you are missing context, then present the evidence in the appropriate forum. Seniority changes decision rights; it does not make facts disappear. Keep the tone direct and the content testable.
Follow-up 6: What if the disagreement became personal conflict?
Separate the technical judgment from the behavior problem. Stop labeling motives, restate the other view, and check for misunderstanding. A neutral facilitator may help restore discussion rules. If the behavior involves insults, discrimination, or retaliation, document facts and use the formal people process rather than hiding it inside a technical compromise.