{"title":"Expectations by Experience Level","description":"","content":"A system design interview is not graded on one universal scale.\n\nThe same answer that works for a new grad may feel too shallow for a senior engineer. As the level goes up, interviewers expect you to handle more ambiguity, make better trade-offs, reason through failures, drive the discussion with less help, and connect technical decisions to real operational and business constraints.\n\nThis chapter explains what a strong system design answer looks like at each level, from new grad to staff, and how your approach should change based on the level you are targeting.\n\n---\n\n# 1. Why the Same Question Is Scored Differently\n\nMost companies have an internal career ladder. The titles differ, but the pattern is similar: as engineers become more senior, they are expected to own larger systems, work with less guidance, handle more ambiguity, and make stronger trade-offs.\n\nSo when two candidates get the same problem, the real question is not just: “Can they design a working system?”. It is: “Can they design it at the depth expected for their level?”\n\nA new grad may pass by showing good fundamentals and a reasonable high-level design. A senior engineer is expected to go further: identify bottlenecks, discuss failure modes, justify trade-offs, and show ownership of the system beyond the happy path.\n\nThe titles vary across companies, but the common mapping roughly looks like this:\n\n\n| Rung | Google | Meta | Amazon | Microsoft |\n|---|---|---|---|---|\n| Entry / New Grad | L3 (SWE II) | E3 | SDE I | SDE |\n| Mid-Level | L4 (SWE III) | E4 | SDE II | SDE II |\n| Senior | L5 (Senior SWE) | E5 (Senior) | SDE III (Senior SDE) | Senior SWE |\n| Staff+ | L6+ (Staff and above) | E6+ (Staff and above) | Principal SDE | Principal SWE |\n\n\nTreat this table as approximate. Company ladders change, and the same title can mean different things depending on the team, org, and hiring bar. What matters is the expectation pattern.\n\nFull system design rounds are most common from mid-level upward. New grad and junior interviews often skip them, or include a lighter design discussion inside another round, because early-career engineers are not usually expected to have owned large production systems yet.\n\n---\n\n# 2. The Dimensions That Scale With Level\n\nSeniority in a system design interview is not about adding more boxes to the diagram. It shows up in a few specific dimensions that each grow as you go up the ladder.\n\n\n```mermaid\nflowchart LR\n A[Breadth
cover the
whole system]:::primary\n B[Depth
go deep on
the hard parts]:::orange\n C[Autonomy
drive vs
be guided]:::teal\n D[Trade-offs
justify every
decision]:::green\n E[Ambiguity
turn vague
into concrete]:::rose\n F[Scope
see beyond
the happy path]:::lightblue\n\n A --> B --> C --> D --> E --> F\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef rose fill:#f783ac,stroke:#000,color:#000\n classDef lightblue fill:#3bc9db,stroke:#000,color:#000\n```\n\n\n**Breadth** means covering the system end to end: clients, APIs, services, storage, data flow, and the read/write paths.\n\n**Depth** means going beyond surface-level components. Anyone can say \"add a cache.\" Depth is explaining what you cache, where, how misses behave under load, how invalidation works, and what happens when the cache goes down.\n\n**Autonomy** is how much help you need. Stronger candidates move through requirements, high-level design, bottlenecks, and deep dives without being prompted at every step. They still collaborate, but they do not need the interviewer to carry the session.\n\n**Trade-off reasoning** is explaining choices, not just naming technologies. \"I'll use Cassandra\" is a decision. \"I'll use Cassandra over PostgreSQL because the access pattern is high-volume key-based lookups with no joins or multi-row transactions\" shows reasoning.\n\n**Handling ambiguity** is turning a vague prompt into a concrete problem. A prompt rarely hands you scale, consistency needs, latency targets, or feature scope, so a strong candidate asks the right questions and makes reasonable assumptions.\n\n**Scope** is how far beyond the core feature you can see. At lower levels the focus is the happy path. Higher up, a strong answer also weighs failures, abuse, cost, operations, observability, migrations, and how the system fits into the larger product.\n\nThe same six dimensions apply at every level. What changes is how many you cover and how deep you go on each, as the matrix below summarizes.\n\n\n| Dimension | Junior | Mid-Level | Senior | Staff+ |\n|---|---|---|---|---|\n| Breadth | Covers core components with guidance | Covers the full happy path | Covers the full design independently | Covers the system plus adjacent systems |\n| Depth | Explains concepts | Goes deep on one important component | Goes deep on two or three critical areas | Goes deep where the largest risks are |\n| Autonomy | Needs step-by-step guidance | Drives with occasional nudges | Drives the session end to end | Drives and reshapes the problem |\n| Trade-offs | Names possible options | Justifies main choices | Compares trade-offs clearly | Connects choices to business, cost, and long-term impact |\n| Ambiguity | Responds when asked | Asks the key clarification questions | Sets scope proactively | Challenges weak assumptions when needed |\n| Scope | Focuses on the happy path | Covers the happy path plus basic failures | Covers scale, failures, and bottlenecks | Covers failure, abuse, cost, operations, and organization impact |\n\n\nThe rest of this chapter walks through each level, then uses one problem to show how the answer changes as the bar goes up.\n\n---\n\n# 3. Level-by-Level Expectations\n\nThis section describes what a strong answer looks like at each level and what is usually missing. These are patterns, not rigid rules, since interviews vary by company, interviewer, and role.\n\n## 3.1 Junior and New Grad\n\nAt the entry level, the bar is not a highly scalable distributed system. It is understanding the basic building blocks and reasoning through a simple design with some guidance. The focus is on correctness, clarity, and structure.\n\n\n### Strong Answer\n\n- A simple end-to-end flow, such as client → API → service → database.\n- Correct use of basic components, like a database for persistence, a cache for faster reads, and a load balancer when there are multiple servers.\n- A reasonable data model with the main entities and relationships.\n- Clear thinking out loud, especially when you are unsure.\n- Willingness to start simple instead of over-engineering too early.\n\n### Common Mistakes\n\n- Drawing components before clarifying what the system needs to do.\n- Adding advanced components like Kafka, Kubernetes, sharding, or microservices without a real need.\n- Memorizing a design instead of explaining why each part exists.\n- Going quiet when stuck instead of walking through your thought process.\n\n\n## 3.2 Mid-Level\n\nAt mid-level, the answer should reflect experience with real production systems. You do not need to design everything perfectly, but you should be able to take a vague question, clarify the scope, estimate the scale, and produce a complete working design with limited help.\n\n\n### Strong Answer\n\n- A quick requirements pass that separates functional and non-functional needs.\n- Basic capacity estimates, such as requests per second, read/write ratio, and storage growth.\n- A complete high-level design that covers the main read and write paths.\n- Clear explanation of the main components and why they are needed.\n- One important component explored in depth, such as caching, indexing, database schema, or queue processing.\n- Trade-offs behind the main choices, instead of only naming technologies.\n\n### Common Mistakes\n\n- Designing for scale without first estimating what the scale actually is.\n- Listing tools like Redis, Kafka, Cassandra, or Kubernetes without tying them to a requirement.\n- Covering only the write path and forgetting the read path, or the other way around.\n- Stopping at the first workable design without discussing what breaks as traffic grows.\n- Treating trade-offs as a checklist instead of explaining the actual decision.\n\n\n## 3.3 Senior\n\nAt senior level, the answer should reflect having owned systems, not just implemented features inside them. A strong senior answer does not stop at a working design. It explains where the design will struggle, which parts need deeper thought, what trade-offs are being made, and how the system behaves when things fail. The focus is on judgment, depth, and ownership.\n\n\n### Strong Answer\n\n- Proactive scoping: clearly stating assumptions, defining what is in and out, and confirming the direction before going deep.\n- A complete design that covers the main flows, not just isolated components.\n- Two or three deep dives into the riskiest parts of the system.\n- Clear trade-offs between realistic alternatives, with a recommendation.\n- Numbers that support the design, such as request rate, storage growth, cache hit rate, or replication needs.\n- Failure handling as part of the design, not something added at the end.\n- Awareness of bottlenecks like hot keys, slow queries, overloaded queues, failed replicas, or regional outages.\n\n### Common Mistakes\n\n- Spending the whole interview on the high-level diagram and never going deep.\n- Naming alternatives without explaining why one is better for this problem.\n- Designing only for the happy path.\n- Adding scale-related components without explaining what bottleneck they solve.\n- Waiting for the interviewer to ask about failures, trade-offs, or bottlenecks.\n\n\n\n> **TIP**\n>\n> At senior level and above, a useful habit after the happy-path design is to ask: “What breaks first as this grows?”\n>\n> Then design around that failure point. This is often what moves an answer from a decent system sketch to a strong senior-level discussion.\n\n\n## 3.4 Staff and Above\n\nAt staff level and above, the answer has to go beyond the system diagram. The question is no longer just \"Can you design a working system?\" It is also \"Can you shape the problem, identify the real constraints, and make decisions that hold up across teams, products, and years of operation?\"\n\nA strong staff-level answer still includes the core architecture, but it also connects that architecture to cost, reliability, abuse, migration, ownership, and business goals.\n\n\n### Strong Answer\n\n- Ability to question the premise, narrow the scope, or reshape the problem when the requirements are unclear or unrealistic.\n- Clear connection between technical choices and business constraints, such as cost, compliance, retention, latency, or availability.\n- Awareness of adjacent systems: where the data comes from, who consumes it, and what contracts need to exist.\n- Failure, abuse, cost, and operations treated as core design concerns.\n- Practical thinking about rollout, migration, monitoring, ownership, and long-term maintenance.\n- Judgment about what not to build, not just what to build.\n\n### Common Mistakes\n\n- Staying only at the technical component level and never discussing cost, risk, or operations.\n- Accepting weak or unrealistic requirements without pushing back.\n- Over-polishing one part of the design while ignoring migration, ownership, or failure handling.\n- Designing something impressive but too expensive or too complex for the actual problem.\n- Forgetting that real systems are maintained by teams, not by diagrams.\n\n\n---\n\n# 4. Same Question, Four Answers\n\nThe easiest way to understand level expectations is to keep the problem the same and change only the bar.\n\nIn this section, we will use the question: **“Design a URL shortener.”**\n\nThe core system is the same each time: users create short links, and others follow those links to reach the original URLs. What changes across levels is the depth of reasoning, the trade-offs discussed, the failure cases considered, and how much of the surrounding system the candidate thinks about.\n\nTo keep the numbers consistent across all four, assume the following scale for the mid-level answer and above.\n\n\n> **NOTE**\n>\n> #### Assumptions:\n>\n> - New short URLs created per day: **10 million**\n> - Redirects (reads) per day: **1 billion**\n> - Read/write ratio: **100:1**\n> - Data retained for: **5 years**\n\n\nFrom those inputs, the derived load is:\n\n- Write QPS: 10,000,000 ÷ 86,400 ≈ **116 writes/sec**, with a 3x peak factor ≈ **350 writes/sec**.\n- Read QPS: 1,000,000,000 ÷ 86,400 ≈ **11,600 reads/sec**, peak ≈ **35,000 reads/sec**.\n- Storage: 10M/day × 365 × 5 years ≈ **18 billion records**. At roughly 500 bytes each (short code, long URL, metadata), that's about **9 TB** before replication.\n\nThis is a read-heavy system with moderate write volume and large long-term storage needs, and that imbalance shapes most of the design. The redirect path must be fast and highly available. The write path can be simpler, but it still needs safe ID generation, collision handling, and durable storage.\n\nAs we move up the levels, the answer should reflect more of those realities.\n\n\n

The Junior Answer

\n\nA junior answer focuses on building a simple, correct system. It identifies the two core operations: create a short URL and redirect a short URL to the original URL.\n\n\n```plaintext\nPOST /urls { \"longUrl\": \"https://...\" } -> { \"shortCode\": \"aB3xY\" }\nGET /{shortCode} -> 301 redirect to longUrl\n```\n\n\nThe storage can be a single table that maps each `shortCode` to its `longUrl`. The short code could be generated from an auto-incrementing ID or a random string. For reads, a cache can sit in front of the database because popular links may be opened many times.\n\n\n```mermaid\nflowchart LR\n A[Client]:::primary --> B[URL Service]:::orange\n B --> C[(Cache)]:::teal\n B --> D[(Database)]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThis is a good entry-level answer. It is easy to understand, handles the happy path, and shows the candidate knows how requests, storage, and caching fit together. What is missing is scale: how large the database becomes and what breaks when traffic grows. That is acceptable here, since the goal is clear thinking and a correct basic design.\n

\n\n

The Mid-Level Answer

\n\nA mid-level answer starts by clarifying the requirements before designing anything.\n\nFor a URL shortener, useful questions include: Should the same long URL always produce the same short code? Do links expire? Are custom aliases allowed? Do we need click analytics?\n\nOnce the scope is clear, the candidate uses the given numbers to size the system.\n\nThe key signal is the read/write ratio. With 10 million new URLs per day and 1 billion redirects per day, this is clearly a read-heavy system. That should shape the design.\n\nThe mid-level answer makes a few deliberate choices:\n\n\n| Decision | Choice | Reason |\n|---|---|---|\n| ID generation | Counter + base62 | Gives unique short codes without collision handling |\n| Database | Key-value store | Redirects are simple lookups by `shortCode` |\n| Read scaling | Replicas + cache | Reads dominate writes by roughly 100:1 |\n| Redirect type | 301 vs 302 | 301 is cache-friendly, 302 is better if click tracking matters |\n\n\nFor ID generation, a counter with base62 encoding is a simple and reliable choice. It avoids the collision problem that comes with hashing or random generation. Each generated ID maps to one short code.\n\nFor storage, the access pattern is simple: given a `shortCode`, return the `longUrl`. This does not require joins or complex queries, so a key-value store is a good fit.\n\nFor reads, the design adds a cache in front of storage because popular links are likely to be opened repeatedly. A read-through or cache-aside strategy works well here. On a cache miss, the service reads from the database and stores the result in cache with a TTL.\n\nThis is also a good place to go one level deeper. Since the mapping from `shortCode` to `longUrl` usually does not change after creation, cache invalidation is simple. Stale reads are not a major concern unless the system supports link deletion, expiration, or editing.\n\nThis is a strong mid-level answer: complete, sized, and justified, covering both paths and going deeper on one component.\n\nWhat keeps it from senior-level is that it stays on the happy path, leaving failures, hot keys, abuse, and retention unexplored.\n

\n\n

The Senior Answer

\n\nA senior answer includes the mid-level design, but it does not stop there. It identifies the parts most likely to fail or become bottlenecks, compares alternatives, and explains the trade-offs clearly.\n\nThe first deep dive is **ID generation**.\n\nA single global counter is simple, but it can become a bottleneck and a single point of failure once many application servers are creating URLs at the same time. At around 350 writes per second at peak, the system does not need an exotic solution, but it does need a reliable one.\n\n\n| Approach | Pros | Cons |\n|---|---|---|\n| Single database counter | Simple, easy to reason about | Bottleneck, single point of failure |\n| ID ranges per server | No coordination on every write | Unused IDs are lost if a server dies |\n| Hash of long URL | No central coordination | Collisions need detection and retry |\n| Pre-generated key service | Decouples key creation from writes | Extra service to build and operate |\n\n\nA practical senior-level recommendation is to allocate ID ranges to application servers. Each server reserves a block of IDs from a central source, then generates short codes locally using base62 encoding.\n\nThis avoids coordination on every write while still keeping IDs unique. The trade-off is that some IDs may be skipped if a server crashes before using its full range. For a URL shortener, that is fine. Short codes do not need to be gap-free.\n\nThe second deep dive is the **read path under hot keys**.\n\nThe average peak read load is around 35,000 redirects per second, but traffic will not be evenly distributed. A celebrity, news article, or viral campaign can send a large share of traffic to one short link. That can overload the cache node responsible for that key.\n\nA senior answer calls this out and designs for it. Common options include replicating hot keys across cache nodes, using local in-memory caching for extremely hot mappings, or serving very hot redirects from the CDN edge so the request does not always reach the origin.\n\nThe third deep dive is **analytics**.\n\nThis starts with an important correction: if the service uses a `301` redirect, browsers may cache the redirect, which means repeat clicks may never hit the server again. That is good for performance, but bad for accurate click tracking.\n\nIf analytics matter, the service should usually use a `302` redirect so each click reaches the backend. But the redirect path is the hottest path in the system, so click counting should not happen synchronously.\n\nInstead, the URL service should emit a click event to a queue and return the redirect quickly. A separate analytics consumer can process those events and write them to an analytics store. If analytics falls behind, redirects should still work.\n\n\n```mermaid\nflowchart LR\n A[Client]:::primary --> B[Load Balancer]:::teal\n B --> C[URL Service]:::orange\n C --> D[(Cache)]:::teal\n C --> E[(Key-Value Store)]:::green\n C -- click event --> F[Queue]:::pink\n F --> G[Analytics Consumer]:::orange\n G --> H[(Analytics Store)]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef pink fill:#da77f2,stroke:#000,color:#000\n```\n\n\nThis is a strong senior answer because it drives the discussion beyond the happy path, covering ID generation, hot keys, cache behavior, redirect semantics, analytics, and failure isolation. It is still centered on making this one system work well.\n\nA staff-level answer also asks how the system fits into the larger product, how it is abused, how much it costs, and how it evolves over time.\n

\n\n

The Staff+ Answer

\n\nA staff-level answer includes the senior design, then steps back and asks what changes the shape of the problem.\n\nThe first question is retention. Should short links live forever, or should they expire?\n\nThat decision has real consequences. If most links receive traffic only in the first few days or weeks, old mappings can be moved to cheaper storage or deleted after a defined period. That can reduce cost significantly. But if the product promises permanent links, the system must support long-term storage as an explicit requirement, not an assumption.\n\nAbuse is also a core part of the design. A URL shortener can easily be used for phishing, spam, and malware distribution. A staff-level answer should include link scanning at creation time, rate limits on link creation, abuse detection, and a way to block or take down malicious links. At this scale, abuse handling is not an optional add-on. It is part of the product.\n\nCost and operations matter too. With roughly 18 billion records and 9 TB of raw data before replication, storage choices affect the budget. A staff-level answer should discuss whether old links belong in a cheaper storage tier, what latency trade-off that introduces, and whether the added operational complexity is worth it.\n\n> A retention and cold-storage policy can reduce the cost of storing billions of links. The trade-off is extra complexity: tiering jobs, slower reads for cold links, and a product decision about whether links are allowed to expire.\n\nThe operational story should also be clear. Who owns this service? How is the key-generation system monitored? What alerts fire when redirect latency increases? What happens when the cache is unavailable?\n\nFinally, the staff answer connects the URL shortener to the systems around it. Click analytics may feed dashboards, billing, or marketing tools. The creation API may be used by mobile apps, internal tools, and external partners. Abuse detection may depend on shared security infrastructure. These contracts need to be stable because other teams build on top of them.\n\nAt this level, the URL shortener is not treated as an isolated diagram. It is treated as a real production service that has to survive cost pressure, abuse, incidents, migrations, and changing product needs.\n

\n\n\n---\n\n# 5. Summary\n\nThe same system design question is judged differently at each level. A junior, mid-level, senior, and staff engineer may get the same question, but the expected answer is not usually the same.\n\nAs the level rises, the bar moves toward more ownership, less guidance, stronger trade-offs, and better handling of ambiguity, along the six dimensions: breadth, depth, autonomy, trade-offs, ambiguity, and scope.\n\nEach level adds a different signal:\n\n- Junior: simple, correct design\n- Mid-level: sized design with justified choices\n- Senior: deep dives into risks, scale, and failures\n- Staff+: cost, abuse, operations, ownership, and adjacent systems\n\nThe best way to practice is to take one problem, answer it out loud at your target level, and then push beyond the happy path into the parts of the system that carry real risk.","pageType":"system-design-interviews"}

Get Premium