System Design Interview Practice Plan and Job-Ready Checklist

You have read about load balancers, caches, queues, replication, sharding, consistency, idempotency, sagas, fault tolerance and observability, and worked through fifteen case studies. That is a lot of knowledge. But an interview is not a written exam. It is 45 minutes of thinking aloud, under mild pressure, about a problem you may not have seen, with someone who interrupts, asks "why?" and wants to see your judgement. Performing well there is a separate skill, and like any skill it improves with deliberate practice.

This final article gives you a practice plan, a way to grade yourself, problems to practise on, and the job-ready checklist that summarises the whole course. It cannot promise you an offer: interviews vary by company, interviewer and day, and hiring depends on more than one round. It can make sure that when you walk into a system design round, the method is so familiar that your attention is free for the problem.

• How to practise system design so that it transfers to real interviews.
• An eight-week plan, with a lighter and a faster variant.
• How to run timed solo drills and mock interviews, and how to review them.
• A self-scoring rubric with SDE-1 and SDE-2 expectations.
• A drill sheet for the twelve classic problems in this course.
• Ten new practice problems to test whether your method transfers.
• The common failure patterns, and the complete job-ready checklist.

Three principles matter more than the number of hours:

1. Practise out loud, with a timer. Silent reading builds recognition ("yes, that makes sense"), not production. Speak your design as if to an interviewer, write the requirements and estimates down, draw the diagram, and stop at 45 minutes.
2. Compare and record what you missed. After each attempt, read the matching case study (or ask a peer) and write down, in a "misses" list, every important point you did not cover: a failure mode, a trade-off, a wrong estimate. Your misses list is your personal syllabus.
3. Space and mix. Return to topics after a day, a week and a month, and mix problem types (read-heavy, write-heavy, real-time, correctness-critical) rather than practising one kind repeatedly.

A useful rhythm for each practice problem:

The plan assumes about 6 to 8 hours a week, and that you have read the course once. Adjust the pace to your life; consistency beats intensity.

Lighter variant (12 weeks, 4 hours a week): stretch each week of the plan over a week and a half, keep one timed problem per week, and do mock interviews every three weeks.

Fast variant (4 weeks, for an interview soon): weeks 1 and 2 combined in the first week; then the SDE-1 fast track (articles 12, 13, 15, 17, 20); then three timed problems a week (30, 31, 33, 34, 35, 38) with a mock at the end of each week.

Mock interviews are the closest thing to the real experience. Pair up with a friend or classmate and take turns.

As the interviewer:

• Pick a problem the candidate has not studied recently.
• Give the prompt in one sentence and let them drive. Answer clarifying questions with sensible assumptions.
• Push gently at transitions: "What happens if this cache fails?", "Why not a NoSQL store here?", "Your feed takes 2 seconds; where does the time go?"
• Ask for a summary at the end.
• Score with the rubric and give two strengths and two improvements, with specific moments.

As the candidate: treat it as real. Use the time plan from article 29. If you get stuck, say what you are thinking. Ask for feedback on communication, not only on the design.

Being the interviewer is valuable practice too: you learn quickly what clear and unclear explanations sound like.

Rate each dimension from 1 to 4 after every attempt. Rubrics vary between companies; these dimensions reflect what system design interviews commonly look for (article 29).

Reading your scores: consistent 3s across the board is a solid SDE-1 performance; SDE-2 interviews generally expect 3s everywhere and 4s in depth, failure handling and trade-offs. Track your scores over time; the lowest dimension is where your next week of practice should go.

For each problem, practise until you can state the answers to these questions from memory, then run the full 45-minute version.

The real test of the method is a problem you have not studied. For each one below, the notes say what makes it interesting and which course ideas apply. Attempt it timed before reading the notes.

1. A leaderboard for a mobile game. Ranking at scale with frequent score updates. Applies: sorted sets, top-K caching, idempotent score submission (article 29 has a compressed version; do the full one).
2. A web crawler only (no search). Politeness and scale without the index. Applies: host-partitioned frontier, robots.txt, deduplication, traps (article 44).
3. A metrics and monitoring system that ingests a million data points per second and powers dashboards and alerts. Applies: write-heavy time-series storage, downsampling, retention, cardinality, alert evaluation (articles 17, 25).
4. A distributed counter for likes and views that must handle viral posts. Applies: hot keys, bucketed counters, write-back caching, eventual consistency (articles 09, 14, 16).
5. A coupon and promotions service. Correctness under concurrency with budgets. Applies: conditional updates, unique constraints, idempotency, abuse prevention (articles 14, 20, 43).
6. A file sync service like a personal cloud drive, with desktop clients. Applies: chunking and deduplication, metadata versus blobs, conflict handling between devices, notifications of changes (articles 10, 19, 34).
7. An ad-click aggregation pipeline producing per-minute counts for billing. Applies: event streams, deduplication, exactly-once effects for money, late events and windows (articles 11, 20, 27).
8. A hotel reservation system. Similar to ticket booking, but with date ranges. Applies: inventory per room type per night, holds, overbooking policy, cancellations (articles 14, 38).
9. A collaborative document editor (simplified). Real-time edits from many users. Applies: WebSockets, per-document ordering, conflict resolution approaches, presence (articles 05, 19, 34); the conflict-resolution algorithms can be discussed at a high level.
10. An email delivery service for transactional email at scale. Applies: queues, provider-style retries, reputation and rate limits per destination, bounces and complaints as feedback events (articles 11, 23, 33).

When you finish one, check yourself against the drill-sheet questions: what was the driving requirement, and did your key decisions follow from it?

Tick an item only when you can explain it aloud, with an example, and say how it fails. Use the articles in brackets to revise.

Foundations

• I can explain what system design is and how HLD differs from LLD (01)
• I can separate functional and non-functional requirements and state the latter as numbers (02)
• I understand scalability, vertical and horizontal (02, 08)
• I understand availability, nines, and availability in series and with redundancy (02, 24)
• I understand latency, percentiles and tail latency (02, 03)
• I understand throughput and Little's Law (02, 07)

Capacity

• I can estimate QPS from users, including peak factors and fan-out (06)
• I can estimate storage per day and per year, with replication and retention (07)
• I can estimate bandwidth in Gbps and decide whether a CDN is needed (07, 10)
• I can estimate cache size from the working set and the effect of hit ratio (07, 09)

Building blocks

• Load balancer: algorithms, health checks, statelessness (08)
• CDN: caching rules, cache keys, invalidation versus versioned URLs (10)
• Cache: patterns, TTL, invalidation, stampedes, hot keys (09)
• Database: relational modelling around access patterns (12)
• Queue: acknowledgements, retries, dead-letter queues, ordering (11)
• Workers: idempotent, bounded, observable (11)
• Object storage: presigned and multipart uploads (10)
• API gateway: responsibilities and limits (26)

Databases

• Indexes: composite order, covering, write cost (13)
• Replication: synchronous versus asynchronous, lag, failover (15)
• Read replicas and read-your-writes routing (15)
• Partitioning: keys, strategies, hot partitions (16)
• Sharding and consistent hashing (16, 32)
• SQL versus NoSQL by access pattern (17)
• Transactions, isolation levels and race prevention (14)

Distributed systems

• CAP stated precisely, and PACELC (19)
• Consistency models: strong, causal, read-your-writes, eventual (19)
• Eventual consistency and conflict resolution (19)
• Idempotency keys, unique constraints, idempotent consumers (20)
• Distributed locks, leases and fencing tokens (22)
• Retries with backoff, jitter and budgets (20, 23)
• Failure handling: partial failure, timeouts with unknown outcomes (18)
• Message delivery: at-most-once, at-least-once, effectively-once; outbox and sagas (20, 21)

Reliability

• Availability targets and error budgets (24)
• Fault tolerance: timeouts, circuit breakers, bulkheads (23)
• Failover and split brain (15, 24)
• Backpressure and load shedding (23)
• Graceful degradation plans (23)
• Disaster recovery: RPO, RTO and the four strategies (24)

Operations

• Logging: structured, correlated, without secrets (25)
• Metrics: golden signals, histograms (25)
• Tracing: spans and context propagation through queues (25)
• Monitoring: SLOs and symptom-based alerts (25)
• Health checks: liveness, readiness, synthetic checks (08, 25)

Security

• Authentication: identity providers, sessions and tokens (28)
• Authorisation: object-level checks, deny by default (28)
• Encryption in transit and at rest (28)
• Secrets management and rotation (28)
• Rate limiting and abuse prevention (28, 31)

Interview

• I can clarify requirements in five minutes (29)
• I can estimate scale quickly and draw conclusions (06, 07, 29)
• I can design APIs, including idempotency (04)
• I can model data around access patterns (12)
• I can draw a baseline architecture and walk a request through it (29)
• I can identify the first bottleneck and scale it (29 and every case study)
• I can discuss trade-offs as "chose, costs, acceptable because" (29)
• I can explain what happens when each component fails (every case study)
• I can defend architectural decisions and change my mind gracefully (29, 45)

A good balance for most people: about two thirds solo timed practice with careful review, one third mocks, and depth over breadth.

• Back to the start: re-read Start Here: What System Design Is and How to Learn It. Ideas that were abstract on the first day will now be concrete, which is a good measure of progress.
• For the rest of the interview loop, Software Interview Preparation: A 6-Week Plan That Actually Works covers coding and behavioural rounds, and The Interview Problem-Solving Workflow from the DSA course complements this course for coding rounds.