interview-prep

Files (1)

• SKILL.md

SKILL.md (first lines)

# System Design Interview Prep

Strong candidates win on structure, not trivia. A repeatable framework keeps you driving the conversation, surfaces trade-offs the interviewer cares about, and leaves time for the deep dive that distinguishes seniority.

## Stack Baseline (2026)
| Concern | Recommended |
| --- | --- |
| Framework | Requirements -> Estimation -> API -> Data -> HLD -> Deep dive -> Trade-offs |
| Modeling | C4 Context + Container on the whiteboard |
| Reference text | Richards & Ford, *Fundamentals of Software Architecture* 2e |
| Distributed depth | *Designing Data-Intensive Applications* (Kleppmann), *The Hard Parts* |
| Patterns | Event-driven, CQRS, outbox, saga, CDC, sharding, consistent hashing |
| Practice format | Architecture Kata (Ted Neward), 45-min timeboxed mocks |

## When to Use
- Personal prep for staff/principal/architect interview loops.
- Coaching internal candidates on promotion panels.
- Calibrating interviewer rubric so signal is consistent.

## Prerequisites
- Comfort with one cloud's primitives (compute, queue, KV, OLTP, OLAP, object store).
- Working mental model of CAP, latency numbers, and consistency models.
- A whiteboard or digital canvas; a stopwatch.

## Instructions

```mermaid
flowchart LR
  R[Requirements<br/>5 min] --> E[Estimation<br/>5 min]
  E --> A[API + Data<br/>10 min]
  A --> H[High-Level Design<br/>10 min]
  H --> D[Deep Dive<br/>10 min]
  D --> T[Trade-offs + Wrap<br/>5 min]
```

1. **Clarify requirements**: functional, non-functional (RPS, latency, durability, consistency), constraints. Write them on the board.
2. **Estimate capacity**: users, QPS read/write, storage/day, bandwidth. Show the math; round aggressively.
3. **Sketch API + data model**: 3-6 endpoints, key entities, access patterns, primary/secondary indexes.
4. **Draw HLD** as C4 Containers: clients, edge, services, datastores, async backbone. Mark sync vs async.
5. **Pick a deep dive** the interviewer signals interest in (hot path, sharding, consistency, failure mode).
6. **Articulate trade-offs**: what you chose, what you rejected, what would change your mind.

```markdown
# Mock Scoring Rubric (per dimension, 1-5)

- Requirements & scoping
- Capacity estimation (numbers, units, sanity)
- API & data modeling
- High-level design clarity (C4-ish)
- Distributed-systems depth (consistency, partitioning, failure)
- Trade-off articulation
- Communication & time management

Pass bar (Staff): >=4 average, no dimension <3, deep dive shows production scars.
```

## Common Pitfalls
| Pitfall | Why it hurts | Fix |
| --- | --- | --- |
| Jumping to a diagram | Misses the actual problem | Spend the first 5 min on requirements + NFRs |
| Hand-waved estimates | Signals lack of rigor | Always show units and assumptions |
| Buzzword stacking | Reads as Golden Hammer | Justify each component against an NFR |
| One-way design | Can't defend choices | Pre-load 2-3 trade-off pairs (consistency vs availability, etc.) |
| No deep dive | Looks junior | Pick the riskiest piece and go three layers deep |
| Time blowouts | No wrap, no trade-offs | Use the 5/5/10/10/10/5 timebox |

## Output Format
- A one-page personal cheat sheet: framework, latency numbers, estimation templates.
- A library of 10-15 practiced prompts with notes on chosen designs and rejected options.
- Mock recordings or transcripts scored against the rubric above.

## Authoritative References
- Mark Richards & Neal Ford, *Fundamentals of Software Architecture*, 2e (O'Reilly, 2024).
- Mark Richards & Neal Ford, *Software Architecture: The Hard Parts* (O'Reilly).
- Martin Kleppmann, *Designing Data-Intensive Applications* (O'Reilly).
- Ted Neward, Architecture Kata format — neward.net/architecturalkatas.
- C4 model — c4model.com.
- ThoughtWorks Technology Radar — thoughtworks.com/radar.

From SwapnilPopat/ai-assistant-skills, MIT.

More from SwapnilPopat/ai-assistant-skills