Tell me about a time a project or technical initiative you championed failed. What did you learn?

In Simple Words: Choose a genuine failure, take full responsibility, explain how you killed the project decisively once data contradicted assumptions, and detail the systemic lessons learned.

The STAR Response:

• Situation: I advocated for migrating our real-time notification service to a new graph database to model complex user permission hierarchies and organizational relationship graphs.
• Task: Prove that the graph database would reduce query latency for deeply nested permission evaluations.
• Action:
  1. Built a prototype and ingested production-like datasets containing 500,000 nodes and 4 million edges.
  2. When benchmarking high-concurrency write workloads (user permission updates), write latency spiked by 300% due to distributed lock contention across graph partitions.
  3. Rather than doubling down or letting sunk cost bias cloud our judgment, I presented the benchmark data honestly to leadership and recommended aborting the migration.
  4. Instead, optimized our existing PostgreSQL schema using Recursive Common Table Expressions (CTEs) and an in-memory Redis cache.
• Result: Saved the company over 3 months of wasted engineering effort and $40,000 in dedicated database licensing fees. I learned never to adopt complex niche databases before thoroughly benchmarking write paths under concurrent production loads.

Practical Script & Summary Template

### Sunk Cost Bias Elimination Playbook:
- Establish quantitative "Kill Criteria" before beginning any technical trial.
- Value speed of invalidating a hypothesis just as much as proving one.
- Share negative results openly across the engineering team to prevent others from making the same mistake.