Why I Always Ask About Failed Projects, Not Just Wins

STRONG ANSWER — FIRST 90 SECONDS:

Interviewer: "Tell me about a project that
failed."

Candidate: "Sure. The warehouse migration
stalled for a quarter — and it was my
estimate that caused it.

The impact: about $40K in extended cloud
spend, and the reporting team went back to
manual pulls for three months. That's the part
I'm least proud of.

The root cause: I estimated 4M rows in the
orders table, but it had 40M. The backfill
took 8 hours instead of 1, so we blew the
nightly window every night. We'd restart,
blow the window again, and repeat. The tool
was fine; my estimate was wrong by 10x.

The fix: we split the backfill into chunks by
month and ran it over a weekend — 8 hours
became 8 chunks of 1 hour.

The prevention: I added a row-count check to
the planning phase. Every estimate is now
validated against a COUNT(*) before we commit
a timeline. It's a 30-second query that would
have caught this.

The cost: the chunked backfill added a weekend
of work — I worked Saturday. I accepted that
because a quarter of manual pulls was worse.

The lesson: I now validate every estimate
against the data before I promise a timeline.
The 10x miss was avoidable."

What the interviewer thinks in 90 seconds:
- "They named the project and the impact." ✅
- "They named the root cause: a 10x
  estimate error." ✅
- "They named the fix and the prevention." ✅
- "They named the cost: a weekend." ✅
- "They understand their own work." ✅

Signal: strong. The rest of the interview
confirms it.

WEAK ANSWER — FIRST 90 SECONDS:

Interviewer: "Tell me about a project that
failed."

Candidate: "Yeah, there was a project that
didn't really work out. It was a while ago.
We ended up changing direction, so it wasn't
really a failure. The stakeholders were
happy with what we delivered."

What the interviewer thinks in 90 seconds:
- "No project named." ❌
- "No impact — did anyone notice?" ❌
- "No root cause — 'changed direction' is
  not a cause." ❌
- "No fix, no prevention." ❌
- "They didn't understand the project well
  enough to remember it." ❌
- "I'll ask a follow-up, but I already doubt
  the wins." ⚠️

What happens next:
- The interviewer asks "What was the project?"
- The candidate says "I don't remember the
  name."
- The interviewer asks "What went wrong?"
- The candidate says "I think the scope
  changed."

Signal: weak. The candidate's wins now look
less impressive, because they can't explain
a failure.

Why it failed:
❌ No specific project
❌ No impact named
❌ No root cause
❌ No fix or prevention
❌ No lesson
❌ The first 90 seconds signaled "I ran a
  project," not "I own a project"

ROOT CAUSE ANSWER — WHAT DECIDES:

Interviewer: "How did you find the root
cause?"

WHAT THE CANDIDATE SAYS:
"I found it by timing the backfill and
comparing it to my estimate.

Step one: I timed the first backfill run. It
took 8 hours, not 1. That was the first
signal my estimate was wrong.

Step two: I counted the rows. `SELECT
COUNT(*)` on the orders table returned 40M,
not 4M. I'd missed a zero when I looked at
the staging data.

Step three: I checked the math. 40M rows at
the observed throughput — about 1,400 rows a
second — is 8 hours. The tool was doing
exactly what it should. My estimate was the
problem.

The root cause: my estimate, not the
backfill. I'd looked at a sample table with
400K rows and assumed the production table
was 10x that. It was 100x.

The fix: split the backfill by month — 8
hours became 8 chunks of 1 hour — and ran it
over a weekend.

The trade-off: chunking adds complexity — 8
runs instead of 1, each with its own
checkpoint. I accepted that because 8 chunks
of 1 hour fit the nightly window, and 1 run
of 8 hours didn't.

The lesson: I now validate every estimate
against the data before I commit a timeline.
A 30-second COUNT(*) would have caught the
10x miss."

What the interviewer thinks:
- "They timed the first run." ✅
- "They counted the rows." ✅
- "The math is concrete: 40M at 1,400/s." ✅
- "The root cause is an estimate error." ✅
- "The fix and the cost are named." ✅

Signal: confirmed judgment.

Why it decides:
✅ Timing narrowed the scope
✅ Row count is concrete: 40M
✅ The math is specific
✅ Root cause is an estimate error
✅ The fix cost is named

PREVENTION ANSWER — WHAT DECIDES:

Interviewer: "How did you make sure it
didn't happen again?"

WHAT THE CANDIDATE SAYS:
"Three layers, and each catches a different
failure.

Layer one: a row-count check in the planning
phase. Every estimate is validated against a
`COUNT(*)` on the production table before we
commit a timeline. It's a 30-second query,
and it would have caught the 10x miss.

Layer two: a timing check in the first run.
We run the backfill on a small slice first —
say, one day of data — and extrapolate. If
the extrapolated time blows the window, we
stop and re-plan before the full run.

Layer three: a chunked backfill by default.
Any backfill over 4 hours is split by month,
so a single failure doesn't cost the whole
window. Each chunk has its own checkpoint.

The cost: the row-count check adds 30
seconds, the slice run adds 15 minutes, and
chunking adds orchestration complexity — 8
runs instead of 1. I accepted all three
because a quarter of failed migrations is
worse than a few minutes of planning.

The result: we've run 6 migrations since
with zero blown windows. The slice run caught
one 3x estimate miss before it mattered.

The lesson: estimates are guesses until
they're validated. A COUNT(*) and a slice
run turn a guess into a measurement."

What the interviewer thinks:
- "Three layers, each with a purpose." ✅
- "The checks target different failures." ✅
- "The cost is quantified: 30 seconds, 15
  minutes." ✅
- "The slice run has evidence: one catch." ✅
- "The lesson is a reusable rule." ✅

Signal: confirmed judgment.

Why it decides:
✅ Three layers, not one
✅ Each layer targets a failure class
✅ The cost is quantified
✅ The slice run has evidence
✅ The lesson is a reusable rule

ADOPTION FAILURE — STRONG VS. WEAK SIGNAL:

Scenario: "Tell me about a project that
failed after launch."

WEAK SIGNAL:
"The dashboard launched successfully. The
stakeholders were happy. We got good
feedback."
What the interviewer thinks:
- "Launched isn't the same as adopted."
- "No usage numbers."
- Signal: weak.

STRONG SIGNAL:
"The dashboard launched on time and nobody
used it. That's the failure — the launch was
the easy part.

The impact: we spent a quarter building it.
Only 2 of the 12 stakeholders opened it in
the first month. The manual process it was
supposed to replace kept running.

The root cause: I built what they asked for,
not what they needed. They asked for
'drill-downs and filters'; they needed a
weekly number they could trust. The
drill-downs were a distraction — 8 of the 12
opened the dashboard once and went back to
the spreadsheet.

The fix: I sat with 3 of the non-users for
30 minutes each. They all wanted the same
thing — a weekly number with a timestamp and
a diff from last week. I rebuilt the landing
page around that.

The prevention: I added a usage metric to
every dashboard I build — weekly active
users, and a "last opened" column per
stakeholder. If adoption is under 50% in the
first month, I schedule a 30-minute session
with each non-user.

The cost: the usage metric adds a small
tracking call to the dashboard — about 10
lines. I accepted that because a dashboard
nobody uses is a quarter of wasted work.

The lesson: a dashboard's success isn't
launch; it's adoption. I now define the
adoption target before I build."

What the interviewer thinks:
- "They named the project and the real
  failure: adoption." ✅
- "The impact is specific: 2 of 12." ✅
- "The root cause is 'built what they asked
  for, not what they needed.'" ✅
- "The fix is specific: the weekly number." ✅
- "The prevention is a usage metric." ✅
- Signal: confirmed judgment.

Why it decides:
✅ Real failure named: adoption
✅ Impact is specific: 2 of 12
✅ Root cause is honest
✅ Fix is specific
✅ Prevention is a usage metric

INTERVIEW FOLLOW-UP — STRONG VS. WEAK
SIGNAL:

Scenario: "How did you know the fix worked?"

WEAK SIGNAL:
"I rebuilt it and people started using it.
The feedback was positive."
What the interviewer thinks:
- "Started using it" — how many, how often?"
- "Positive feedback" is not a number.
- Signal: weak.

STRONG SIGNAL:
"Three checks, and I can show the numbers.

Check one: weekly active users. Before the
fix, 2 of 12 stakeholders opened it in a
month. After the fix, 9 of 12 opened it
weekly. I tracked it for 6 weeks to make
sure it wasn't a novelty bump — it held.

Check two: the manual process. The
spreadsheet the dashboard was supposed to
replace had a shared-edit log. Before the
fix, it had 15 edits a week. After, it dropped
to 2 — both from the one stakeholder who
still prefers the spreadsheet.

Check three: the timestamp. The weekly number
now has a "last refreshed" timestamp, and I
checked that stakeholders are looking at the
current week, not last week's — 9 of 12
opened within 24 hours of the refresh.

The cost: I added 30 minutes a week of
tracking — checking the usage and the
spreadsheet log. I accepted that because
adoption is the job, and I'd rather track it
than guess.

The lesson: match the success metric to the
failure. The failure was adoption, so the
metric is weekly active users, not "launched
on time."

The stakeholder I didn't win: 1 of 12 still
uses the spreadsheet. I flagged it to the
product owner as a data-format issue, not a
dashboard issue — they want a CSV export, not
a chart."

What the interviewer thinks:
- "Three checks with numbers." ✅
- "The metric matches the failure." ✅
- "The manual process is a clever check." ✅
- "The 24-hour check is specific." ✅
- "The one non-user is handled honestly." ✅
- Signal: confirmed judgment.

Why it decides:
✅ Three checks with numbers
✅ Metric matches the failure
✅ Manual process is a proxy
✅ The timestamp check is specific
✅ The non-user is handled honestly

Failed-Project Story Checklist:

FIRST 90 SECONDS:
☐ Name the project and what it was supposed
  to deliver
☐ Name the impact: cost, delay, adoption
☐ Name the root cause, not the blame
☐ Avoid "it didn't really fail" — name the
  actual failure

WHAT DECIDES:
☐ Root cause is an estimate error, a scope
  error, an adoption error, or a definition
  error
☐ The fix addresses the root cause, not a
  symptom
☐ The prevention targets the failure class
☐ Name how you knew the fix worked
☐ Name the cost of the fix or the
  prevention

WHAT CONFIRMS:
☐ A reusable lesson or rule
☐ Honest about who found it
☐ The follow-up "how did you know?" is
  answered with evidence
☐ "People started using it" is not evidence
☐ The prevention has caught real issues
  since

RED FLAGS:
❌ "I don't remember the details"
❌ No project named
❌ No impact
❌ "It didn't really fail" as the answer
❌ No fix, no prevention
❌ "The stakeholders changed their minds"
❌ Blame on the tool or the team
❌ No lesson

Why this works:
- The first 90 seconds set the signal
- The rest of the story confirms or
  overturns it
- Impact, root cause, and prevention are
  the three things that can't be faked

30-DAY PRACTICE PLAN (FOR CANDIDATES):

Week 1 — Recall the failures
☐ List 5 projects that failed in the last
  2 years
☐ For each, write: the project, the
  impact, the root cause
☐ Pick the 3 with the clearest impact
☐ Record yourself telling each in
  90 seconds
☐ Cut every "I don't remember" and "it
  didn't really fail"

Week 2 — Root causes
☐ For each story, write the root cause
  in one sentence
☐ Classify it: estimate error, scope
  error, adoption error, or definition
  error
☐ Write how you found it: timing, count,
  usage
☐ Write the fix and why it addresses
  the cause

Week 3 — Prevention and evidence
☐ For each story, write the prevention
  and what it targets
☐ Write how you knew the fix worked
☐ Write one reusable lesson or rule
☐ Add the cost of the fix or prevention

Week 4 — Mock interviews
☐ Run 2 mock interviews with a peer
☐ Ask them to challenge: "How did you
  know?" and "What was the root cause?"
☐ Re-run with stronger evidence
☐ Compare the two recordings

Signs it's working:
✅ You can name the impact without
  pausing
✅ You name an estimate or scope error,
  not "it didn't really fail"
✅ You name how you found it
✅ You name how you knew the fix worked
✅ You name a reusable lesson
✅ The interviewer asks "what else?"
  instead of "what was the project?"