Skip to main content

How I approach system design interviews

When people say “a system design interview should just feel like a conversation”, I fundamentally disagree.

Yes — it’s conversational in format, but it’s not just a free-flowing chat.
If you actually have experience building systems, you already know the tradeoffs and guarantees —
but none of that will come through unless you have a clear structure for communicating it.

Over time I've realized that there are three things I need to have prepared before going into a system design interview:

1. The Checklist — make the full space visible​

At the start of the interview I literally write out the categories I want to cover (either on a whiteboard or in the notepad / code editor if it’s virtual).
This serves two purposes:

  1. It signals to the interviewer that I know what needs to be considered.
  2. It keeps me from getting stuck going too deep in one area (e.g., scalability) and never coming back to the others.

I don’t use the classic “functional vs non-functional requirements” labels — I think that split is artificial and not how engineers actually reason in practice.
Instead I frame it in terms of:

Product Scope

  • API surface / what operations are supported
  • Expected payloads (what does the request look like; what entities are involved)
  • Usage patterns
    • burst scenarios (this is describing the event itself e.g. celebrity tweet, the numbers are discussed in system guarantees)
  • In-scope vs out-of-scope use cases
    • e.g. query patterns / filtering to support

System Guarantees

  • Scalability – expected request rate (QPS), per region — and if no numbers are given, I explicitly ask for them
    • Burst handling capability -
  • CAP tradeoff – consistency vs availability (what’s more important? think back to product scope)
  • Latency / response times – Response time SLAs
  • Auth / access control – do we handle it or does a downstream service?
  • Interactive vs analytics workloads – (are we supporting both, or just user-facing queries?)
  • Failure handling / system health / auto-scaling - (remember to touch back to this for each component)

(Yes — this maps roughly to what people mean by “functional” and “non-functional” requirements. I’m intentionally using different labels because I think “product scope” and “system guarantees” are more intuitive and lead to better questions.)

2. The Timer — switch to solution mode​

Once I’ve written the checklist, I start asking clarifying questions — but I time-box that phase.

After ~13–15 minutes (max), I transition to drawing boxes and designing the actual architecture, even if not every single detail is fully clarified.
The reason is simple: in the real world you could spend hours diving into details, but in an interview we are severely restricted on time, every minute matters.

3. Pre-Canned Buckets — communicate depth without analysis delay​

Certain questions come up so often that it’s not worth generating the answer in real time (it takes too long and the interviewer doesn’t wait).
Instead, I prepare "bucketized" tradeoffs ahead of time so I can immediately articulate the reasoning.

Example: Database Choice (anchored in 4 axes)​

There are four main things we need to consider when choosing a database:

1. Data model — is it relational or non-relational?​

  • Relational → normalized schema, joins, ACID transactions.

  • Non-relational →

    • Document (denormalized, flexible schema, doc-local access)
    • Key-value (simple lookups, caching, session/state)
    • Wide-column (Cassandra-style, partition-oriented)
    • Time-series (optimized for inserts + range queries)
    • Graph (relationship traversals, N-hop queries)

2. Workload — what’s the dominant pattern?​

  • OLTP vs OLAP

    • OLTP → many small, latency-sensitive reads/writes.
    • OLAP → large scans, aggregates, analytics queries.

  • Read vs Write intensity

    • Read-heavy → lots of point lookups, low write volume (B-trees shine).
    • Write-heavy → high ingest rates (logs, events, IoT), eventual compaction okay (LSM trees shine).
    • Mixed workloads → relational with tuned indexing, caching layers, or splitting responsibilities.

3. Storage / index mechanics — what’s under the hood?​

  • B-trees (Postgres, MySQL default) → balanced read/write, great for point lookups and range scans, supports many secondary indexes.

  • LSM trees + SSTables (RocksDB, Cassandra, Dynamo internals) → write-optimized, sequential flushes, compaction-heavy; need Bloom filters and indexes to accelerate reads.

  • Hash indexes (common in KV stores like Redis, some Postgres hash indexes) → O(1) equality lookups, extremely fast for “key → value” patterns.

    • Downside: no support for range scans. You need an ordered structure (B-tree, LSM with sorted SSTables) if you want range queries.
    • Many KV systems therefore combine hashing (for direct lookups) with ordered tables or skip lists (for ranges). For example, RocksDB uses LSM + Bloom filters for range support.

Quick mapping​

  • Equality lookups (point get by key) → Hash index / KV store.
  • Range scans (WHERE id BETWEEN …) → Ordered index (B-tree or SSTable).
  • Write-heavy logs/events → LSM + SSTables.
  • Mixed read/write transactional workloads → B-tree-based systems.

4. Durability / Persistence Model — how does it survive crashes?​

  • Write-ahead logging (WAL) → Postgres, MySQL; fsync guarantees, strong crash recovery, higher latency.
  • Append-only log + compaction → LSM systems; durability comes from replication + sequential disk writes.
  • In-memory + optional persistence → Redis (AOF snapshots, or none at all), Memcached (none).
  • Distributed log as source of truth → Kafka, Pulsar; downstream rebuilds state.

Interview-ready summary​

“When I choose a database, I ground it in three axes: data model, workload, and storage mechanics — and I always keep durability in mind as a fourth. If I need strict transactions and mixed workloads, I default to relational OLTP with JSONB. If it’s analytics-heavy, I split into a columnar OLAP store. If it’s write-heavy at scale, I lean toward LSM/SSTable systems. For pure key lookups, hash-based KV stores or Redis make sense. For durability, I balance WAL fsync vs replication tradeoffs depending on whether survival or latency is paramount. In short: model, workload, storage — and don’t forget durability.”

This way, no matter how the interviewer phrases the question, you’ve got a repeatable lens:

Final Thoughts​

System design interviews aren’t a trivia test. The challenge isn’t knowing what to do — it’s communicating what you already know in a structured way.

✔️ The Checklist makes the full problem space visible
✔️ The Timer keeps you from getting lost in discovery
✔️ The Pre-Canned Buckets let you show depth without stalling

If you already have experience building systems, this structure makes sure that experience actually shows up in the interview.