System Design Interview Prep: What Senior Engineers Actually Ask

System design interviews evaluate how you think about large-scale distributed systems. Unlike coding interviews, there is no single correct answer. The interviewer is assessing your ability to navigate ambiguity, make and justify trade-offs, and demonstrate breadth across infrastructure, data management, and scalability concepts. Here is what senior engineers — the people who actually conduct these interviews — are evaluating and how to structure your approach.

The evaluation framework has four dimensions: requirements gathering (15% of score), high-level design (25%), detailed component design (35%), and scalability/trade-off analysis (25%). Most candidates skip requirements gathering entirely and jump into drawing boxes and arrows. This is the first red flag. An engineer who starts designing without clarifying requirements will build the wrong system. Spend the first 5 minutes of a 45-minute interview asking questions.

Requirements gathering should cover functional requirements (what the system does), non-functional requirements (scale, latency, availability, consistency), and constraints (budget, team size, timeline). For a URL shortener design, functional requirements include creating short URLs, redirecting to original URLs, and optionally tracking analytics. Non-functional requirements might specify 100 million URLs, 10:1 read-to-write ratio, sub-100ms redirect latency, and 99.9% availability. These numbers shape every subsequent design decision.

High-level design starts with a simple architecture and iterates. Draw the user, the load balancer, the application servers, the database, and the cache. For most systems, this basic architecture is the starting point. The interviewer wants to see you build from simple to complex, not start with a microservices architecture with 15 components. Add complexity only as the requirements demand it.

The database choice is usually the first major design decision. SQL vs NoSQL is not a religious debate — it is a trade-off analysis. SQL databases provide ACID transactions, strong consistency, and are suitable for complex queries with joins. NoSQL databases provide horizontal scalability, flexible schemas, and high write throughput. For a URL shortener with simple key-value lookups and high read volume, a NoSQL store or even a distributed cache makes sense. For an e-commerce order management system with inventory transactions, a SQL database with ACID guarantees is more appropriate.