Interview Gauntlet: Disagreeing with a Technical Decision¶
Category: Behavioral + Technical Hybrid Difficulty: L2-L3 Duration: 15-20 minutes Domains: Architecture, Leadership
Round 1: The Opening¶
Interviewer: "Describe a technical decision you disagreed with. What was the decision, and what was your alternative?"
Strong Answer:¶
"Our team lead decided to adopt Terraform Cloud for all infrastructure management, replacing our existing setup of Terraform with S3 backend and GitHub Actions for plan/apply. I disagreed with the timing and scope, not the direction. My concerns were: first, we were mid-migration of 15 services from EC2 to EKS — introducing a new Terraform workflow during that migration would add risk and slow us down. Second, Terraform Cloud's pricing at our scale (50+ workspaces, 20 engineers) would cost about $3,500/month for the Team tier, while our current setup cost about $50/month for the S3 bucket and GitHub Actions minutes. Third, the specific feature they wanted — collaborative plan reviews — could be achieved with Atlantis (open-source), which integrates with our existing GitHub PR workflow and costs nothing beyond the compute to run it. My alternative was: finish the EKS migration with our existing workflow, evaluate Atlantis as a free alternative to TFC, and revisit Terraform Cloud in 6 months when we could make the decision without the pressure of the migration."
Common Weak Answers:¶
- "I disagreed with using Kubernetes" or any very broad, one-sentence answer — Too abstract. The interviewer wants a specific story with specific technical trade-offs.
- "I disagreed and I was right." — The point isn't who was right. The interviewer is evaluating how you advocate, collaborate, and learn, not whether you win arguments.
- Vague on the technical details — If you can't explain the specific technical trade-offs in your disagreement, the story doesn't demonstrate depth.
Round 2: The Probe¶
Interviewer: "How did you advocate for your alternative? What evidence or data did you bring to the discussion?"
What the interviewer is testing: Whether the candidate can influence technical decisions through evidence and persuasion rather than position or volume.
Strong Answer:¶
"I wrote a one-page comparison document — not a 20-slide deck — with three sections: cost analysis, risk analysis, and timeline impact. For cost: a table showing Terraform Cloud Team tier at $3,500/month vs Atlantis on a t3.medium EC2 instance at $30/month vs our current GitHub Actions setup at ~$50/month. For risk: I identified that migrating to TFC during the EKS migration meant learning two new systems simultaneously (EKS and TFC), and I cited two previous incidents where we'd changed too many things at once and had trouble isolating which change caused the problem. For timeline: I estimated the TFC migration would take 2-3 weeks of one engineer's time for workspace setup, workflow migration, and team training — time we couldn't afford during the EKS migration. I presented this in our weekly architecture review, not in a 1:1 where it could seem like I was going behind the lead's back. I framed it as 'here are the trade-offs I see' rather than 'you're wrong.' I also acknowledged what TFC does better: managed state locking is more reliable than our S3+DynamoDB setup, and TFC's Sentinel policy engine has no open-source equivalent."
Trap Alert:¶
If the candidate bluffs here: The interviewer will ask for specifics about the comparison — "What was the actual Terraform Cloud pricing tier?" or "How does Atlantis handle concurrent plans?" Candidates who have actually done this analysis can answer these naturally. If you haven't done a TFC vs Atlantis comparison specifically, adapt the story to a comparison you have done. The interviewer is testing your process for advocacy, not your Terraform Cloud pricing knowledge.
Round 3: The Constraint¶
Interviewer: "The team lead heard your arguments and still chose Terraform Cloud. How did you respond?"
Strong Answer:¶
"I disagreed and committed. Once the decision was made, I didn't passive-aggressively undermine it or keep relitigating it in every standup. I asked the lead to document the decision and the reasoning (we use Architecture Decision Records — ADRs), so that if we needed to revisit it later, we had the context and rationale preserved. Then I actively helped with the migration. I volunteered to migrate two of my team's workspaces first, partly to support the decision and partly because I wanted to understand the experience firsthand — if my concerns were valid, I'd have concrete data rather than just predictions. As it turned out, the migration to TFC was smoother than I expected for the managed workspaces, but the cost concern was validated: within 3 months, we were at $4,200/month. The team lead and I revisited the decision at the 6-month mark (as I'd suggested), and we agreed to move most workspaces to Atlantis while keeping a few compliance-sensitive workspaces on TFC for Sentinel policies. So the final outcome was a hybrid approach that neither of us originally proposed — which is often how good technical decisions evolve."
The Senior Signal:¶
What separates a senior answer: "Disagree and commit" is the baseline expectation. The senior signal is: actively supporting the decision while maintaining the feedback loop. Volunteering to do the migration work, collecting real data about the experience, and proposing a revisit point shows both team player behavior and engineering rigor. The hybrid outcome — where the final answer was better than either original position — demonstrates that healthy disagreement leads to better outcomes than either consensus or authority alone.
Round 4: The Curveball¶
Interviewer: "Let's say the decision had gone badly — Terraform Cloud caused two production incidents during the migration. Your original objection was documented in the ADR. How do you handle the 'I told you so' moment?"
Strong Answer:¶
"I would absolutely not say 'I told you so' — that destroys trust and makes the team lead less likely to listen to dissent in the future, which is the opposite of what you want. Instead, I'd focus on the postmortem for each incident and ensure the root causes are identified and fixed. If the root causes are specific to TFC (like a TFC outage during a critical apply, or the workflow difference causing a misconfiguration), I'd let the evidence speak for itself in the postmortem. I'd frame any revisit conversation as 'what have we learned' rather than 'what did we get wrong.' 'Based on these two incidents, should we re-evaluate our Terraform workflow? Here are the options: stay with TFC and add guardrails for the specific failure modes, move to Atlantis, or a hybrid approach.' The goal is to make the next decision better, not to score points on the last decision. That said, I would privately check in with the team lead: 'How are you feeling about the TFC decision? I want to make sure we're learning from this without it becoming a blame exercise.' This builds the relationship for the next disagreement, which is more valuable than winning this one."
Trap Question Variant:¶
The right answer is restraint. Candidates who say "I'd bring up my ADR" are technically doing an "I told you so" with documentation. Candidates who say "I'd just ignore it" are missing the opportunity to learn and improve. The senior answer uses the incidents as learning opportunities without making the team lead feel attacked. This is emotional intelligence applied to technical leadership.
Round 5: The Synthesis¶
Interviewer: "How do you create an environment where technical disagreements are productive rather than political?"
Strong Answer:¶
"Three practices. First, separate the idea from the person. When evaluating technical options, use a structured format — we use Architecture Decision Records with a template that requires listing all considered alternatives and the trade-offs of each. This depersonalizes the discussion: we're evaluating options, not defending egos. When I present an alternative, I include the downsides of my own proposal. This signals that I'm trying to make the best decision, not win an argument. Second, make decisions reversible when possible. If the decision is 'try Terraform Cloud for 3 months and revisit,' the stakes are lower and people argue less. If the decision is 'migrate all infrastructure permanently with no revisit plan,' the stakes are high and people entrench. Most infrastructure decisions are more reversible than they seem — the cost of reverting is usually 2-3 weeks of engineering work, not a company-ending disaster. Third, celebrate being wrong. When I'm wrong about a prediction, I say so publicly: 'I was worried about TFC's cost and it turned out to be within budget. I was wrong about that, and I learned that the Team tier includes more runs than I estimated.' When people see that being wrong is acknowledged rather than punished, they're more willing to voice concerns early — which is when concerns are cheapest to address. The worst team culture is one where everyone agrees in the meeting and complains in private. The best team culture is one where people argue vigorously in the meeting and execute together afterward."
What This Sequence Tested:¶
| Round | Skill Tested |
|---|---|
| 1 | Articulating technical trade-offs in a specific disagreement |
| 2 | Evidence-based advocacy and persuasion |
| 3 | Disagree and commit — supporting decisions you didn't agree with |
| 4 | Emotional intelligence and avoiding destructive "I told you so" |
| 5 | Building productive disagreement culture on a team |