Interview Prep · Topic 7 of 10

Mock System Design

150 XP

Why system design mocks are different

In coding rounds, correctness is binary.

In system design rounds, quality is judged by:

  • scoping skill
  • trade-off quality
  • operational realism
  • communication structure

You can pass with an imperfect architecture if your reasoning is strong.
You can fail with a "fancy" architecture if your reasoning is weak.

The 45-minute simulation template

0-5 min: Clarify requirements

  • who are users?
  • key user actions?
  • scale assumptions (DAU, QPS, data growth)?
  • latency and availability targets?
  • consistency requirements?

5-10 min: Rough estimation

  • read/write QPS
  • storage growth
  • bandwidth hot paths

10-20 min: High-level architecture

  • core services
  • data stores
  • cache/message queues
  • API boundaries

20-35 min: Deep-dive critical path

Pick the hardest path (feed fanout, payment flow, chat delivery, etc.) and go deep:

  • data model
  • partitioning
  • failure handling
  • consistency trade-offs

35-42 min: Bottlenecks + reliability

  • hot keys/shard imbalance
  • cache failure
  • regional outage
  • backpressure strategy
  • observability

42-45 min: Recap

  • summary of decisions
  • explicit trade-offs
  • what you'd build next

This time structure prevents common failure: spending 30 minutes in vague diagrams.

Scoring rubric (use for each mock)

Score each 0-5:

| Category | 0-1 | 2-3 | 4-5 | |---|---|---|---| | Requirement clarity | no scope control | partial | crisp scope + assumptions | | Scale estimation | missing/wrong order | rough but usable | strong, drives design choices | | Architecture quality | ad hoc | workable | clean services + data boundaries | | Trade-off analysis | hand-wavy | some trade-offs | explicit decision matrix thinking | | Reliability thinking | ignores failures | basic failover | realistic failure mode mitigation | | Communication | chaotic | understandable | organized, interviewer-friendly |

Track trend across 8-10 mocks, not one session.

Question bank for mock rotation

Rotate archetypes, not just products:

  1. Read-heavy: news feed, timeline, recommendation serving
  2. Write-heavy: event ingestion, telemetry pipeline
  3. Consistency-critical: payments, inventory, booking
  4. Real-time: chat, collaborative docs, multiplayer events
  5. Analytics/reporting: dashboards, aggregation pipelines

If all your mocks are "design Twitter," your preparation is narrow.

Evaluation prompts for the interviewer/peer

Ask your mock partner to score and comment on:

  • Did I ask enough clarifying questions?
  • Did my estimates meaningfully influence architecture?
  • Did I identify a bottleneck before being asked?
  • Did I explain consistency choices clearly?
  • Did I reason about failure and recovery, not just happy path?

The feedback prompt quality matters as much as the mock itself.

Common mistakes in system design mocks

Mistake 1: Overbuilding too early

Starting with multi-region active-active before defining requirements.

Fix: baseline first, then scale/failure upgrades.

Mistake 2: Naming tools without design logic

"We'll use Kafka + Redis + Cassandra" without role clarity.

Fix: every component must answer:

  • what responsibility does it own?
  • why this choice over alternatives?

Mistake 3: No data model

APIs and architecture are vague without entities and keys.

Fix: define primary objects, IDs, and access patterns early.

Mistake 4: Ignoring operations

No mention of metrics, tracing, or alerting.

Fix: include at least:

  • saturation metrics
  • error rates
  • latency percentiles
  • key business metric

Trade-off matrix habit (senior signal)

When choosing between alternatives, state matrix out loud:

| Option | Pros | Cons | Use when | |---|---|---|---| | Push feed fanout | fast reads | expensive writes | moderate fanout | | Pull feed | simpler writes | read amplification | high-celebrity skew | | Hybrid | balanced | higher complexity | mixed traffic profile |

This demonstrates judgment, not memorization.

Reliability drill (must include in mocks)

For every mock, answer:

  1. What fails first at 10x traffic?
  2. What fails first during region outage?
  3. What data can be eventually consistent?
  4. What data must be strongly consistent?
  5. What is rollback strategy for bad deploy?

If you cannot answer these, architecture discussion is incomplete.

Communication script for strong delivery

Use this sentence flow:

  1. "I'll first clarify scope and constraints."
  2. "Given these assumptions, here is baseline architecture."
  3. "Now I'll deep-dive the critical path."
  4. "Here are bottlenecks and mitigations."
  5. "Trade-off summary and next improvements."

This creates a predictable narrative and reduces interviewer cognitive load.

4-week mock plan

Week 1

  • 2 foundational designs (URL shortener, rate limiter)

Week 2

  • 2 distributed dataflow designs (feed, event pipeline)

Week 3

  • 2 consistency-critical designs (payments, reservations)

Week 4

  • 2 mixed mocks with strict timing + peer scoring

After each week, write one "mistake pattern" note and one "improvement action."

What "interview ready" looks like

You are ready when:

  • you can structure any unknown prompt in three minutes or less
  • your estimates are directionally sound and useful
  • your design choices are justified by constraints
  • you discuss bottlenecks proactively
  • you can recover cleanly when challenged

System design readiness is composure plus reasoning.

Final takeaway

Mock system design should train:

  • structured ambiguity handling
  • explicit trade-offs
  • operational realism
  • calm communication

Do 8-12 deliberate mocks with scoring and review, and your real interviews become controlled discussions instead of improvisation.