What a Great Project Walkthrough Actually Sounds Like

THE ARC — FIVE PARTS IN 2 MINUTES:

Interviewer: "Walk me through the order
service."

1. THE PROBLEM (15s):
"The order service was handling 800K
requests per day and p99 was climbing past
400ms. The database was the bottleneck."

2. THE CONSTRAINTS (15s):
"The team was AWS-only, we had one month,
and we couldn't take downtime."

3. THE DECISION (30s):
"So we moved to a three-tier VPC with ECS
and RDS, rather than EKS. ECS was simpler
for a team without platform maturity, and
the ops overhead was lower."

4. THE TRADE-OFF (20s):
"We gave up portability. EKS would have been
better if we had a multi-cloud plan. We
didn't, so ECS earned its simplicity."

5. THE RESULT (20s):
"The result was p99 under 180ms at 2.4M
requests per day, and 99.9% uptime over
six months. Database CPU dropped 62% after
we added read replicas."

What the interviewer thinks:
- "They had a problem, not just a stack." ✅
- "They reasoned inside real constraints." ✅
- "They made a decision and named the
  cost." ✅
- "They measured the result." ✅
- "This is a real engineer." ✅

Why it works:
✅ Problem → constraints → decision →
  trade-off → result
✅ Each part earns the next
✅ The story is 2 minutes, not 10
✅ The numbers are specific

WHY IT WORKS — THE ENGAGEMENT MECHANISM:

The interviewer's attention is held by four
questions, answered in order:

1. "What was broken?"
   → The problem answers this.
   "800K req/day, p99 past 400ms."

2. "What were the limits?"
   → The constraints answer this.
   "AWS-only, one month, no downtime."

3. "What did you choose?"
   → The decision answers this.
   "Three-tier VPC with ECS and RDS."

4. "Did it work, and what did it cost?"
   → The trade-off and result answer this.
   "Gave up portability; p99 < 180ms,
   99.9% uptime."

Why this order matters:
- Problem first: without it, the stack is
  abstract
- Constraints second: without them, the
  decision is arbitrary
- Decision third: without it, the walkthrough
  is a description
- Trade-off fourth: without it, the decision
  is a guess
- Result last: it's the proof, not the hook

What each part does:
✅ Problem earns attention
✅ Constraints earn respect
✅ Decision earns trust
✅ Trade-off earns judgment
✅ Result earns confidence

The inverse is what makes a walkthrough
forgettable:
❌ "We used React, Node, and Postgres."
❌ "It was a microservices architecture."
❌ "We deployed on AWS."
❌ No problem, no decision, no result.

"THE CONSTRAINT WAS..." — SIGNALS DEPTH:

Surface walkthrough:
"We used microservices with Kubernetes and
Kafka. It scaled well."

What the interviewer thinks:
- "Scaled to what?"
- "Why microservices?"
- "Why Kafka?"
- No constraints, no reasoning.

Depth walkthrough:
"The constraint was that we had 6 engineers
and one quarter. Microservices would have
added operational overhead we couldn't
afford, so we started with a modular
monolith and split out the notification
service first, because it had a different
scaling profile."

What the interviewer thinks:
- "They reasoned inside a team-size
  constraint." ✅
- "They chose the monolith deliberately." ✅
- "They knew which service to split first,
  and why." ✅
- "This is an engineer, not a tutorial." ✅

Why it works:
✅ Constraint: 6 engineers, one quarter
✅ Decision: modular monolith, split
  notifications
✅ Reason: different scaling profile
✅ The constraint makes the decision
  meaningful

The phrase in one line:
- Surface: "We used microservices."
- Depth: "The constraint was team size, so
  we started with a modular monolith and
  split out the first service for a real
  reason."

"WE TRADED X FOR Y" — SIGNALS DEPTH:

Surface walkthrough:
"We chose Playwright because it's better."

What the interviewer thinks:
- "Better for what?" ❌
- "What did you give up?" ❌
- "When would Selenium win?" ❌
- This is fandom, not engineering. ❌

Depth walkthrough:
"We traded browser coverage for developer
speed. Playwright's auto-waiting and built-in
runner cut our test code by 40% and our
flake rate from 18% to 3%. But Playwright
has less support for legacy Safari, which
matters if you're testing older iOS. For our
users on modern Chrome and Firefox, the
trade-off was worth it."

What the interviewer thinks:
- "They named the gain: 40% less code, 18%
  → 3% flake." ✅
- "They named the cost: legacy Safari." ✅
- "They named when Selenium wins: older
  iOS." ✅
- "This is judgment, not fandom." ✅

Why it works:
✅ Trade: coverage for speed
✅ Gain: -40% code, 18% → 3% flake
✅ Cost: legacy Safari
✅ Condition: "for our users on modern
  browsers"

The phrase in one line:
- Surface: "Playwright is better."
- Depth: "We traded browser coverage for
  developer speed, and for our users, that
  was the right call."

FULL WALKTHROUGH — 2 MINUTES 30 SECONDS:

Interviewer: "Walk me through a project
you're proud of."

WHAT YOU SAY:
"Sure. I'll walk through the order service
in five parts: the problem, the constraints,
the decision, the trade-off, and the
result.

The problem: the order service was handling
800K requests per day and p99 was climbing
past 400ms. The database was the bottleneck
— 80% of p99 was spent in queries.

The constraints: we were AWS-only, we had
one month, and we couldn't take downtime.
That ruled out a full rewrite.

The decision: we moved to a three-tier VPC
with ECS and RDS, not EKS. ECS was simpler
for a team without platform maturity, and
the ops overhead was lower. We added read
replicas to take the load off the primary.

The trade-off: we gave up portability. EKS
would have been better if we had a
multi-cloud plan. We didn't, so ECS earned
its simplicity. We also gave up some query
flexibility by adding read replicas — reads
could see slightly stale data.

The result: p99 dropped from 400ms to
180ms, at 2.4M requests per day, with 99.9%
uptime over six months. Database CPU
dropped 62%. And we cut cost 18% by
right-sizing the RDS instance after the
replicas came online.

If I were doing it again, I'd measure the
replicas first, before spending a week on
a caching layer we later removed. The
replicas solved 80% of the problem."

What the interviewer thinks:
- "Five parts, clearly labeled." ✅
- "Problem: 800K req/day, 400ms p99." ✅
- "Constraints: AWS-only, one month, no
  downtime." ✅
- "Decision: ECS + RDS + read replicas." ✅
- "Trade-off: portability, stale reads." ✅
- "Result: 180ms, 2.4M req/day, 99.9%,
  -62% CPU, -18% cost." ✅
- "Reflection: replicas before caching." ✅
Signal: strong hire.

Why it works:
✅ The arc is explicit
✅ Every part has a number or a name
✅ The trade-off is honest
✅ The reflection shows growth
✅ The whole thing is under 3 minutes

THE FOLLOW-UPS — WHAT THE WALKTHROUGH
UNLOCKS:

A great walkthrough invites the right
follow-ups. Here's what an interviewer asks
after a strong one:

Interviewer: "Why ECS over EKS?"

Candidate: "Team size and platform maturity.
We had 6 engineers and no one who'd run
Kubernetes in production. EKS would have
been a 2-month learning curve, and we had
one month. ECS was the right tool for our
team at that time."

Interviewer: "What about the stale reads?"

Candidate: "We accepted a 2-second
replication lag on reads. For order status,
that was fine — the user sees the order
within 2 seconds. For the payment flow, we
routed reads to the primary to avoid
inconsistency. So the stale reads were
scoped, not global."

Interviewer: "What would you do differently?"

Candidate: "I'd measure the replicas first.
We spent a week on a caching layer before
realizing the replicas solved 80% of the
problem. That week was wasted. The lesson:
measure before optimizing."

Interviewer: "What would you do at 10x
scale?"

Candidate: "At 10x, RDS read replicas
wouldn't be enough. I'd shard the order
table by customer_id and move to a
distributed database, probably Aurora
Global or DynamoDB. The trade-off is
operational complexity and a migration
project. I'd plan it as a 6-month project,
not a sprint."

What the interviewer thinks:
- Every follow-up is answered with a
  specific reason. ✅
- The candidate knows the edge cases of
  their own decision. ✅
- The candidate can reason about scale. ✅
- This is a senior engineer. ✅

Why the walkthrough unlocks good follow-ups:
✅ The constraints invite "why that choice?"
✅ The trade-off invites "how did you
  handle the cost?"
✅ The reflection invites "what would you
  do differently?"
✅ The numbers invite "what about at 10x
  scale?"

A strong walkthrough doesn't end the
conversation. It starts it.

Project Walkthrough Checklist:

THE FIVE PARTS:
☐ Problem: what was broken, with a number
☐ Constraints: team, time, budget, existing
  stack
☐ Decision: what you chose, and why
☐ Trade-off: what you gave up
☐ Result: what changed, with numbers

THE PHRASES:
☐ "The constraint was..."
☐ "We traded X for Y..."
☐ "If I were doing it again..."
☐ "The trade-off was..."
☐ "The result was..."

THE FOLLOW-UP PREP:
☐ "Why that choice?" → the constraint
☐ "What broke?" → one incident
☐ "What would you do at 10x?" → a plan
☐ "What would you do differently?" → a
  reflection

RED FLAGS IN YOUR OWN WALKTHROUGH:
❌ "We used React, Node, and Postgres."
❌ "It was a microservices architecture."
❌ "We deployed on AWS."
❌ No problem, no constraint, no decision
❌ No trade-off, no number
❌ No reflection
❌ The walkthrough is over 5 minutes

THE ENGAGEMENT TEST:
For each project, ask yourself:
1. "What was broken, and by how much?"
2. "What were the constraints?"
3. "What did I choose, and what did it
  cost?"
4. "Did it work, and by how much?"

If any answer is a blank, the walkthrough
is a description, not a story.

30-DAY WALKTHROUGH PLAN:

Week 1 — Write the five parts
☐ Pick your strongest project
☐ Write the problem with a number
☐ Write the constraints: team, time, budget
☐ Write the decision and the trade-off
☐ Write the result with numbers

Week 2 — Practice the arc
☐ Say the walkthrough out loud in 3 minutes
☐ Record and listen for the five parts
☐ Cut every feature list
☐ Add a number to every part

Week 3 — Prepare the follow-ups
☐ Write answers to "why that choice?",
  "what broke?", "what would you do at
  10x?", "what would you do differently?"
☐ Practice each in 30 seconds
☐ Record and listen for vague answers

Week 4 — Mock interview
☐ Have a peer ask "walk me through a
  project"
☐ Give the 3-minute walkthrough
☐ Have them ask all four follow-ups
☐ If you pause, that's the part to prepare

Signs it's working:
✅ You lead with the problem, not the stack
✅ Every part has a constraint or a number
✅ The trade-off is honest
✅ The reflection is specific
✅ The interviewer asks "tell me more"
✅ The walkthrough is under 3 minutes
✅ You leave feeling you were understood,
  not just quizzed