System Design

Fundamentals — Staff Depth

Treat fundamentals as a decision framework, not a vocabulary quiz. Staff answers name the bottleneck resource (CPU, memory, disk, network), pick the scaling lever that attacks it, and quantify latency/throughput/availability tradeoffs before drawing boxes. Caching, CDNs, and load balancers are tools with failure modes — you score by saying when not to use them.

Data Storage — Staff Depth

Storage interviews reward modeling access patterns, not listing databases. Staff answers pick primary keys and sharding keys from query shapes, separate OLTP from analytics, and speak consistency (strong vs eventual) as a product requirement. Indexes, replication, and partitioning are capacity and correctness tools — you name the failure when the wrong key or engine is chosen.

Distributed Systems — Staff Depth

Distributed systems answers are about failure and coordination cost. Staff candidates invoke CAP/PACELC as constraints on a specific failure (network partition), design for idempotency and exactly-once effects via at-least-once + dedupe, and treat consensus, leader election, and consistent hashing as tools with operational load — not buzzwords.

Cloud Architecture — Staff Depth

Cloud design is about blast radius, tenancy, and operability — not logo bingo. Staff answers place workloads in multi-AZ (and optionally multi-region) with clear data residency, IAM least privilege, and cost/latency tradeoffs. Managed services are fine when you own failure modes: throttles, regional outages, and vendor lock-in escape hatches.

Interview Skills — Staff Depth

System design interviews score communication and judgment under time pressure. Staff candidates clarify scope, state assumptions with numbers, drive a structured agenda (requirements → estimate → HLD → deep dive → risks), and invite collaboration. Depth beats breadth: one sharp deep dive outperforms a shallow tour of every buzzword.

Building Blocks — Staff Depth

Building blocks (rate limiters, unique IDs, queues, search, notifications) are reusable patterns you compose. Staff answers know the algorithm options (token bucket vs sliding window, snowflake vs UUID), their failure modes, and how to place them in a larger design without over-fitting. Precision on APIs and data structures beats vague 'we'll use Redis'.