Part VII — Interview Playbook
How to perform in the loop itself: calibrating to your level, company formats, driving the whiteboard, drawing designs on any medium, the past-project round, avoiding red flags, a study plan, a bank of real prompts, and cheat sheets.
60. Level Calibration: Senior, Staff, Principal, and Engineering Managers
With the material from Parts I–VI in hand, this chapter shows exactly how the bar differs by level, so you can aim your practice at the right target.
60.1 What changes as the level goes up
The system design round is the main leveling signal for senior roles. At mid-level it checks whether you can produce a working design. At Staff and above it checks whether you can own an ambiguous, high-stakes problem: frame it, make the defensible trade-offs, and anticipate what goes wrong in year two.
| Dimension | Senior (L5 / E5 / 63-64) | Staff (L6 / E6 / 65) | Principal / Sr. Staff (L7+ / E7+ / 66-67+) | EM / Sr. EM |
|---|---|---|---|---|
| Problem framing | Asks clarifying questions | Narrows scope deliberately, states assumptions | Reframes the problem around the business outcome; spots that the stated problem is the wrong one | Frames around customer, team, and delivery constraints |
| Design breadth | Correct high-level design | Correct design + alternatives considered | Several viable architectures compared on cost, risk, and time-to-market | Design that the team can build and operate |
| Depth | Can go deep when asked | Picks the right areas to go deep in on their own | Deep in the 1–2 places that decide success; knows the internals (e.g. LSM compaction, quorum math) | Deep enough to judge the team's design, not necessarily to write it |
| Trade-offs | Names them | Quantifies them | Ties every trade-off to an outcome ("this costs $X/mo but cuts p99 by Y, which matters because Z") | Ties trade-offs to staffing, schedule, and operational load |
| Failure & operations | Mentions replication | Failure modes, retries, monitoring | Blast radius, cells, metastable failures, DR drills, error budgets | On-call health, runbooks, incident process, SLO ownership |
| Evolution | — | How it scales 10× | Migration path from today's system, what to build now vs later, what never to build | Phased roadmap, team topology, build vs buy |
| Communication | Answers questions | Drives the session | Drives it, and treats the interviewer as a stakeholder to align with | Same, plus how they'd get org buy-in |
Level names are not portable. "Principal" at Microsoft (level 65–67) is roughly Staff to Senior Staff at Google/Meta (L6–L7 / E6–E7). Amazon's Principal SDE is L7. Google's L8 is titled "Principal". Before the loop, find out which band the role maps to; it changes how much ambiguity and org scope the interviewer expects.
60.2 How the same answer sounds at each level
Same prompt, "Design a notification system", five answers. Each level keeps everything below it and adds a layer:
- Mid-level: "We'll have a notification service that reads from a queue and calls APNs, FCM, and an email provider."
- Senior: "...with per-channel worker pools, retries with backoff, a dedupe key, user preferences, and rate limiting so we don't spam. State is stored per user, with a queue per channel and a status API." (The mechanics are right and complete.)
- Staff: "Transactional notifications (OTP, receipts) and marketing ones have different SLOs, so they get separate queues, worker pools, and provider quotas: a 50M-user campaign must never delay a 2FA code. At ~1B notifications/day we average ~12k/s, with campaign bursts of 10×, so the provider rate limits are the first bottleneck, and SMS needs vendor failover." (Failure domains isolated, numbers driving decisions.)
- Principal: "First: what is the business using notifications for? If it's re-engagement, the metric is incremental DAU per notification, and the biggest risk is over-notifying, because unsubscribes and OS-level disables are effectively permanent. That puts a central notification budget / ranking service in the critical path for every sending team, with governance over who may send what. Then the transactional/marketing split..." (The architecture changed because of the business outcome.)
- EM / Sr. EM: "The Staff-level design, plus: this is a platform many teams send through, so a platform team owns delivery and the budget service, product teams get self-serve templates with quotas, and v1 ships transactional-only, which carries the highest risk and has the simplest scope. Marketing follows in v2 once budgets exist." (Buildable, ownable, sequenced.)
Interviewers level you by the highest layer you reach consistently. This guide trains every layer: Parts I–II for Senior mechanics, Part III and the corner-case blocks for Staff depth, Part IV (§27–30) for the Principal and manager layers.
60.3 Adjacent senior tracks: same framework, different emphasis
Many senior roles have a system design round with a particular flavor. Formats vary by company, so ask the recruiter which flavor to expect.
| Track | How the design round differs | Emphasize in this guide |
|---|---|---|
| SRE / production engineering | "Design X and tell me how it fails"; capacity, observability, incident response; sometimes a live troubleshooting round | §14, §16, §20, §22–24, §53, Appendix A |
| Infrastructure / platform | Control planes, multi-tenancy, config and identity distribution, adoption by other teams | §19–20, §49, §52–58 |
| Data engineering | Pipelines, CDC, batch vs streaming, data quality, data modeling | §11, §18, §21, §44 |
| ML / AI engineering | Feature stores, training vs serving, ranking funnels, LLM serving, agents, evals | §25–26, §33, §42 |
| Security engineering | Threat models, identity, keys, isolation, audit, recovery | §17, §24, §26.6, §55–56 |
| Frontend / mobile (senior) | Client architecture, offline sync, API contracts, performance ("product architecture" rounds) | §5, §7.5, §34, §45, §48; client-side architecture itself isn't covered in depth here |
| Solutions / enterprise architect | Customer requirements, multi-tenancy, migration, managed services, cost | §17, §20, §27–29, §61 |
| Technical program manager | Enough design depth to sequence, de-risk, and coordinate | §2, §29–30, §64.7 |
60.4 The same moment at five levels
The same moment in an interview, at five levels.
Prompt: "Our DB is at 85% CPU and growing 10% a month. What do you do?"
| Level | Typical answer |
|---|---|
| Mid-level | "Upgrade to a bigger database instance." |
| Senior | "Add read replicas and a cache; look at slow queries." |
| Staff | "First find out what's consuming CPU: query profile, top-N queries. Probably 3 queries are 70% of the load. Fix indexes and cache those reads; move analytics off the primary. That buys 6–12 months. In parallel, plan a sharding key, because writes will hit the ceiling next." |
| Principal | All of the Staff answer, plus: "At 10%/month we have ~2 months before p99 degrades nonlinearly (§22.1), so the immediate fixes are urgent and the sharding decision is a one-way door that needs a proper design review. Is the growth from the product, or from one team's new feature doing N+1 queries? The second is a governance problem: per-service query budgets and ownership. And does the 3-year forecast justify moving to a distributed SQL database instead of hand-sharding? Hand-sharding costs 2 engineers for 2 quarters plus ongoing overhead." |
| EM / Sr. EM | Staff/Principal-level framing plus: "I'd put a DRI on the short-term fixes this sprint, protect the team from feature work for 2 weeks using the error-budget policy, stand up a small design group for the long-term option with a decision date, and tell product and finance the trade-off: a 4-week slip on feature X, or a $Y/month bigger instance as a bridge." |
Which row do you need? For a Senior role, a consistent Senior answer with some Staff elements (numbers, failure modes) is a strong hire. For Staff, you need the Staff row consistently. For Principal, the Principal row, with depth you can defend. For EM roles, the EM row: a credible technical answer and the execution plan. Reaching the row above your target is how you get "strong hire" or an up-level.
What raises your level in the room:
- Asking why and for whom before how.
- Stating assumptions, and numbers, unprompted.
- Naming the one-way doors and slowing down on them.
- Bringing up migration, cost, ownership, and operations without being asked.
- Recognizing when the boring answer (Postgres, a monolith, buy instead of build) is the right one, and defending it.