Skip to content

Practising System Design

~20 min

In short

System design and DSA are the two main skills in most software interviews. Design is a skill you build by talking through problems again and again, not by reading one article. Start early, practise a little each week, use the same 45-minute structure every time, and review your own answers against a fixed rubric. Nobody can promise an offer. Practice builds depth and speed, and that is what this page is for.

Why start early

Candidate reports and interview-prep sites (forum and prep-site opinion, not an official statement) say system design is usually expected from about 2 to 3 years of experience, and that freshers more often face DSA plus basic OOD and LLD. Amazon's own preparation page ties its SDE interview course to roles that require at least two years of experience (checked 18 Oct 2026). Treat this as the typical pattern, not a rule. Some interviews will ask you a design question early, and the first time you think about load balancers should not be in the interview room.

Topic checklist

Know what each topic means and when to bring it up. Tick a topic only when you can explain a trade-off, not just the definition.

  • [ ] Requirements and estimation: functional vs non-functional, users, requests per second, storage
  • [ ] APIs: endpoints, request and response shape, pagination
  • [ ] Data model: entities, keys, which database and why
  • [ ] Caching: what to cache, where, how it goes stale
  • [ ] Queues: when to decouple work with a queue
  • [ ] Sharding and replication: how data is split and copied
  • [ ] Consistency: what happens when copies disagree
  • [ ] Rate limiting: how to protect a service from too many calls
  • [ ] Idempotency: safe retries when a request runs twice
  • [ ] Failure handling: timeouts, retries, circuit breakers, graceful degradation

A repeatable 45-minute answer

Use the same order every time so your effort goes into the design, not into choosing what to do next.

Minutes Step
0 to 5 Clarify requirements. Ask about scope and say what you will not build.
5 to 8 Estimate users, traffic and storage. State every assumption out loud.
8 to 15 Define the APIs and the data model.
15 to 35 Draw the high-level design. Then deep-dive into the two biggest bottlenecks.
35 to 42 Cover failures, scaling and consistency trade-offs.
42 to 45 Summarise the design and name what you would do next.

20 classic problems to practise

Work through these one at a time. For each, do the full 45-minute answer on paper or a whiteboard, then review it with the rubric below.

System design (14):

  • [ ] URL shortener
  • [ ] Rate limiter
  • [ ] Key-value store
  • [ ] Distributed cache
  • [ ] Unique ID generator
  • [ ] Web crawler
  • [ ] Chat system
  • [ ] News feed
  • [ ] Notification system
  • [ ] Typeahead (autocomplete)
  • [ ] File storage (Dropbox-style)
  • [ ] Ride matching (Uber-style)
  • [ ] Video streaming
  • [ ] Ticket booking with seat locking

Low-level design (6):

  • [ ] Parking lot
  • [ ] Elevator system
  • [ ] ATM
  • [ ] LRU cache
  • [ ] Vending machine
  • [ ] Pub-sub system

Using this site's HLD and LLD sections

Read a trade-off page after you attempt a problem, not before. Your own attempt first, then the comparison.

Practising with a friend

  • Split roles: one person is the interviewer and one is the candidate. With three people, the third keeps time and takes notes.
  • The interviewer gives only the prompt. Answer clarifying questions honestly, and say "assume reasonable numbers" when asked for something you have not decided.
  • Run the full 45 minutes, then give 10 minutes of feedback using the rubric.
  • Swap roles. Two people can cover a lot of problems in a month if each session is strict about time.

Self-review rubric

Score each area from 0 (missing) to 2 (clear and reasoned) after every practice answer.

Area What a 2 looks like Score
Requirements Asked about scope and stated what is out of scope
Estimation Numbers written down with assumptions
APIs and data Clear endpoints and a justified storage choice
Scaling Named the bottleneck and how to remove it
Trade-offs Said what each choice costs, not only what it gives
Failures Covered timeouts, retries or what breaks first
Pace Stayed within the 45 minutes with a summary at the end

Keep a log of scores. A weak area that shows up three times in a row is the one to study next.

Try this

Choose the URL shortener. Set a timer for 45 minutes, work through the table above on paper, and then score yourself with the rubric. Write down the one area that scored lowest and read its topic page on this site.

Sources