64. "Walk Me Through a System You Designed" — The Past-Project Deep Dive

64.1 What this round is, and why it decides levels

In many senior loops one round, or a large part of the hiring-manager round, is: "Tell me about the most complex system you've designed or led. Walk me through it." It's commonly reported at Amazon (often probed along the Leadership Principles, especially Dive Deep and Ownership), at Meta (project retrospective-style discussions for senior candidates), at Google (Staff+ leadership and experience discussions read by the hiring committee), and at Microsoft (hiring-manager and "as appropriate" rounds).

The interviewer can't verify a hypothetical design, but they can test whether you've actually operated at the level you're applying for. The system design round shows what you could do. This round shows what you did. At Senior level it confirms you've owned systems end to end. At Staff and Principal level it often counts as much as the design round.

What they score:

64.2 Choosing the project(s)

Prepare three projects, because interviewers sometimes ask for a second one or redirect:

Selection checklist:

• Within the last ~3–4 years (older is fine if it's clearly your best and you remember the details).
• You made or drove the key decisions. Not "I was on the team that...".
• It touched multiple teams and had a business outcome you can quantify.
• You can draw it from memory in 3 minutes and go deep on at least two components.
• You know the numbers (QPS, data size, latency, cost, team size, timeline), or honest ranges.
• It contains at least one real trade-off where reasonable people disagreed.
• You can talk about it without violating confidentiality. Anonymize names and round numbers, and say so.

Projects that hurt you: a project too small for the level ("I built a service with 3 endpoints"); a project where your role was mostly implementation of someone else's design (for Staff+ roles); one where you can't explain why the architecture is the way it is ("it was already like that"); a pure success story with no trade-offs or problems (it sounds rehearsed, or shallow).

64.3 The structure: a 5-minute overview, then let them drill

Open with a tight 4–6 minute overview, then hand control to the interviewer. Don't monologue for 20 minutes. The deep dive is where the signal comes from, and the interviewer wants to choose where to dig.

 1. CONTEXT & BUSINESS PROBLEM (45 s)
    "Company/product, what was broken or needed, what it cost the business, why now."
 2. CONSTRAINTS & REQUIREMENTS (45 s)
    Scale, SLOs, deadlines, team size, legacy, compliance — the forces that shaped the design.
 3. MY ROLE (20 s)
    "I was the tech lead / architect / EM; I owned X and Y; Z was owned by another team."
 4. THE DESIGN (2 min) — draw it
    Before → after diagram; the 2-3 key decisions and the alternatives you rejected.
 5. EXECUTION & RISK (45 s)
    How you rolled it out safely; the hardest moment; how you aligned other teams.
 6. OUTCOME (30 s)
    Measured results tied back to the business problem.
 7. REFLECTION (30 s)
    "What I'd do differently" — one real, specific thing.
 → "Happy to go deeper anywhere — the consistency model and the migration were the most interesting parts."

The last line matters: you steer the interviewer toward the areas where you're strongest, without forcing it.

64.4 The prep worksheet (fill one per project)

PROJECT: ______________________   Dates: ____   Team size: __ engineers across __ teams
BUSINESS PROBLEM:   what hurt, who felt it, $ / users / incidents / deadline
NORTH-STAR METRIC:  the number the business cared about (before → after)
CONSTRAINTS:        scale (QPS, data), SLOs, legacy, compliance, timeline, people
MY ROLE:            decisions I made | things I influenced | things others owned
ARCHITECTURE:       before diagram | after diagram (practice drawing both in < 3 min)
KEY DECISIONS (3):  decision | alternatives | why chosen | what it cost | would I choose it again?
DEPTH LADDERS (2):  pick 2 components; write 4 levels of "why/how" for each (see 63.5)
HARDEST PROBLEM:    what went wrong / surprised us, how I found it, how we fixed it
ROLLOUT:            migration strategy, safety mechanisms, rollback plan, how long
INFLUENCE:          who disagreed, how it was resolved (data? prototype? escalation?)
OUTCOMES:           latency, availability, cost, incidents, velocity, revenue — with numbers
REFLECTION:         what I'd change; what I learned that I've applied since
NUMBERS SHEET:      QPS, p50/p99, data volume, # services, $ cost, timeline, team size

64.5 Depth ladders: be ready to go 4 levels down

Interviewers probe one component until they reach the edge of your knowledge. Prepare a ladder for your two most important decisions:

 L1  "Why Kafka for the order events?"
       → durable replay for 5 consumers; ordering per order_id; team already ran it
 L2  "How did you partition it?"
       → by order_id, 48 partitions sized for 3× peak consumer parallelism
 L3  "What went wrong with that?"
       → a marketplace seller generated 30% of events → hot partition → consumer lag
          during sales; we re-keyed by (seller_id, order_id) hash for big sellers only
 L4  "How did re-keying affect ordering guarantees?"
       → ordering is per order_id; since an order's events still share one key, per-order
          order held; cross-order ordering was never guaranteed and nobody depended on it —
          we verified by auditing consumers' assumptions before the change

If you hit the limit of your knowledge, say so and reason: "I didn't own the broker configuration, but I'd expect acks=all with min.insync=2, and I'd verify..." That's far better than inventing an answer, which experienced interviewers detect quickly.

64.6 A worked example (illustrative; use your own project)

The following is a fictional but realistic answer, shown to calibrate length, structure, and the level of detail. Never borrow someone else's project. Interviewers will find out within two follow-up questions.

Overview (≈ 5 min, as spoken):

Context. "At a mid-size e-commerce company (~$800M GMV), checkout ran on a Rails monolith with a single Postgres primary shared by 14 teams. We had roughly 2 major checkout incidents a month, mostly from other teams' changes, such as a reporting query or a migration that locked tables. Each one cost about $150–300k in lost orders. Leadership also wanted to launch in the EU within a year, which required EU data residency."

Constraints. "Peak was 1,800 orders/min on Black Friday, checkout p99 had to stay under 800 ms, the EU deadline was fixed, and I had 3 teams (~18 engineers) with no headcount growth. We couldn't freeze features for more than 6 weeks in total."

My role. "I was the principal engineer for the commerce domain. I wrote the architecture proposal, chose the migration strategy, and owned the order and data model decisions. The payments team owned the payment integration. My EM partner owned staffing and sequencing, and I advised on the risk ordering."

Design. (draws before/after) "We extracted the order lifecycle into an Order service that owned its own database, published events via a transactional outbox with CDC, and was deployed in cells: one per region plus a split of the US into 2 cells by customer hash. Three key decisions. First, outbox + CDC instead of dual writes: dual writes had already caused inconsistencies in a previous project. Second, cells instead of a single sharded cluster, because the business problem was blast radius and residency, not raw scale; a cell maps cleanly to 'EU data stays in the EU'. Third, a modular extraction instead of a full microservices split: only orders and inventory reservation came out; everything else stayed in the monolith behind a module boundary."

Execution. "We migrated with the expand → dual-read → cut-over pattern, using CDC from the monolith's tables and shadow-comparing reads for 3 weeks. The hardest moment was the backfill: our first run overwrote orders that customers had updated during the backfill. We caught it in shadow comparison before cut-over and fixed it with conditional writes on updated_at."

Outcome. "Checkout incidents caused by other teams went from about 2 a month to zero over the next 3 quarters. Checkout p99 went from 1.1 s to 420 ms, mostly by removing lock contention. EU launched on time with residency built in. Infrastructure cost rose about 12% because of the cell duplication, which the business accepted against the incident savings."

Reflection. "I under-invested in tooling for moving tenants between cells. We needed it 6 months later for a large B2B customer, and building it under pressure was painful. Today I'd build cell migration as part of the platform from the start."

"I'm happy to go deeper on the outbox design, the cell routing, or how we got the 14 teams to agree to the module boundaries."

Typical drill-down questions, and the shape of strong answers:

64.7 The engineering manager version of this round (EM, Sr. EM)

For engineering managers the same question is scored differently. You don't need to have designed every box, but you must show that you created the conditions for a good design and delivered it:

The EM trap: answering only at the people level ("I made sure the team was happy"). Senior EM loops expect you to hold your own on the architecture, at least two levels deep.

64.8 Handling the hard moments

64.9 Self-scoring rubric (use after a mock)