Explaining trade-offs

Explaining trade-offs frames decisions by constraints, alternatives, consequences, reversibility, and evidence—instead of claiming one stack is always best. Interviewers want structured comparison, not zealotry.

					Constraint: team knows Postgres; 10x read spike expected
Option A: read replica — faster ship, replication lag risk
Option B: Redis cache — lower DB load, invalidation complexity
Pick A for v1; add cache if p95 read > 100ms in load test
				

| Element | Why it matters | |---------|----------------| | Constraints | Ground the comparison | | Alternatives | Show you considered more than one path | | Consequences | Name cost, risk, operability | | Reversibility | One-way doors deserve more caution |

On interviews: use a simple table or "A vs B" with a clear recommendation and falsification criteria.

Common pitfalls: straw-man alternatives; ignoring ops cost; no recommendation; hiding uncertainty.

The trade-off is thoroughness versus interview time—prioritize the dimensions that matter for the stated constraints.

Checklist:

• State constraints before options.
• Compare at least two viable paths.
• Recommend with consequences named.
• Say what measurement would change your mind.