Study guide 03 of 183

"What interviewers expect at mid, senior and staff levels"

How system design interviews are graded at different levels: what mid-level, senior and staff candidates are expected to show in scoping, depth, trade-offs, failure handling and leadership of the conversation, with examples of the same question answered at each level.

Reading is half of it. See this used in a real interview: walk through Design a URL Shortener →

The same question, "design a URL shortener" or "design a news feed", is asked at every level, but the bar is very different. A design that earns a strong hire for a mid-level role can be a no-hire for staff. Knowing what each level is expected to show helps you spend your 45 minutes on what is actually graded. Exact expectations vary by company, but the pattern below is common across large tech companies.

What is graded

Most rubrics look at some version of:

Problem navigation: clarifying requirements, scoping, prioritising.
Solution design: a working end-to-end architecture with sensible components.
Technical depth: real understanding of the hard parts.
Trade-offs: alternatives considered and choices justified.
Failure and operations: what breaks and how the system copes.
Communication: structure, clarity, collaboration with the interviewer.

The levels differ in how much of each is expected, and how much you drive versus are guided.

Mid-level (around 2 to 5 years)

Expected:

A complete, working high-level design for the core features.
Reasonable component choices (database, cache, queue) with basic justification.
A data model and API that support the main use cases.
Awareness of scaling basics: load balancing, caching, replication, sharding.
Responding well to hints and follow-up questions.

Acceptable: the interviewer steering the deep dives; some gaps in failure handling.

Senior (around 5 to 10 years)

Expected, in addition:

Drives the interview: scopes the problem, sets the agenda, manages time.
Estimates that drive decisions, not decoration. See back-of-envelope estimation.
Depth in two or three areas the problem actually hinges on, with specifics (partition keys, consistency mechanisms, idempotency, hot keys).
Trade-offs stated proactively: "we could do X, but Y because..."
Failure modes covered without prompting: retries, duplicates, failover, overload.
Identifies the hard part of the problem early (the celebrity fan-out, the double booking, the exactly-once count).

Staff and above

Expected, in addition:

Reframes the problem: questions requirements, identifies what matters to the business, proposes phasing ("first version for one region, then...").
Breadth and depth together: handles cross-cutting concerns (multi-region, data residency, cost, security, migration from the current system) as naturally as core design.
Evolution: how the design changes at 10x and 100x, what to build now versus later, how to migrate without downtime. See online schema migrations.
Operational maturity: SLOs, rollout strategy, observability and on-call implications. See SLIs, SLOs and error budgets.
Judgement under ambiguity: makes reasonable assumptions quickly, states them, and moves on.
Communication that would work with other teams and leadership: clear diagrams, crisp summaries of decisions.

The same question at three levels

"Design a URL shortener" (walkthrough):

Mid-level: API for create and redirect, a key-value table from code to URL, base62 codes from a counter or hash, a cache in front of reads, replicas for scale.
Senior: adds estimates (read-heavy, about 100:1), chooses code generation with collision handling and explains why, caches redirects at the edge with the 301 versus 302 trade-off for analytics, partitions by code, handles hot links, idempotent creation, and analytics through an asynchronous pipeline. See hashing and encoding.
Staff: additionally discusses abuse (phishing links, spam), custom domains and multi-tenancy for business customers, multi-region reads with a single write region or globally unique id ranges, data retention, cost per million redirects, SLOs for the redirect path, and a phased rollout. See trust and safety and global traffic management.

Calibrating yourself

If you finish the high-level design with time left and no deep dives, you are performing at mid-level.
If the interviewer has to ask "what happens if this fails?" for every component, failure handling is a gap.
If you never say "alternatively" or "the trade-off is", trade-offs are a gap.
If you never mention numbers, estimation is a gap.

Practise with questions that stretch the area you are weakest in: Design a Payment System for correctness and failure handling, Design a News Feed for scale trade-offs, Design a Monitoring System for data volume and operations.

Checklist

Know which level you are interviewing for and its bar.
Mid: complete, working design with sound basics.
Senior: drive, estimate, go deep on the hard parts, state trade-offs and failures unprompted.
Staff: reframe, phase, evolve, and cover cross-cutting and operational concerns.
Use the same question to practise each level's additions.