What each level looks like

TL;DR

Interviewers calibrate your level in every system design round. A correct answer at the wrong depth signals a level mismatch and fails the interview.
The four levels (Junior/Mid, Senior, Staff, Principal) differ in scope, trade-off depth, and communication posture, not just technical knowledge.
Juniors solve what's asked. Seniors solve adjacent problems. Staff solve organizational problems. Principals shape the problem itself.
The single biggest level signal: juniors name trade-offs, seniors quantify them, staff connect them to business impact, and principals decide which trade-offs the organization should take.
Same question, same answer, different level. What you say about the design matters more than the design itself at senior+ levels.

Here's a scenario I've seen play out many times: a senior engineer interviews for a staff position. They design a perfectly correct notification system with a message queue, fan-out workers, and a delivery service. Clean diagram, solid API design, good data model.

They get rejected. The feedback: "Strong senior performance, but we didn't see staff-level signals."

The design was fine. The level was wrong. They solved the problem as stated instead of expanding scope. They presented options instead of making recommendations. They talked about system internals instead of connecting decisions to team structure and business constraints.

Level calibration is a distinct skill, separate from system design knowledge. Two engineers with identical technical knowledge can perform at different levels based on how they scope, communicate, and drive the conversation. This article teaches you to see the difference and operate at your target level deliberately.

The Four Levels at a Glance

The progression is not about knowing more. It's about expanding what you consider relevant. A junior thinks about the database. A senior thinks about the database and why not the alternatives. A staff engineer thinks about the database, the team that operates it, and the migration path when requirements change in six months.

Junior/Mid Level (E3-E4)

Target signal: Can implement a well-specified system competently. Understands the basic building blocks and can assemble them into a working design.

What E3-E4 should demonstrate

Identifies the primary data store and sketches a reasonable API contract
Knows standard components: load balancer, application server, database, cache, CDN
Can estimate rough scale ("this fits on a single database at our scale" or "we'll need sharding at 100M rows")
Asks clarifying questions instead of making wild assumptions
Produces a design that would actually function if built

What E3-E4 is NOT expected to do

Proactively identify non-obvious failure modes
Recommend a specific replication strategy with quantified trade-offs
Navigate multi-dimensional trade-off discussions fluently
Design the schema for 100M+ users without guidance

What a junior sounds like

Here's what a junior might say when asked "Design a notification system":

"Users need to receive notifications, so I'll have a notifications table in PostgreSQL. When something happens, we write a row. The client polls for new notifications. I'd put a cache in front of the reads since users check notifications frequently."

This is fine for E3-E4. The design works. The components are reasonable. The candidate answered the question.

Common E3-E4 mistakes

Over-engineering for the wrong scale. Designing a sharded, globally distributed system when the problem says "small startup with 10K users." This signals anxiety, not skill.

Getting stuck in one component. Spending 20 minutes designing the authentication flow when the interviewer wants to see the full system. I've seen candidates burn half their time on a single service because they felt most comfortable there.

Not asking about scale. Jumping straight into drawing boxes without establishing how many users, how much data, or what latency requirements exist.

Senior Level (E5)

Target signal: Can independently design systems of moderate complexity with strong trade-off awareness. Proactively identifies risks and explains why alternative approaches are worse.

What separates E5 from E4

The biggest jump between these levels is trade-off articulation. A junior designs a system. A senior designs a system and tells you why the other reasonable approaches would be worse.

Signal	E4	E5
Data model	"I'll use PostgreSQL"	"I'll use PostgreSQL because the data is relational and we need ACID for payment consistency. DynamoDB would be cheaper at scale but the access patterns require joins."
Scaling	"I'll add a cache"	"The read-to-write ratio is 100:1, so a cache-aside pattern with Redis cuts 90%+ of DB load. I'd set TTL at 5 minutes because notification freshness matters but real-time isn't required."
Failure modes	(waits to be asked)	"The main risk here is the fan-out service becoming a bottleneck. If a celebrity triggers 10M notifications, that's 10M queue messages in seconds. I'd partition by recipient and rate-limit the producer."
NFRs	(covers if asked)	"We need 99.9% availability on the delivery path, eventual consistency is fine for notification reads, and p99 delivery latency under 30 seconds for push notifications."

What E5 sounds like

For the same "Design a notification system" prompt:

"Let me first clarify requirements. We need push notifications (mobile), in-app notifications, and probably email for lower-priority alerts. The core challenge is fan-out: a single event (someone likes your post) may trigger notifications to one user, but a system event (new feature announcement) may fan out to 50M users.

I'd separate the notification pipeline into three stages: event ingestion (Kafka topic, partitioned by event type), fan-out workers (expand one event into N notification records), and delivery services (one per channel: push, in-app, email). The fan-out stage is where scaling matters most.

For the data model, I'd store notifications in a user-partitioned table with a cursor-based read API. PostgreSQL works for moderate scale. If we hit 100M+ users, I'd move to DynamoDB with user_id as partition key since the access pattern is always 'get notifications for user X.'

The biggest risk is celebrity fan-out. If one event triggers 10M notifications, the fan-out workers need to be horizontally scalable and rate-limited to avoid overwhelming the delivery services."

Notice the difference: the senior proactively identifies the bottleneck, names specific numbers, and explains why alternatives exist.

The vocabulary precision signal

Seniors use precise vocabulary. Not "the database is consistent" but "we need read-your-writes consistency for the user's own notifications, eventual consistency is fine for notification counts." Precise language tells the interviewer you understand the concept, not just the buzzword.

Common E5 mistakes

Presenting one design without alternatives. The interviewer wants to hear "I chose X over Y because Z." If you never mention Y, they don't know if you considered it.

Skipping NFRs until asked. At E5, you're expected to state latency, availability, and consistency requirements proactively. Waiting to be asked is an E4 signal.

Getting defensive when pushed. When the interviewer says "What if the fan-out is 100x larger?", the E5 answer is "Good question, here's how the design adapts" not "Well, I already covered that."

Staff Level (E6)

Target signal: Can design complex, large-scale systems with architectural awareness. Drives the conversation. Makes strong recommendations instead of presenting balanced options.

What separates E6 from E5

The E5-to-E6 jump is the biggest in terms of interview behavior. Three key differences:

1. E6 structures the conversation for the interviewer. E5 waits for direction: "Should I go deeper on the data model?" E6 says: "The three interesting deep-dives here are fan-out scaling, delivery guarantees, and notification preferences. I'll start with fan-out since that's the architectural bottleneck, then cover delivery guarantees. Sound good?"

2. E6 connects design to operations. E5 designs a correct system. E6 designs a system and explains how you'd run it in production. "Here's how we'd deploy this, here's the runbook for when the queue backs up, here's the dashboard I'd build to monitor fan-out lag."

3. E6 makes recommendations, not menus. E5 says: "We could use Kafka or SQS. Kafka has ordering guarantees but requires more operational overhead. SQS is simpler but has at-least-once delivery." E6 says: "I'd use Kafka here because notification ordering matters for the user experience (seeing 'X liked your post' before 'X commented on your post' feels wrong in reverse), and our team already operates Kafka for the event pipeline."

What E6 sounds like

"Before I start drawing, let me frame this. Notification systems have three distinct scaling challenges: event ingestion (bursty, needs buffering), fan-out (the multiplier problem, especially for broadcast events), and multi-channel delivery (each channel has different latency and reliability characteristics). I'll design all three but spend most time on fan-out since that's where architectures either scale or break.

For context, I'm designing for a platform with 50M monthly active users, assuming 500M notifications per day based on typical social platform ratios. That's about 6K notifications/second sustained, with peaks at 50K/sec.

The notification pipeline has four stages...

One thing I want to flag early: the team topology matters here. If one team owns the entire notification stack, I'd keep it as a single service with internal modules. If multiple product teams need to send notifications, I'd expose a Notification API as a platform service with self-service configuration. That's the difference between 'notification feature' and 'notification platform', and it changes the API design significantly."

Notice: E6 frames the problem before solving it, estimates scale before being asked, and connects architecture to team structure.

The most common E6 failure

The candidate gives a technically excellent design but never mentions how it would be operated, deployed, or monitored in production. At E6, the interviewer expects you to think about the system's lifecycle, not just its architecture. If you never mention observability, deployment strategy, or incident response, you're missing the staff signal.

Common E6 mistakes

Theoretical knowledge without production intuition. Knowing that Kafka provides ordering guarantees is E5. Knowing that Kafka partition count is the scaling bottleneck for fan-out workers, and that rebalancing during a deploy causes a 30-second processing pause, is E6.

Missing cross-service dependencies. Designing the notification system in isolation without considering: "What happens when the user service is down? Can we still deliver notifications? Do we need a local cache of user preferences?"

Ignoring operability. Never mentioning deployment, monitoring, alerting, or runbooks. At E6, "how do you debug this at 3am?" is part of the design.

Principal Level (E7+)

Target signal: Reasons about systems at the organizational level, not just the service level. Designs for long-term evolution and connects technical decisions to business constraints.

What separates Principal from E6

1. Principal shapes the problem, not just the solution. E6 designs an excellent notification system. Principal asks: "Should we build a notification system at all, or should we adopt a third-party service (OneSignal, Firebase Cloud Messaging) and focus our engineering on the product features that differentiate us?"

2. Principal reasons about system evolution. "This design works for the next 12 months. At 5x our current scale, we'll need to split the fan-out service into a dedicated platform. At 20x, we'll need to rethink the storage model. Here's where I'd place the decision points so we don't over-invest now but also don't paint ourselves into a corner."

3. Principal connects to business constraints. "The real question isn't 'how do we scale notifications' but 'what notification capabilities drive user retention?' The push notification delivery rate directly impacts DAU. If we can improve delivery from 85% to 95%, that's worth significant infrastructure investment. If notifications are just a hygiene feature, we should buy, not build."

What Principal sounds like

"Let me start with the strategic framing. Notifications sit at the intersection of user engagement and platform infrastructure. Before designing the system, I want to establish: is this a competitive differentiator or a commodity capability?

If it's a differentiator (like Slack's notification intelligence, which is a key part of their value prop), we should build a sophisticated internal platform with features like smart batching, user-preference learning, and cross-device deduplication. That's a 3-person team for 6 months.

If it's a commodity (we just need to tell users when something happens), we should integrate a service like FCM/APNs for push and build a thin in-app notification service. That's 2 sprints.

Assuming it's somewhere in the middle, here's my recommendation..."

Common Principal mistakes

Analysis paralysis. Presenting so many dimensions and trade-offs that no clear recommendation emerges. Principal gives opinions backed by reasoning, not exhaustive analysis.

Ignoring the current state. Designing the ideal architecture without a migration path from what exists today. At this level, the migration plan is as important as the target state.

Designing in isolation. Not connecting the notification system design to other platform capabilities (analytics pipeline, user preference service, content moderation). Principal sees the system in the context of the entire platform.

The Same Question, Four Levels

Here's how each level handles "Design a notification system" differently. This is the most important section of this article because it makes the abstract level differences concrete.

Dimension	Junior (E3-E4)	Senior (E5)	Staff (E6)	Principal (E7+)
Opening statement	"I'll need a notifications table and an API to fetch them"	"Let me clarify: push, in-app, and email? The fan-out pattern differs for each"	"There are three scaling challenges here. Let me frame them, then design"	"Before architecture: is this a differentiator or commodity?"
Data model	"PostgreSQL with a notifications table"	"PostgreSQL for now, DynamoDB if we pass 100M users, partitioned by user_id"	"User-partitioned storage, with a read model optimized for the 'unread count' query that drives 80% of reads"	"The data model depends on whether we build notification intelligence (ML on read patterns) or just store-and-deliver"
Scale discussion	"I'll add a cache"	"100:1 read/write ratio, cache-aside with 5-minute TTL covers 90% of reads"	"6K notifications/sec sustained, 50K peak. Fan-out workers are the bottleneck. Here's the partition math"	"At our 3-year growth projection, we'll need to federate this across regions. Let me design the decision points now"
Trade-offs	"Kafka is good for messaging"	"Kafka over SQS because ordering matters for UX"	"Kafka, because our team already operates it for the event pipeline. Adding SQS increases operational surface area"	"Build the thin layer now, with an abstraction that lets us swap implementations. The build-vs-buy decision will change as we scale"
What they never mention	Alternatives, NFRs, failure modes	Team topology, operational concerns	Multi-year evolution, business strategy	(They cover everything)

I've used this table in coaching sessions, and the reaction is always the same: "Oh, I've been giving E5 answers in my E6 interview." That awareness alone is worth the read.

The Three Key Signals

Signal 1: Scope Expansion

This is the clearest level differentiator. How far beyond the stated problem does the candidate reach?

Junior: solves exactly what's asked. "Design a notification system." Designs one.
Senior: solves adjacent problems. "We'll also need rate limiting on the producer side to prevent a single event from flooding the queue. And the unread count needs to be cached separately since it's queried on every page load."
Staff: solves organizational problems. "This should be a platform service, not a feature. Multiple product teams need to send notifications, so we need a self-service API with per-team quotas and their own delivery preferences."
Principal: redefines the problem. "The question isn't 'design a notification system' but 'design a user engagement layer.' Notifications are one channel. We also need in-product nudges, email digests, and eventually proactive suggestions."

Signal 2: Trade-off Depth

How deeply does the candidate reason about trade-offs?

Junior: names the trade-off. "There's a trade-off between consistency and availability."
Senior: quantifies it. "Eventual consistency with a 5-second staleness window is acceptable for notification reads. We'll see stale unread counts occasionally, but the UX impact is low."
Staff: connects to business impact. "The staleness window for notification delivery directly affects our 'time to engage' metric. If a user doesn't see a notification within 30 seconds, the click-through rate drops by 40%. That drives our p99 delivery SLO."
Principal: decides which trade-offs the organization should take. "We should accept higher delivery latency for batch notifications (email digests) and invest the reliability budget into real-time push. Push drives engagement, email drives retention. Different trade-off profiles."

Signal 3: Communication Posture

How does the candidate drive (or follow) the conversation?

Junior: responds to questions. Waits for the interviewer to ask "what about scaling?" before discussing it.
Senior: volunteers information. "Before you ask, the main risk here is celebrity fan-out. Let me address that."
Staff: structures the conversation. "I see three interesting deep-dives. Let me propose: fan-out scaling first, then delivery guarantees, then user preference modeling. Does that work?"
Principal: sets the agenda. "I'm going to spend 5 minutes on strategic framing before architecture, because the build-vs-buy decision changes everything downstream. Then I'll walk through the system in 15 minutes and close with the migration path."

Match your communication to your target level

If you're interviewing for E6, practice structuring the conversation before each mock interview. Open with a framing statement, propose the agenda, and drive the deep-dives. If you wait for direction, you're signaling E5 regardless of your technical depth.

Common Mistakes

Mistake 1: Over-scoping for your level. A candidate interviewing for E5 who spends 10 minutes on organizational topology and multi-year migration plans is demonstrating the wrong skills. The interviewer wants to see trade-off depth and proactive risk identification, not strategic vision. Match your depth to your target level.

Mistake 2: Under-communicating trade-offs. This is the most common miss at the E4-to-E5 transition. You know the trade-offs exist but don't articulate them unless asked. At E5+, every design decision comes with an explicit "I chose X over Y because Z."

Mistake 3: Not driving the conversation (E6+). If the interviewer is leading you through the design with questions like "what about caching?" and "what about failure modes?", you're being directed. At E6+, you should be directing. Propose the structure, identify the deep-dives, and navigate between them.

Mistake 4: Giving analysis without opinions (E7+). "We could do A or B, each has trade-offs" is balanced analysis. It's fine at E5. At E7+, the interviewer wants: "My recommendation is A, because [reasoning]. The condition under which I'd switch to B is [specific trigger]."

Mistake 5: Forgetting that correct is not sufficient. A technically correct design at the wrong level fails the interview. It's entirely possible to design a perfect system and still get "not at senior level" feedback because you never articulated alternatives, quantified trade-offs, or drove the conversation.

How This Shows Up in Interviews

Level calibration happens continuously, not at the end. Every statement you make, every question you ask (or don't ask), and every trade-off you articulate (or don't) contributes to the calibration.

How to prepare by level:

Targeting E4: Focus on getting a complete, working design on the board. Cover all the basics: API, data model, core flow. Ask clarifying questions about scale.
Targeting E5: Practice verbalizing "I chose X over Y because Z" for every major decision. Surface 2-3 risks unprompted. Cover NFRs without being asked.
Targeting E6: Practice opening with a problem framing statement and proposing your agenda. Cover operability (deployment, monitoring, incident response). Make recommendations, not menus.
Targeting E7+: Practice strategic framing: build-vs-buy, team topology, multi-year evolution. Open with business context before technical architecture.

Interviewer observes	Level signal
"Candidate produced a working design"	E4 pass
"Candidate proactively identified risks and quantified trade-offs"	E5 signal
"Candidate structured the conversation and connected design to operations"	E6 signal
"Candidate framed the problem strategically and designed for evolution"	E7 signal
"Candidate gave balanced analysis without recommendations"	E5 ceiling, E6 fail
"Candidate designed a correct system but waited to be directed"	E4 ceiling, E5 fail

Quick Recap

Interviewers calibrate your level continuously throughout every system design interview. A correct design at the wrong depth signals a level mismatch and fails, regardless of technical quality.
The four levels differ in scope (given problem, adjacent problems, organizational problems, multi-year strategy), trade-off depth (naming, quantifying, connecting to business impact, deciding), and communication posture (responding, volunteering, structuring, agenda-setting).
The biggest jump is E5 to E6. E5 presents balanced analysis. E6 makes recommendations. "It depends" is the E5 ceiling. "I recommend X because Y, and I'd switch to Z when [condition]" is E6.
Same diagram, different level. Two candidates can draw identical architectures and get different level scores. What you say about the design, the alternatives you considered, and the risks you surfaced matter more than the boxes on the board.
Over-scoping for your level is a mistake. Spending 8 minutes on build-vs-buy strategy in an E5 interview costs you the technical depth the rubric actually measures. Match your focus to your target level.
Practice the right signal for your target: E4 practices completeness and clarity, E5 practices "I chose X over Y because Z" for every decision, E6 practices opening framing and conversation structure, E7+ practices strategic context and evolution planning.
The single most valuable habit: for every design decision you make, immediately state the alternative you rejected and why. This one habit is what separates E4 from E5 and makes every level above it possible.