EngMock Logo
EngMock.com

🏗️ System Design guide

How to run a high-quality System Design interview

A timed, six-phase conversation where you own the architecture and defend every trade-off.
Start a System Design mockAll guides

What this interview tests

  • Whether you can turn a vague product prompt into a bounded, measurable problem.
  • Whether your architecture follows from stated requirements and scale, not from memorized diagrams.
  • Whether you understand what breaks in production and how you would detect and contain it.
  • Whether you can defend a decision under pressure and change it when given new information.

How the session is set up

  • Voice conversation with an interactive whiteboard you control.
  • You draw the architecture. The interviewer will only draw if you explicitly ask and then confirm.
  • Whatever the interviewer draws is clearly labeled as its own scaffold and never counted as your work.

The enforced phase timeline

The interviewer moves through these phases in order and never skips backwards. Percentages show the intended share of the session; minutes assume a 45-minute interview.

1

Functional Requirements

8% · ~4 min

Goal: Agree on the core user flows the system must support, in your own words.

Strong signals

  • You list the two or three flows that define the product and explicitly defer the rest.
  • You ask who the users are and what the primary read and write paths look like.
  • You confirm scope with the interviewer before moving on.

Common mistakes

  • Jumping into databases, caches, or queues before scope is agreed.
  • Listing twenty features and committing to designing all of them.
  • Treating the prompt as fully specified and asking nothing.
2

Non-Functional Requirements

10% · ~5 min

Goal: Turn quality attributes into numbers you will design against.

Strong signals

  • You give target latency, availability, consistency, and durability with concrete values.
  • You state which requirement dominates the design and why.
  • You distinguish requirements per flow instead of applying one blanket SLO.

Common mistakes

  • Saying "it should be scalable and highly available" with no numbers.
  • Claiming strong consistency everywhere without acknowledging the cost.
  • Skipping this phase and retrofitting requirements to justify a design later.
3

Back-of-the-envelope Estimation

10% · ~5 min

Goal: Size the system enough to justify later storage, cache, and partitioning decisions.

Strong signals

  • You derive QPS, storage growth, and bandwidth from stated assumptions.
  • You round aggressively and explain why the magnitude is what matters.
  • You connect a number to a decision, for example cache size to hit rate.

Common mistakes

  • Producing precise numbers that never influence any later decision.
  • Estimating without stating the assumptions behind the inputs.
  • Spending ten minutes on arithmetic instead of design.
4

API & Data Model

12% · ~5 min

Goal: Define the contract and the data before the boxes and arrows.

Strong signals

  • You specify the key endpoints or operations with their inputs and outputs.
  • You choose a partition key and explain the access patterns it serves.
  • You call out where denormalization or an index is required and why.

Common mistakes

  • Naming a database product before describing the entities and access patterns.
  • Ignoring idempotency, pagination, or authentication on write-heavy APIs.
  • Designing a schema that cannot serve the flows you just agreed on.
5

High-Level Design

25% · ~11 min

Goal: Draw an end-to-end architecture where every component exists for a stated reason.

Strong signals

  • You show the read path and write path separately and label the important arrows.
  • You keep the latency-critical path lean and push non-essential work to async paths.
  • Each component maps back to a requirement or an estimation result.

Common mistakes

  • A generic client → service → database sketch with no labels.
  • Adding a queue, cache, or CDN because it is expected rather than needed.
  • Narrating the diagram without ever explaining the data flow.
6

Deep Dives, Reliability & Trade-offs

35% · ~16 min

Goal: Go deep on the parts that carry the real risk, and show you understand failure.

Strong signals

  • You pick the hardest component yourself instead of waiting to be directed.
  • You reason about hot keys, partition skew, replication lag, and backpressure.
  • You explain what happens on regional failure, cache loss, or a poison message.
  • You name the monitoring signal that would tell you the system is degrading.

Common mistakes

  • Running out of time because earlier phases were over-elaborated.
  • Describing happy-path scaling only, with no failure analysis.
  • Answering "how would you improve this?" with more features instead of more resilience.

The bar at each level

This is the exact calibration the interviewer and the final report use for System Design.

Junior

A coherent client, service, and data-store design covering the core functional requirements, communicated clearly. Advanced distributed-systems internals are not required to pass.

Mid

A working multi-component design with functional and non-functional requirements, basic estimation, one meaningful deep dive, and awareness of common failure modes and trade-offs.

Senior

Independent problem framing, explicit scale assumptions, a production-ready architecture, multiple deep dives, failure handling, and trade-offs you can defend under challenge.

Staff

You drive ambiguity resolution and reason across multi-region reliability, organizational boundaries, cost, migration paths, operability, and long-term platform trade-offs. Expect harder cross-cutting follow-ups.

What a high-quality session looks like

  • Requirements first, always. The strongest candidates spend the opening minutes narrowing, not expanding.
  • Every box on the whiteboard should be traceable to a requirement or a number you produced.
  • Depth beats breadth. One rigorous deep dive outscores five shallow components.
  • Talk about failure unprompted. Production experience shows up in what you worry about.
  • Time-box deliberately. Say "I will keep this simple for now and revisit it in the deep dive."

Red flags that sink interviews

  • Choosing technologies by name recognition instead of by access pattern.
  • Synchronously updating a single hot row or counter on every request.
  • A single global component with no failover or partitioning story.
  • Silence while drawing, so the interviewer cannot follow your reasoning.
  • Defending a decision by authority ("everyone uses Kafka") rather than by requirement.

Readiness checklist

A mock is most useful when the basics are already in place. If several of these are shaky, study first — the session is meant to test performance, not teach fundamentals.

  • You can describe what a load balancer, cache, message queue, and replica do, and when each hurts.
  • You are comfortable estimating QPS and storage from user counts.
  • You know the difference between strong and eventual consistency, and can name a case for each.
  • You have read through at least one full worked design end to end.

Where to study the fundamentals

EngMock does not try to replace these. They are the references we would point a candidate to before a real loop.

System Design Primer ↗

Broad open-source reference covering the building blocks and classic designs.

Designing Data-Intensive Applications ↗

The standard book for replication, partitioning, consistency, and stream processing.

AWS Architecture Center ↗

Vendor reference architectures useful for seeing how real systems are composed.

Google SRE Book ↗

Best free source on SLOs, failure handling, and operability — the deep-dive phase.

Other guides

⌨️Coding / DSA🧩OOD🤖AI-Assisted Coding