leadership · high

Hard Technical Trade-offs: Build-vs-Buy & Disagree-and-Commit

Asked about a hard technical decision, interviewers want to see a structured process, not a lucky guess. Start by laying out two or three real options (including 'do nothing') and the criteria you weighed — latency, cost, delivery time, risk, operational burden, maintainability, team familiarity — then make the trade-offs explicit and decide with data such as a spike, benchmark, or prototype rather than opinion; naming what you optimized for and what you sacrificed is the core signal, across common axes like build-vs-buy, simple-vs-flexible, performance-vs-readability, and consistency-vs-availability. Match your rigor to the stakes: two-way-door (reversible) decisions like a library choice or an internal API shape should be made fast — pick, learn, and change later — while one-way-door decisions that are hard to reverse, such as a public API contract, data model, storage engine, or security model, deserve heavy diligence, prototypes, and broad review; recognizing which kind you face avoids both reckless irreversible calls and analysis-paralysis on trivial ones. Once you have gathered input and decided, record it in an Architecture Decision Record capturing context, options, decision, and consequences so future engineers understand the why, then disagree-and-commit — if you advocated a different option but the team chose otherwise, commit fully and support it — own the outcome, set a trigger to revisit if assumptions change, and in the interview be candid about what you would do differently, because that combination of structure and humility is exactly the senior signal.

The code

/*  "Tell me about a hard technical decision you made."
    They want a STRUCTURED decision, not a lucky guess:
      1. Options      - list 2-3 real alternatives
      2. Criteria     - latency, cost, time, risk, maintainability
      3. Trade-offs   - make them explicit; decide with data
      4. Reversible?  - one-way vs two-way door (move fast on 2-way)
      5. Commit       - record it (ADR), disagree-and-commit, own it */

What this lesson walks through

1. 01Options + explicit criteria
2. 02Reversible vs irreversible decisions
3. 03Gotcha — no constraints, ignoring reversibility
4. 04Commit, record, and own it

A strong decision story shows a process, not a hunch. Lay out 2-3 REAL options (including 'do nothing'), then state the criteria you weighed — latency, cost, delivery time, risk, operational burden, maintainability, team familiarity. Make the trade-offs explicit and decide with data (a spike, a benchmark, a prototype) rather than opinion. Naming what you optimized for and what you sacrificed is the signal interviewers want.