Courses › System Design › Getting Started

How to Prepare

A 4-week study plan that moves from concepts to timed mock interviews.

Most engineers prepare for system design by watching videos and reading blog posts. That builds familiarity, not skill. The goal of preparation is to be able to produce a design under time pressure — so your plan should shift from consuming to producing as quickly as possible.

A 4-week plan

This assumes 6–8 hours per week. Compress or stretch as needed.

Week 1: build the foundation

Start with the Delivery Framework. Then read the Core Concepts in order. For each one, write down:

  • The problem it solves
  • The two or three main options and their trade-offs
  • One sentence you'd say in an interview to justify a choice

That last item matters. "I'll use a cache-aside Redis cache here because reads outnumber writes 100:1 and we can tolerate a few seconds of staleness" is the kind of sentence that earns credit.

Week 2: technologies and patterns

You don't need to know every database. You need to know a small toolkit deeply enough to answer follow-ups:

  • A relational database (PostgreSQL) — transactions, indexes, replication
  • A key-value / wide-column store (DynamoDB or Cassandra) — partition keys and access patterns
  • A cache (Redis) — data structures, eviction, use as a lock or rate limiter
  • A log / queue (Kafka) — partitions, consumer groups, ordering
  • A search index (Elasticsearch) — inverted indexes, when search needs its own store
  • Blob storage + CDN — presigned URLs, multipart uploads

Then read the Patterns section. Patterns are the bridge between concepts and questions: almost every deep dive is one of them in disguise.

Week 3: question breakdowns

For each breakdown:

  • Read only the problem statement and requirements.
  • Design it yourself for 30 minutes on paper.
  • Read the breakdown and note every gap between your design and it.
  • A few days later, redo it from scratch without looking.

[!WARNING] Don't memorize designs Interviewers modify classic questions specifically to catch memorized answers — "design Ticketmaster, but for restaurant reservations". Focus on *why* each decision was made so you can re-derive it.

Week 4: simulate the real thing

Practice under real conditions:

  • 45 minutes, timer visible
  • A whiteboard tool you'll use in the interview (Excalidraw, a doc, or a real whiteboard)
  • Talk out loud the whole time — record yourself if you can
  • Use unseen questions from the question library

The single highest-leverage activity is a mock interview with someone who has interviewed candidates. They'll catch habits you can't see yourself: rambling requirements, skipping the API, never stating trade-offs.

[!TIP] Keep a mistakes log After every practice session, write down the one or two moments you stalled. Patterns in that log tell you exactly what to study next.