System Design Expectations by Company

First: will you even get a design round?

The most important system-design fact for a mid-level candidate is that the round's very existence depends on the company:

The planning consequence is blunt: verify the loop with your recruiter before allocating prep time. Weeks of design prep for a Google L4 loop is misallocated effort that should have gone to coding — which is both more of the loop and the heaviest-weighted signal there.

The mid-level design bar, precisely

Where a design round exists, the mid-level bar is component-scoped design: take a familiar-sized product ("design a URL shortener", "a rate limiter", "a news feed") and assemble a sensible high-level architecture out of standard parts, with each choice justified. Concretely, a passing mid-level performance:

1. Asks clarifying questions first. Scale, read/write ratio, latency needs, consistency needs. Diving into boxes without scoping is itself a negative signal.
2. Draws a sensible standard architecture: load balancer, application servers, a justified database choice, a cache, maybe a queue — each present for a stated reason.
3. Does rough capacity math when a number decides something — order-of-magnitude, not precision.
4. Explains trade-offs at surface-to-moderate depth: SQL vs NoSQL for this workload, cache-aside vs write-through, where the bottleneck moves next.

What is explicitly not required at mid-level: multi-region failover, org-level architecture, consensus-protocol internals, deep sharding strategy. That is the senior (L5/E5+) bar, where the discussion is about navigating deep trade-offs and organizational impact. Reaching for senior-tier topics with shaky fundamentals is a classic mid-level mistake — an interviewer who hears "we'd go multi-region active-active" will ask a follow-up question about conflict resolution, and the crater that follows costs more than the ambition earned. Depth you can defend beats altitude you cannot.

A worked example at exactly the right depth

Prompt: "Design a rate limiter for our public API." A calibrated mid-level pass:

Clarify (2–3 min): "Per-API-key limits or global? What scale — requests per second across the fleet? Do limits need to be exact, or is small over-admission acceptable near the boundary?" Suppose: per-key, ~50K req/sec fleet-wide, approximate is fine.

Sketch (10 min): "Enforcement lives in the API gateway layer — every request already passes through it, so no extra hop. The algorithm: token bucket per key — each key gets tokens at its allowed rate up to a burst cap; a request spends a token or gets rejected with HTTP 429 and a retry-after header. Counters can't live in gateway memory because we run many gateway instances and a key's requests spread across them — so state goes in Redis, an in-memory store fast enough for a counter update per request."

One capacity check, because it decides something (2 min): "50K req/sec means 50K Redis operations/sec. A single Redis instance comfortably handles over 100K simple ops/sec, so one primary with a replica for failover is fine — no sharding needed. If we grow 5x, we shard by key hash; keys are independent so that's clean."

Trade-offs when probed (5–10 min): "Race between read and update? Do the whole check-and-decrement atomically in a Lua script — a small server-side script Redis runs as one operation. If Redis is briefly unreachable? Fail open — admit traffic — because dropping all API traffic over a limiter blip is worse than a minute of unenforced limits; and alarm on it. Precision at the window edge? Token bucket already handles bursts more gracefully than fixed windows, and we agreed approximate is acceptable."

Every component earned its place with a reason, the one calculation performed decided the sharding question, and the trade-offs stayed at the depth of this system. That is the whole bar. Notice what never came up: regions, consensus, or a bespoke algorithm.

Company flavors, briefly

• Meta E4 (Pirate): product-flavored prompts (design a feed, design Instagram stories). Emphasis on a clean end-to-end data path — client, API, storage, delivery — and on you driving the whiteboard with energy. The behavioral "move fast" culture shows up as a preference for candidates who make reasonable calls quickly over those who agonize.
• Amazon SDE2: expect the low-level/logical design round to be about structuring code — classes, interfaces, state machines for something like a parking garage or an elevator bank — where the bar is clean decomposition and extensibility. The system-flavored round stays scoped; and remember Leadership Principles questions arrive in this round too ("tell me about a time you simplified a design").
• Everywhere: the interviewer's follow-ups are calibrated to the level. At mid-level they probe whether you understand the components you drew ("what exactly does your load balancer do when a server dies?"). You are not expected to volunteer senior-depth answers — but everything you draw, you must be able to defend one level down.

Preparing efficiently

Practice 5–8 scoped classics end to end, out loud, at the depth shown above: URL shortener, rate limiter, news feed, chat system, notification service, file storage, typeahead. For each, rehearse the same four-beat rhythm — clarify, sketch with justifications, calculate when it decides something, trade-offs on probe. The system-design track of this app covers the components themselves; this lesson's job is calibration — knowing exactly how deep the mid-level round goes, and stopping there with confidence rather than apology.