SystemOverflow

System Design Interview Answer Rubric by Level

Concrete expectations for system design interviews at each experience level. Use this to calibrate the depth and breadth of your answers.

Junior
Mid-Level
Senior
Staff+
Communication & Structure
Junior
  • -States approach before drawing
  • -Explains components as they draw them
  • -Responds to interviewer questions clearly
  • -Asks for feedback at major decision points
Mid-Level
  • -Proposes a structured approach upfront (requirements, design, deep dive)
  • -Time-boxes each section appropriately
  • -Summarizes before moving to next section
  • -Keeps whiteboard organized and readable
Senior
  • -Drives the interview, not led by interviewer
  • -Adjusts depth based on interviewer signals
  • -Offers multiple options with trade-offs at decision points
  • -Proactively identifies which areas to deep dive
Staff+
  • -Frames the problem before solving it
  • -Teaches while designing (explains "why" unprompted)
  • -Navigates ambiguity without needing guidance
  • -Connects technical decisions to business outcomes
Requirements & Estimation
Junior
  • -Asks 3-5 clarifying questions before designing
  • -Identifies core functional requirements
  • -Confirms user types and basic use cases
  • -Acknowledges scale matters (even if not calculated)
Mid-Level
  • -Covers functional and non-functional requirements systematically
  • -Estimates DAU, QPS, storage from given constraints
  • -Identifies read vs write ratio and its implications
  • -Calculates: QPS = DAU x actions/user / 86400
Senior
  • -Back-of-envelope: storage, bandwidth, cache size, server count
  • -Identifies latency SLAs (p50, p99) and consistency requirements
  • -Prioritizes requirements (P0 vs P1) to scope the problem
  • -Uses estimates to justify design choices ("At 10K QPS, we need...")
Staff+
  • -Challenges assumptions in requirements ("Do we really need X?")
  • -Estimates cost implications of design choices
  • -Identifies phased delivery milestones
  • -Anticipates scale evolution (current vs 6 months vs 2 years)
High-Level Design
Junior
  • -Client, API server, database clearly shown
  • -Request flow with arrows
  • -Identifies need for authentication
  • -Basic separation of concerns
Mid-Level
  • -Load balancer, stateless app servers, database with replicas
  • -Cache layer with clear invalidation trigger
  • -CDN for static content
  • -Separates read and write paths when beneficial
Senior
  • -Service boundaries with clear responsibilities
  • -Async processing via message queues for heavy operations
  • -Multiple storage types matched to access patterns
  • -Search/indexing infrastructure when needed
Staff+
  • -Multi-region topology with data flow
  • -Identifies single points of failure and mitigations
  • -Shows observability integration points
  • -Deployment and rollback strategy visible in design
API Design
Junior
  • -REST endpoints for core operations
  • -Correct HTTP methods (GET, POST, PUT, DELETE)
  • -Request/response structure sketched
  • -Authentication mentioned
Mid-Level
  • -Resource naming follows conventions
  • -Pagination with cursor or offset
  • -Consistent error response format
  • -Rate limiting awareness
Senior
  • -Idempotency for mutations (with idempotency keys)
  • -Versioning strategy for evolution
  • -Async patterns: webhooks, polling, or streaming
  • -API gateway responsibilities defined
Staff+
  • -Internal vs external API separation
  • -Backward compatibility guarantees
  • -Batch vs single-item trade-offs
  • -Client SDK considerations
Data Model
Junior
  • -Identifies main entities with attributes
  • -Primary keys defined
  • -Basic relationships shown (1:N, N:M)
  • -Reasonable field types
Mid-Level
  • -SQL vs NoSQL choice with reasoning
  • -Indexes for frequent query patterns
  • -Denormalization decisions explained
  • -Handles N:M relationships appropriately
Senior
  • -Partition key selection with reasoning
  • -Hot partition prevention strategy
  • -Read vs write optimized schemas (CQRS when appropriate)
  • -Data lifecycle: TTL, archival, deletion
Staff+
  • -Cross-service data boundaries and ownership
  • -Consistency guarantees at entity level
  • -Schema evolution and backward compatibility
  • -Compliance considerations (PII, retention, audit)
Scalability
Junior
  • -Horizontal vs vertical scaling understood
  • -Caching reduces database load
  • -Stateless services can be replicated
  • -Load balancer distributes traffic
Mid-Level
  • -Read replicas for read-heavy workloads
  • -Cache-aside with TTL and invalidation strategy
  • -Async processing moves work off critical path
  • -Connection pooling for database efficiency
Senior
  • -Database sharding with consistent hashing
  • -Partitioned queues for parallel processing
  • -Write scaling strategies (sharding, batching)
  • -Back-pressure and load shedding
Staff+
  • -Cell-based architecture for blast radius
  • -Multi-region active-active with conflict resolution
  • -Capacity planning methodology
  • -Graceful degradation tiers under overload
Reliability & Fault Tolerance
Junior
  • -Redundancy prevents single point of failure
  • -Backups for data recovery
  • -Retry on transient failures
  • -Timeouts prevent hanging
Mid-Level
  • -Database replication for HA
  • -Health checks with auto-restart
  • -Exponential backoff with jitter
  • -Graceful degradation when dependencies fail
Senior
  • -CAP trade-offs for specific components
  • -Circuit breakers to prevent cascade failures
  • -Idempotent operations for safe retries
  • -RTO/RPO requirements and how design meets them
Staff+
  • -Failure domain isolation
  • -Consensus protocol awareness for coordination
  • -Data durability guarantees (replication factor, sync vs async)
  • -Defines SLIs that map to user experience
Trade-offs Discussion
Junior
  • -Acknowledges trade-offs exist
  • -Identifies at least one bottleneck
  • -Explains why they chose their approach
  • -Open to alternative suggestions
Mid-Level
  • -Articulates 2-3 explicit trade-offs made
  • -Compares alternatives with pros/cons
  • -Identifies the primary bottleneck and mitigation
  • -Consistency vs availability choice explained
Senior
  • -Quantifies trade-offs when possible (latency vs throughput)
  • -Anticipates how bottlenecks shift at higher scale
  • -Explains what they are NOT building and why
  • -Operational complexity factored into decisions
Staff+
  • -Build vs buy analysis for components
  • -Engineering cost vs system complexity trade-off
  • -Reversibility of decisions considered
  • -Identifies technical debt and payoff conditions
Deep Dive Ability
Junior
  • -Explains their design choices when asked
  • -Walks through a request end-to-end
  • -Answers "what happens when X?" questions
  • -Admits gaps in knowledge honestly
Mid-Level
  • -Explains cache invalidation in detail
  • -Walks through failure scenarios
  • -Handles "what if component X fails?" questions
  • -Can zoom into any component they drew
Senior
  • -Proactively offers to deep dive on complex areas
  • -Explains edge cases (race conditions, split brain)
  • -Handles "10x scale" scenarios with specific changes
  • -Discusses operational concerns (monitoring, debugging)
Staff+
  • -Explains incremental migration path from v1 to v2
  • -Handles "what would you do with unlimited resources?"
  • -Discusses how to validate the design before full build
  • -Identifies risks and mitigation strategies
Note: Levels reflect interview expectations, not years of experience. A strong 3-year engineer can interview at Senior level; a 10-year engineer may interview at Mid-Level for unfamiliar domains. Focus on demonstrating clear thinking and justifying your decisions.