What Interviewers Actually Look For: A System Design Rubric by Level
System Design Rurbric by Level
What exactly is the interviewer writing on their scorecard while you design a URL shortener on the whiteboard?
It is not a checklist of technologies. It is not whether you mentioned Kafka or Redis. Every interviewer at a serious tech company is evaluating you across a set of dimensions, and the expected depth on each dimension changes based on the level you are interviewing for.
The problem is that nobody publishes these rubrics. Companies keep them internal. So candidates end up guessing what “Senior-level depth” means versus “Mid-level depth,” and they calibrate against blog posts and YouTube videos that are often written by people who have never actually conducted these interviews.
What follows is a concrete rubric. No hand-waving. No “it depends.” For each dimension of a system design interview, here is exactly what is expected at Junior, Mid-Level, Senior, and Staff+ levels.
How to Use This Rubric
Before we dive in, a few things to understand about how interview leveling works.
Levels reflect interview expectations, not years of experience. A sharp engineer with 3 years of experience can interview at Senior level if they have worked on the right problems. A 10-year engineer can interview at Mid-Level for a domain they have never worked in. The rubric describes what you need to demonstrate, not who you need to be.
Key insight: Interviewers are not looking for you to hit every single point at your target level. They are looking for a pattern. If you consistently demonstrate Senior-level thinking across most dimensions, you will get a Senior rating even if you miss a few specifics.
The rubric covers nine dimensions. Not every interview will test all of them. A 45-minute round might only touch five or six. But understanding all nine helps you recognize what the interviewer is probing for and adjust your depth accordingly.
1. Communication and Structure
This is the dimension that most candidates underestimate. It is also the one that interviewers evaluate from the very first minute.
At the Junior level, the bar is straightforward: state your approach before you start drawing, explain components as you add them, respond to questions clearly, and ask for feedback at major decision points. You are showing that you can think out loud and collaborate.
At the Mid-Level, you should propose a structured approach upfront. Something like: “I will start with requirements, then sketch the high-level design, then deep dive into the areas that matter most.” You time-box each section, summarize before moving on, and keep the whiteboard organized. This shows you have done this before.
At the Senior level, you drive the interview. You are not waiting for the interviewer to direct you. You adjust depth based on their signals. When you hit a decision point, you offer multiple options with trade-offs instead of just picking one. You proactively identify which areas deserve a deep dive.
At Staff+, you frame the problem before solving it. You teach while designing, explaining the “why” unprompted. You navigate ambiguity without needing guidance. And critically, you connect technical decisions to business outcomes. “We need eventual consistency here because the business can tolerate a 5-second delay on friend counts, and strong consistency would cost us 3x in latency.”
Why this matters so much: An engineer who builds a perfect system but cannot explain their reasoning is risky to hire. Communication is not a soft skill in system design. It is how interviewers determine whether you actually understand what you built or just memorized patterns.
2. Requirements and Estimation
This is where experienced engineers separate themselves from those who have only read about system design.
Junior: Ask 3-5 clarifying questions before designing. Identify core functional requirements. Confirm user types and basic use cases. Acknowledge that scale matters, even if you cannot calculate it precisely.
Mid-Level: Cover both functional and non-functional requirements systematically. Estimate DAU, QPS, and storage from the constraints given. Identify whether the system is read-heavy or write-heavy and explain the implications. Do basic math: QPS = DAU x actions per user / 86,400.
Senior: Do back-of-envelope calculations for storage, bandwidth, cache size, and server count. Identify latency SLAs (p50 and p99) and consistency requirements. Prioritize requirements as P0 versus P1 to scope the problem. Most importantly, use your estimates to justify design choices. “At 10K QPS, we need sharding because a single PostgreSQL instance tops out around 5K writes per second.”
Staff+: Challenge assumptions in the requirements. “Do we really need real-time updates, or would near-real-time with a 2-second delay be acceptable?” Estimate cost implications of design choices. Identify phased delivery milestones. Anticipate how scale will evolve: current state, 6 months out, 2 years out.
3. High-Level Design
The high-level design is where most candidates spend the majority of their time. Ironically, it is also where the level differences are most visible.
Junior: Show a clear client, API server, and database. Draw request flows with arrows. Identify the need for authentication. Demonstrate basic separation of concerns. This is the minimum viable architecture.
Mid-Level: Add a load balancer, stateless app servers, and database replicas. Include a cache layer with a clear invalidation trigger. Use a CDN for static content. Separate read and write paths when the access patterns justify it.
Senior: Define service boundaries with clear responsibilities. Introduce async processing via message queues for heavy operations. Match storage types to access patterns. Maybe you need a relational database for transactional data, a document store for user profiles, and a search index for full-text queries. Each choice should have a reason.
Staff+: Show multi-region topology with data flow. Identify single points of failure and their mitigations. Include observability integration points. Make deployment and rollback strategy visible in the design. At this level, the architecture tells a story about how the system operates, not just how it processes requests.
4. API Design
With the high-level architecture sketched, the next question is how services talk to each other and to the outside world. API design is often treated as an afterthought, but it reveals a lot about how a candidate thinks about system boundaries and contracts.
Junior: Define REST endpoints for core operations. Use correct HTTP methods. Sketch request and response structures. Mention authentication.
Mid-Level: Follow resource naming conventions. Include pagination with cursor or offset. Define a consistent error response format. Show awareness of rate limiting.
Senior: Design for idempotency on mutations using idempotency keys. Define a versioning strategy for API evolution. Choose appropriate async patterns: webhooks, polling, or streaming. Define API gateway responsibilities.
Staff+: Separate internal APIs from external APIs. Define backward compatibility guarantees. Analyze batch versus single-item trade-offs. Consider client SDK implications. At this level, you are designing APIs that other teams will build against for years.
5. Data Model
The data model is where interviewers probe your understanding of how data actually behaves at scale.
Junior: Identify main entities with attributes. Define primary keys. Show basic relationships (one-to-many, many-to-many). Use reasonable field types.
Mid-Level: Make a SQL versus NoSQL choice with reasoning. Define indexes for frequent query patterns. Explain denormalization decisions. Handle many-to-many relationships appropriately.
Senior: Select partition keys with reasoning. Prevent hot partitions. Consider read versus write optimized schemas (CQRS when appropriate). Define data lifecycle: TTL, archival, and deletion policies.
Staff+: Define cross-service data boundaries and ownership. Specify consistency guarantees at the entity level. Plan for schema evolution and backward compatibility. Address compliance considerations like PII handling, retention policies, and audit trails.
A pattern interviewers notice: Junior and Mid-Level candidates design data models that work. Senior candidates design data models that scale. Staff+ candidates design data models that evolve. The difference is in what you optimize for: correctness, performance, or longevity.
6. Scalability
Once the data model is defined, the interview typically shifts to how the system handles growth. Scalability questions reveal whether you have actually operated systems under load or just studied the theory.
Junior: Understand horizontal versus vertical scaling. Know that caching reduces database load. Recognize that stateless services can be replicated. Explain what a load balancer does.
Mid-Level: Use read replicas for read-heavy workloads. Implement cache-aside with TTL and invalidation strategy. Move work off the critical path with async processing. Use connection pooling for database efficiency.
Senior: Implement database sharding with consistent hashing. Use partitioned queues for parallel processing. Know write scaling strategies: sharding and batching. Implement back-pressure and load shedding to protect the system under stress.
Staff+: Design cell-based architecture to limit blast radius. Implement multi-region active-active with conflict resolution. Define a capacity planning methodology. Design graceful degradation tiers so the system loses features, not availability, under overload.
7. Reliability and Fault Tolerance
This is where production experience shows most clearly. Engineers who have been woken up at 3 AM think about failure differently than those who have not.
Junior: Understand that redundancy prevents single points of failure. Know that backups exist for data recovery. Retry on transient failures. Use timeouts to prevent hanging.
Mid-Level: Implement database replication for high availability. Use health checks with auto-restart. Apply exponential backoff with jitter on retries. Design graceful degradation when dependencies fail.
Senior: Discuss CAP trade-offs for specific components in your design. Use circuit breakers to prevent cascade failures. Make operations idempotent for safe retries. Define RTO and RPO requirements and explain how your design meets them.
Staff+: Isolate failure domains. Show awareness of consensus protocols for coordination. Define data durability guarantees including replication factor and sync versus async replication. Define SLIs that map directly to user experience, not just server metrics.
8. Trade-offs Discussion
Reliability and scalability are not free. Every design decision is a trade-off. The question is whether you recognize it and can articulate it.
Junior: Acknowledge that trade-offs exist. Identify at least one bottleneck. Explain why you chose your approach over alternatives. Be open to suggestions from the interviewer.
Mid-Level: Articulate 2-3 explicit trade-offs you made during the design. Compare alternatives with pros and cons. Identify the primary bottleneck and how to mitigate it. Explain your consistency versus availability choice.
Senior: Quantify trade-offs when possible. “This adds 50ms of latency but gives us 10x throughput.” Anticipate how bottlenecks shift at higher scale. Explain what you are NOT building and why. Factor operational complexity into your decisions.
Staff+: Do build versus buy analysis for components. Weigh engineering cost against system complexity. Consider the reversibility of decisions. Identify technical debt you are intentionally taking on and define the conditions under which it should be paid off.
The Staff+ signal: When a candidate says “this decision is easy to reverse if our assumptions are wrong, so I would start here and re-evaluate in 3 months,” the interviewer is hearing exactly what they want to hear. It shows maturity, pragmatism, and real-world judgment.
9. Deep Dive Ability
The deep dive is the final test. It is where interviewers push past your preparation and find the edges of your knowledge.
Junior: Explain your design choices when asked. Walk through a request end-to-end. Answer “what happens when X?” questions. Admit gaps in knowledge honestly. Honesty about what you do not know is always better than bluffing.
Mid-Level: Explain cache invalidation in detail. Walk through failure scenarios. Handle “what if component X fails?” questions. Be able to zoom into any component you drew and explain how it works internally.
Senior: Proactively offer to deep dive on complex areas without being asked. Explain edge cases like race conditions and split brain scenarios. Handle “what happens at 10x scale?” with specific, concrete changes to your design. Discuss operational concerns: how do you monitor this? How do you debug a slow request?
Staff+: Explain an incremental migration path from v1 to v2. Handle “what would you do with unlimited resources?” without falling into the infinite resources trap. Discuss how to validate the design before committing to a full build. Identify the biggest risks and define mitigation strategies for each.
Putting It All Together
Here is the pattern across all nine dimensions:
Junior demonstrates awareness. They know the concepts exist and can apply them when prompted.
Mid-Level demonstrates competence. They can apply concepts systematically and make reasonable choices.
Senior demonstrates depth. They anticipate problems, quantify decisions, and think about operations.
Staff+ demonstrates judgment. They challenge assumptions, think about evolution, and connect technical decisions to business outcomes.
The jump from Junior to Mid-Level is about breadth: covering more ground. The jump from Mid-Level to Senior is about depth: going further into each area. The jump from Senior to Staff+ is about judgment: knowing what matters and what does not.
If you are preparing for an interview, use this rubric to calibrate. Record yourself doing a mock interview, then score yourself on each dimension. The gaps will be obvious. Focus your preparation on the dimensions where you are below your target level, not on the ones where you are already strong.
And remember: the goal is not to memorize this rubric. The goal is to develop the thinking patterns that make these behaviors natural. When you genuinely understand why partition key selection matters, you do not need to remember that it is a “Senior-level expectation.” It just comes out because it is part of how you think about systems.
Score yourself against the full interactive rubric on System Overflow before your next interview. All 9 dimensions, all 4 levels, in one page. Identify exactly where to focus your preparation.
Learn system design @ System Overflow