System design interview questions in 2026: real prompts, model answers, and how to score them

System design interview questions are open-ended on purpose: "design a URL shortener," "design a news feed." They test whether a candidate can take a vague problem, clarify it, estimate its scale, and reason through the trade-offs of a real architecture.

They are also the hardest interview to score consistently, because there is no single right answer, which is exactly why a rubric matters more here than in any other round. This guide gives you real prompts, a model answer for each, and a scoring rubric so you can tell a strong design from a confident one.

Most system design content teaches candidates a framework. Almost none helps the interviewer judge whether an answer is actually good. That is the gap this guide fills: the same prompts, but with the evaluation layer that lets a hiring manager or recruiter score an open-ended answer without being a distributed-systems expert.

A quick note on scope. This is a practical set of system design interview questions and answers built around a system design interview rubric. It runs from software engineer system design interview questions at mid-level up to system design interview questions for senior engineers, and every prompt is one of the worked system design interview questions with solutions that show the rubric in action.

Key Takeaways

• The strongest signal in a system design round is the first five minutes: a candidate who clarifies requirements and estimates load before drawing boxes is reasoning; one who jumps to a diagram is performing.

• Score against a frame, not a "right answer." Requirements, estimation, high-level design, deep dive, and trade-offs is the rubric that makes an open-ended round defensible.

• Level the same prompt. "Design a URL shortener" is a mid-level question about data modeling and a senior question about scaling reads and handling hot keys.

• Trade-off reasoning is the senior separator. The best candidates name what they are giving up (consistency for availability, latency for durability), not just what they are choosing.

• A structured, rubric-scored interview predicts performance far better than an unstructured one. Schmidt and Hunter put structured interview validity at about 0.51.

What system design interview questions actually test

A system design interview tests how a candidate handles ambiguity at scale. Given a deliberately vague prompt, can they ask the right clarifying questions, estimate the load, sketch a high-level architecture, go deep on the hard part, and reason honestly about trade-offs. It is less about knowing one canonical design and more about a defensible process applied out loud.

Because the prompts are open-ended, the questions below are paired with a scoring rubric rather than a single answer key. The rubric is what lets a non-specialist interviewer evaluate the round, because it names what a strong answer covers at each step versus where a weak one stalls.

The scoring framework: how to judge any design answer

Before the prompts, here is the frame to score against. A strong answer moves through these five steps, roughly in order, and a weak answer skips the early ones.

• Clarify requirements. Functional (what must it do) and non-functional (scale, latency, availability, consistency). Strong candidates pin these down before designing.

• Estimate the load. Rough numbers for users, requests per second, storage, and read-versus-write ratio. The estimate does not need to be precise; it needs to drive the design.

• High-level design. The major components and how data flows between them: clients, API layer, services, datastores, caches, queues.

• Deep dive. Go deep on the genuinely hard part (the data model, the hot path, the bottleneck), not the easy boxes.

• Trade-offs. Name what is being given up. Every real design sacrifices something, and naming it is the senior signal.

Use this as your rubric for every prompt below. The model answers are organized around it.

Mid-level system design questions

These test whether a candidate can structure a design and reason about data and scale at a basic level. A mid-level answer should hit requirements, a rough estimate, and a sensible high-level design.

Design a URL shortener. Clarify first: how many URLs per day, read-to-write ratio (very read-heavy), do links expire, do we need analytics. Estimate the scale to size storage and throughput. The core is a service that generates a short unique key (a base-62 encoding of an ID, or a hash with collision handling), stores the key-to-URL mapping in a datastore, and redirects on lookup. Because reads dominate, put a cache in front of the mapping. Scoring note: Strong answer clarifies the read-heavy ratio and adds a cache; reasons about key generation. Weak answer jumps straight to "store it in a database" with no estimation or caching.

How would you add a cache, and what do you cache? Cache the hot, read-heavy data that is expensive to compute or fetch, the URL mappings, a user's feed, a product page. Decide on an eviction policy (commonly least-recently-used) and a consistency approach (write-through or invalidate on update). The judgment is naming what you cache and how you keep it from going stale, not just "add Redis." Scoring note: Strong answer names what to cache, the eviction policy, and the staleness risk. Weak answer says "use a cache" with no policy or invalidation story.

SQL or NoSQL for this system, and why? It depends on the access pattern. A relational database fits structured data with relationships and transactional needs. A NoSQL store fits high write throughput, simple key-based access, or flexible schemas, and scales horizontally more easily. The senior move is matching the store to the query pattern, not naming a favorite. Scoring note: Strong answer ties the choice to access patterns and consistency needs. Weak answer picks one because it is "more scalable" without reasoning.

How do you scale reads when one database cannot keep up? Add read replicas to spread read load, and a cache layer to absorb the hottest reads. For writes that outgrow a single node, partition (shard) the data by a key so each shard handles a slice. Replication helps reads; sharding helps writes and storage. Naming which problem you are solving is the signal. Scoring note: Strong answer separates replication (reads) from sharding (writes/storage). Weak answer says "add more servers" without distinguishing the two.

Senior-level system design questions

These test depth and trade-off reasoning under harder constraints. A senior answer goes deep on the bottleneck and names what it sacrifices.

Design a news feed (for example, a social timeline). Clarify scale and freshness needs first. The core trade-off is fan-out on write (precompute each user's feed when someone posts, fast reads, expensive for high-follower accounts) versus fan-out on read (assemble the feed at request time, cheaper writes, slower reads). A strong answer uses a hybrid: precompute for most users, fall back to read-time assembly for celebrity accounts with millions of followers. Scoring note: Strong answer names the fan-out trade-off and handles the celebrity-account edge case. Weak answer describes a feed without the write-vs-read tension.

Explain the consistency-versus-availability trade-off and where you would choose each. Under a network partition, a distributed system cannot be both fully consistent and fully available (the CAP trade-off). For a banking ledger you favor consistency, refusing the operation rather than risking a wrong balance. For a social feed or a shopping cart you favor availability, serving slightly stale data rather than failing. The senior signal is choosing per use case and justifying it. Scoring note: Strong answer applies the trade-off to concrete cases with justification. Weak answer recites CAP as a definition without applying it.

How do you design for failure? Assume every component fails. Use redundancy and replication so no single node is critical, health checks and load balancers to route around failures, timeouts and retries with backoff so a slow dependency does not cascade, and graceful degradation so the system serves a reduced experience rather than nothing. The mindset is "what happens when this dies," asked of every box. Scoring note: Strong answer names cascading failure and degradation, not just "add redundancy." Weak answer assumes the happy path.

How would you shard a large dataset, and what breaks when you do? Choose a shard key that spreads load evenly and matches the common query, then route each request to the right shard. What breaks: queries that span shards become expensive, transactions across shards are hard, and a poorly chosen key creates hot shards. A strong answer names these costs, not just the mechanism. Scoring note: Strong answer names cross-shard queries and hot-key risk as costs. Weak answer describes sharding as a free scaling win.

Real prompts, scored: a worked example

To show the rubric in action, take "design a rate limiter." A strong candidate clarifies the limit (requests per user per window) and where it sits (per service, global). They estimate traffic to size the counter store. They propose an algorithm (token bucket or sliding window) and store counters in a fast in-memory store keyed by user.

They go deep on the race condition of two requests reading the same counter at once, and they name the trade-off: a centralized counter is accurate but adds latency, while a per-node counter is fast but approximate. A weak candidate names an algorithm and stops, never touching the race condition or the accuracy-versus-latency trade-off.

The difference between those two answers is not knowledge of rate limiters. It is whether the candidate applies the frame. That is what your rubric should reward.

How to evaluate a design answer when you are not a systems expert

If you are a recruiter or hiring manager who does not architect distributed systems, the five-step frame is your rubric. You do not have to know the "right" design; you have to notice whether the candidate clarified, estimated, went deep on the hard part, and named trade-offs. And the sharpest tool is the follow-up: "what breaks at ten times the load," "what are you giving up there." Real experience extends; memorization stalls.

This is the exact problem Expert Hire's AI interview platform is built to solve, and system design is where it helps most, because the round is the hardest to score by hand. It runs a structured design interview, asks the clarifying and trade-off follow-ups, and scores the answer against a published rubric, returning a scorecard with the transcript and the reasoning per step.

Structured, rubric-scored rounds predict performance far better than unstructured ones: Schmidt and Hunter put structured interview validity at about 0.51, and SHRM's 2026 State of AI in HR report finds most HR teams using AI in recruiting report meaningful time savings. The scoring methodology is open, and it is the same rubric logic behind every bank in our question library. Pair it with AI candidate shortlisting so the strongest designers reach the panel.

How to practice these as a candidate

Do not memorize canonical designs, practice the process. For any prompt, force yourself to clarify requirements, estimate load, sketch the high-level design, go deep on one hard part, and name a trade-off, out loud and on a clock. Then get follow-ups, because a real interviewer will push on scale and failure.

Run a timed system design mock interview or use Expert Hire's practice interviews, and prep the coding round alongside it with the sibling banks: Python interview questions and SQL interview questions.

Frequently asked questions

What system design questions should senior engineers expect? Senior candidates should expect open-ended prompts (design a news feed, a chat system, a rate limiter) with heavy follow-up on scaling, the consistency-versus-availability trade-off, failure handling, and sharding. The bar is trade-off reasoning: naming what you give up, not just what you choose.

How do you answer a system design question with no single right answer? Use a frame: clarify requirements, estimate the load, sketch a high-level design, go deep on the hard part, and name the trade-offs. Interviewers score the process, so making that process explicit and reasoning out loud matters more than landing on one canonical architecture.

What is the most common mistake in a system design interview? Jumping straight to a diagram without clarifying requirements or estimating scale. The design that follows is then ungrounded. Strong candidates spend the first few minutes pinning down what they are actually building and for what load.

Can a non-technical recruiter run a system design screen? Not by judging the architecture directly, but yes with a rubric or an AI interviewer that scores against one. The five-step frame lets a non-specialist see whether the candidate clarified, estimated, went deep, and named trade-offs, which is the evaluable part.

How many system design questions fit in one round? Usually one prompt with deep follow-up, sometimes two. Depth beats breadth: a single prompt explored to its trade-offs reveals more than three shallow ones. That is why a structured, rubric-scored round outperforms a rushed checklist.

The bottom line

The best system design interview is not a harder prompt, it is a clear rubric applied to an open-ended one. The candidates worth hiring clarify before they design, estimate before they commit, and name what they are giving up. Score the process, follow up on scale and failure, and the strong answers separate themselves from the confident ones.

If you want to see what a structured, rubric-scored design round looks like, look at a sample candidate scorecard and decide whether the per-step reasoning is something you would trust to advance a senior engineer. That is the difference between an open-ended question and an actual evaluation.

• By TK, Growth at Expert Hire. Last updated June 30, 2026. Reviewed by Anand Suresh, CPO at Expert Hire.