← All posts
general

System Design Interview Questions by Level: Mid to Staff

The same system design interview questions are asked at every level, and they are a different interview each time. "Design a URL shortener" asked of a mid-level engineer checks whether you can produce a working design with a sensible data model and talk about it clearly. Asked of a senior engineer, it checks whether you find the hard part (the redirect path at scale, key generation under contention) without being pointed at it. Asked of a Staff engineer, the shortener is a pretext; the interviewer wants to see how you decide whether to build it at all and what you tell the three teams that depend on it.

Most candidates fail by answering at the wrong altitude. A senior candidate who spends twenty minutes on the schema reads as mid-level. A mid-level candidate who opens with multi-region failover before stating a single requirement reads as someone reciting a video. This guide groups the common prompts by level, says what each one probes, and shows how the grading moves with seniority. It assumes you know the building blocks; if you do not, start with the system design prerequisites and the framework guide, then come back.

What changes with level

Level names vary by company. Roughly, mid-level is Amazon L5, Meta E4 or Google L4; senior is L6, E5 or L5; Staff is L7, E6 or L6, and some companies call the top band principal. Interviewers rarely say which bar they are grading against, so you set it yourself through the scope of your answer. The table is what candidates and interviewers consistently describe; no company publishes its rubric.

What changes Mid-level Senior Staff
What you are given Requirements, mostly; you confirm them A vague brief; you find the requirements An ambiguous goal or an organisational constraint; you decide what the problem is
Scale Stated numbers; you size storage and traffic from them You estimate, then design for an order of magnitude more You design for growth and for the migration path to get there
Failure modes Name them when asked Find them unprompted and design around the ones that matter Decide which failures are acceptable and say why
Data and consistency Pick a store and justify it Explain the consistency model and where it bends Reason about data ownership across teams and across years
Operations Mention monitoring and deployment Design for on-call: alerts, rollbacks, capacity Design for the team that will run it after you move on
Trade-offs State them Own them and defend one position Frame the decision for others and record it
Influence Communicate clearly with one interviewer Lead the conversation; push back when the interviewer is wrong Run the session like a design review you are chairing

Mid-level questions

These prompts have a well-known shape and the interviewer wants a complete design in 45 minutes: correct components, a data model you can defend, numbers in the right order of magnitude, and one deep dive where they choose. Depth in one area is a bonus, not the bar.

  1. Design a URL shortener. Probes key generation, the read-heavy redirect path, caching, and whether you size storage from the numbers given. Worked example in design a URL shortener.
  2. Design a rate limiter. Probes algorithm choice (token bucket, sliding window), where the limiter sits, and what happens to traffic when the limiter itself fails. Worked example in design a rate limiter.
  3. Design a key-value store behind an HTTP API. Probes the read and write paths, replication for durability, and whether you can state what happens on a node failure.
  4. Design a paste bin or a file-sharing service. Probes separating blob storage from metadata, expiry, access control, and the upload path for large files.
  5. Design a notification service for email, push and SMS. Probes queues, retries, idempotency, fan-out, and user preferences as data.
  6. Design a web crawler for a bounded set of sites. Probes the frontier queue, deduplication, politeness per host, and how you recover from a crash halfway.
  7. Design a leaderboard for a game with millions of players. Probes sorted structures, read against write patterns, top-N queries, and when an approximation is acceptable.
  8. Design a hotel or parking booking system. Probes data modelling and concurrency on a shared resource: the double-booking case and the transaction that prevents it.
  9. Design search autocomplete for one product. Probes prefix structures, precomputation, the latency budget, and how often the index can be rebuilt.
  10. Design a metrics pipeline for one service. Probes ingestion, aggregation windows, retention, and whether you know the difference between logs and metrics.

What passes at this level is a clear requirements list, a diagram the interviewer can read, estimates that are in the right order of magnitude, and a store chosen for a reason you can say out loud. What fails is skipping requirements to get to the drawing, a database picked by habit, and no numbers at all.

Senior questions

The prompt gets vaguer, the interviewer says less, and the grading moves to what you find on your own. You are expected to pick the hard part of the problem within the first ten minutes and spend most of the session there.

  1. Design a payment system. Probes idempotency, the ledger, reconciliation, and what exactly-once means in practice when a provider times out. Worked example in design a payment system.
  2. Design a chat system like WhatsApp. Probes persistent connections at scale, message ordering and delivery guarantees, presence, and group fan-out. Worked example in system design of WhatsApp.
  3. Design a ride-hailing service like Uber. Probes geospatial indexing, matching under a latency budget, and the write volume of location updates. Worked example in system design of Uber.
  4. Design a news feed. Probes fan-out on write against fan-out on read, the celebrity problem, ranking as a separate service, and cache invalidation.
  5. Design a distributed job scheduler. Probes leader election, at-least-once execution with idempotent jobs, clock skew, and what happens when a worker dies mid-job.
  6. Design a distributed cache. Probes consistent hashing, eviction, hot keys, replication, and the stampede when a popular key expires.
  7. Design an inventory system that must never oversell. Probes the consistency and availability trade-off made concrete: reservations, timeouts, compensating transactions.
  8. Design a video upload and streaming pipeline. Probes chunked upload, a transcoding workflow, storage tiers, and the CDN as part of the design rather than an afterthought.
  9. Design real-time fraud detection for payments. Probes stream processing, the features you need at decision time, the latency budget, and the cost of a false positive against a false negative.
  10. Design an API gateway for a company with two hundred services. Probes authentication, rate limiting, routing, observability, and the blast radius when the gateway itself degrades.

What passes at senior is finding the defining constraint unprompted (connections for chat, idempotency for payments, matching latency for rides), designing for it, and defending one position when the interviewer pushes. What fails is a textbook architecture with every box present and no opinion about which one will break first.

Staff questions

At Staff the prompt is often not a system. It is a situation: a migration, a cost target, a platform other teams must adopt, a data residency rule that arrived from legal. The interviewer is checking whether you can turn an organisational problem into a technical plan and back again, and whether you ask what the real goal is before you draw anything. The Staff engineer interview guide covers how the rest of the loop shifts at this level.

  1. Migrate a monolith that forty engineers ship to daily, without a freeze. Probes sequencing, the strangler pattern, what you measure to know it is working, and who decides the order when two teams disagree.
  2. Make this service multi-region when the data residency rules differ by country. Probes partitioning by jurisdiction, consistency across regions, failover, cost, and whether you ask what the rule actually says before designing for it.
  3. Design a platform other teams will build on, such as an internal event bus, a feature flag service or a model serving layer. Probes API stability, multi-tenancy, self-service onboarding, the migration path for teams already doing it their own way, and how you say no to a feature request.
  4. Halve the infrastructure cost of this system without reducing availability. Probes where cost lives, what to measure first, tiered storage, right-sizing, and which trade-off you would make visible to the business rather than absorb.
  5. Design the timeline infrastructure for a social product at Twitter scale, then say how you would evolve it over three years. Probes the design itself plus a roadmap: what you would build first, what you would defer, and what signal would change the plan. Reference design in in-depth system design of Twitter.
  6. Design video delivery and recommendations for a Netflix-sized catalogue, and decide what to build and what to buy. Probes CDN strategy, the encoding pipeline, and the build-or-buy reasoning for each component. Reference design in system design of Netflix.
  7. Two teams have built overlapping systems. Design the path to one. Probes the technical merge plan, data migration, which system survives and why, and the people problem you are expected to name without being asked.
  8. Our incident rate doubled this year. Redesign how reliability works here. Probes whether you ask why first, SLOs and error budgets, ownership, and which fixes are architecture and which are process.

What passes at Staff is restating the problem in a way the interviewer finds sharper than their own prompt, choosing a plan with explicit stages and exit criteria, and naming the organisational cost of each option. What fails is treating the prompt as a senior design question with bigger numbers.

How interviewers grade

Most companies approximate the same five dimensions, with weights that shift by level. Amazon folds the design round into leadership principle feedback (Dive Deep and Are Right, A Lot come up most), Meta grades named signals, and Google's interviewers write to a hiring committee; the underlying shape is still roughly this.

  • Requirements. Did you find out what the system is for, who uses it, how many, how fast, and what is out of scope. At mid-level this is confirming; at senior it is discovering; at Staff it is deciding.
  • High-level design. Does the design work end to end for the main path, and are the components there for a reason.
  • Deep dive. Can you take one component down to the level of failure modes, data layout and the specific choice you would make, and defend it.
  • Trade-offs. Did you name what you gave up with each decision, and does the trade match the requirements you stated. "It depends" with no position scores badly at every level.
  • Communication. Could the interviewer follow the design without asking you to repeat yourself, did you say what you were about to do before doing it, and did you notice when they were steering.

Interviewers usually write feedback immediately after the session and before talking to anyone, so the design you leave on the board is the design that gets graded. A strong deep dive does not rescue a high-level design with a missing component.

Running the 45 minutes

A time plan with checkpoints. If you miss a checkpoint by more than three minutes, cut the next section rather than the one after it.

  1. 0 to 5 minutes: requirements. Checkpoint: a written list of functional requirements, the non-functional ones that matter (latency, availability, consistency), and the scale numbers. Say what is out of scope.
  2. 5 to 10 minutes: estimates and API. Checkpoint: requests per second for the main paths, storage per year, and the two or three API calls the system exposes.
  3. 10 to 25 minutes: high-level design. Checkpoint: a diagram with every component the main path needs, data flow drawn for one request, and the store chosen with a reason.
  4. 25 to 38 minutes: deep dive. Checkpoint: one component designed to the level of failure modes and the specific choice you would make, with the alternative named. Ask the interviewer which component they want if they have not steered.
  5. 38 to 43 minutes: trade-offs and operations. Checkpoint: what you gave up, how you would monitor it, how you would roll it out, and what you would do with another week.
  6. 43 to 45 minutes: summary. Restate the requirements and how the design meets them. This is the last thing the interviewer hears before writing feedback.

The plan compresses with level. At senior, requirements take three minutes and the deep dive takes twenty. At Staff, you may spend the first ten minutes on framing the problem and arguing for a different one, and that is the right use of the time if you say that is what you are doing.

Failure patterns by level

  • Mid-level: drawing before asking. Opening with components and discovering the requirements from the interviewer's objections.
  • Mid-level: the database by habit. Choosing a store because it was in the last video, with no read or write pattern to justify it.
  • Mid-level: no numbers. A design with no idea whether it serves a hundred requests a second or a hundred thousand.
  • Senior: the complete textbook. Every box present, correct, and shallow; no opinion about which component breaks first and no deep dive anyone would remember.
  • Senior: agreeing with every steer. The interviewer suggests a change and the candidate adopts it without checking it against the requirements. Pushing back correctly is graded higher than agreeing.
  • Senior: consistency hand-waved. "Eventually consistent" said once, with no account of what the user sees in the window and whether that is acceptable.
  • Staff: a bigger senior answer. Treating the migration or the platform as a design question with larger numbers, and never mentioning the teams, the sequencing or the exit criteria.
  • Staff: strategy without a system. The opposite failure: fifteen minutes on organisational framing and no technical design the interviewer can grade.
  • Every level: silence. Thinking for two minutes without saying what you are thinking about. Interviewers grade what they hear.

Where coaching fits

Alone, the practice that works is written and timed: take a prompt from the list for your level, write a one-page design in 45 minutes against the clock, then read it the next day and mark it against the five grading dimensions above. Do five of these before any live practice. The free practice interview (free, sign in with LinkedIn) runs a system design round with an AI interviewer, optionally grounded in the job ad you paste, and gives a written recap of what worked and what to drill; it is a good way to find out whether your altitude matches the level before anyone human is watching.

Past that, a mock needs an interviewer who has graded at your level. A Staff mock run by someone who has only interviewed seniors will pass a senior answer. The system design coaches on this marketplace include Staff and Principal engineers and a VP of Engineering who have run these rounds at Amazon, Microsoft, Meta and others; one session with written feedback is usually enough to see which failure pattern above is yours.

Related guides