Top 10 System Design Interview Questions

Ideas you will meet

Distributed Systems

Consensus, time, failure and the fundamentals of scale-out.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Low-Level Design Practice · 10 minHow to approach a low-level design problemA repeatable six-step method: clarify, find the nouns, give each a responsibility, relate them, pick patterns and then code the core.Read hereClose

  Low-level design is about structure

  A high-level design decides servers, databases and queues. A low-level design (LLD) decides classes, methods and relationships inside one program. The questions are: what objects exist, who owns which rule, and how will this change next month?

  Interviewers use LLD problems (a parking lot, an elevator, a chess game) because a small problem shows how you think: do you clarify, do you model sensibly, do you keep rules in one place, do you notice concurrency?

  The six steps

  100%

  Figure SDA-LLD-01-1 · The six-step method for low-level design · © forcsguy.com

  1. Clarify requirements. Who uses it? What are the three to five main flows? What is the scale? What is deliberately out of scope?
  2. Find the nouns and verbs. Nouns become candidate classes; verbs become methods. Drop nouns that are only values (a price can be a number or a small value type).
  3. Assign responsibilities. Each class owns its data and the rules about that data. If a rule needs data from two classes, ask which one should own it or whether a third coordinating class is justified.
  4. Draw relationships. Has-a (composition), is-a (inheritance, used sparingly), uses (dependency). Prefer composition and interfaces to deep inheritance.
  5. Apply patterns where they earn their keep. A lifecycle with many states suggests the State pattern; swappable rules (pricing, matching) suggest Strategy; things that react to events suggest Observer; complex creation suggests Factory.
  6. Code the core flow, then stress it. Write the happy path, then ask: what if two users act at once? What if the input is invalid? What if a step fails halfway?

  Habits that earn trust

  • Names carry meaning. ParkingSpot, Ticket, calculateFee beat Manager and process.
  • Single responsibility. A class that "does everything" is the usual red flag.
  • Depend on interfaces at the points that will change (payment method, pricing rule), not everywhere.
  • Make illegal states hard to represent. Use enums or state objects instead of loose strings and booleans.
  • Say your trade-offs aloud. "I used a simple map here; if we needed millions of spots I would index by level."

  A tiny example of the method

  Requirement: "a vending machine that sells snacks for coins". Nouns: machine, product, slot, coin. Verbs: select, insert, dispense, refund. Responsibilities: Inventory knows what is in each slot; VendingMachine coordinates the flow; a state (idle, has money, dispensing) decides which actions are allowed. Only the state and the stock rules need real design; the rest is plain code.

  The following lessons apply this method to well-known problems. Each ends with the extensions an interviewer is likely to ask for.

  Real-world reading

  Related reading

  • Apple Machine Learning BlogApple engineers · AppleBlogs
  • AWS Machine Learning BlogAmazon Web Services engineers · Amazon Web ServicesBlogs
  • Machine Learning for Indexing Text from Billions of Images at DropboxDropbox engineers · DropboxCase Studies
  • Optimizing Payments with Machine Learning at DropboxDropbox engineers · DropboxCase Studies

  Show 6 moreShow fewer

  • 8 Things You Need to Know Before a System Design InterviewGainlo engineers · GainloBlogs
  • CAP Twelve Years Later: How the Rules Have ChangedEric Brewer · InfoQBlogs
  • Deep Learning for Frame Detection in Product Images at AllegroAllegro engineers · AllegroCase Studies
  • Explaining Low-Level Systems (OS, Network/Protocol, Database, Storage)Wustl engineers · WustlBlogs
  • System Design Interview (checkcheckzz)checkcheckzz · GitHubGitHub
  • Top 10 System Design Interview QuestionsHackernoon engineers · HackernoonBlogs

  Open this lesson with its quiz and exercise