Interviews

“Design Uber” sounds like a CRUD app with a map on top. A rider taps a pin, a driver shows up, money moves. The interviewer lets you believe that for about thirty seconds, then asks the question that breaks the toy version: there are 5 million drivers on the road right now, each one broadcasting its GPS position every few seconds, and a rider standing on a corner wants the nearest available car in under a second. How do you find “the closest driver” out of millions of constantly-moving points, hundreds of thousands of times per second, without scanning the whole planet on every request? ...

Everyone thinks the URL shortener is a trivial problem. “It’s a hash map. Store long URL, return short URL, done.” Then the interviewer asks: how do you generate the key, how do you avoid collisions, what happens when one popular link gets 50,000 redirects a second, and how do you serve that redirect in under 10ms across the globe. Now it’s a real system. The whole problem is deceptively read-heavy and deceptively about one decision: how you mint short keys. Get the key generation wrong and everything downstream (collisions, hot shards, wasted storage) gets worse. Get it right and the rest is caching and sharding you already know. ...

The Twitter timeline looks trivial until you say the numbers out loud. “Show me a list of tweets from people I follow, newest first.” It is a join. SELECT * FROM tweets WHERE author IN (my followees) ORDER BY time DESC LIMIT 50. Done. Then the interviewer points out that some users follow 5,000 accounts, some accounts have 100 million followers, the timeline must load in under 200ms, and 300 million people refresh it all day. The join is now the most expensive query on the internet. ...

A chat app sounds like the easiest system you will ever build. “User A sends a message, user B receives it.” One INSERT, one SELECT. The interviewer lets you say that, then asks the questions that turn it into one of the hardest real-time systems in the building: how does B receive it instantly when B might be offline, on a train, or logged in on three devices at once? How do you show the second grey tick the moment it lands on B’s phone, and the two blue ticks the moment B actually opens the chat? How do hundreds of millions of phones hold an open connection to your servers at the same time without melting? ...

You have 47 browser tabs open. One is a YouTube video on consistent hashing. Another is a blog post about CAP theorem. Somewhere in the mix is a Reddit thread titled “How I cracked system design interviews in 3 months.” You have been studying for two weeks and somehow feel like you know less than when you started. The problem is not a lack of resources. It is the lack of a sequence. System design topics build on each other, and jumping straight to “design Twitter” without understanding database sharding is like trying to build a roof before laying the foundation. ...

You’re in a system design interview. You say “we’ll use PostgreSQL” and immediately follow it with “and we’ll shard it across 16 nodes.” The interviewer asks: “How much traffic are you expecting?” You don’t have a number. You just sharded because it sounded like the senior thing to do. Here’s the thing - most teams shard too early. A single PostgreSQL node can handle far more than people think. The decision to shard should come from actual numbers, not vibes. This post gives you those numbers. ...

You’re building a notification bell. The product team wants it to feel “real-time.” You reach for WebSockets because that’s what every blog post tells you. Six months later, you’re debugging a connection manager that handles reconnections, heartbeats, load balancer stickiness, and auth token refresh - all for a feature where a 5-second delay would have been perfectly fine. The problem isn’t picking the wrong tool. It’s not understanding the tradeoffs before picking. ...

Most candidates jump to drawing boxes on a whiteboard. Here’s the exact structure, order, and time allocation that turns a chaotic 45 minutes into a clear, compelling system design walkthrough.

Most candidates either skip estimation entirely or spend five minutes doing exact math. Here’s how to do quick, high-signal capacity estimation that actually drives architecture.

Saying ’the system should be scalable and highly available’ is not an NFR. Here’s how senior engineers define NFRs that actually drive architecture - with a framework, examples, and checklist.

Most candidates list features. Senior engineers define the system’s contract. Here’s a framework to get FRs right - with examples, anti-patterns, and a checklist.

Your college name is not the blocker you think it is. Here is a honest roadmap from someone who has seen both sides of the interview table.

You can solve hard LeetCode problems and still bomb interviews. The game has shifted, and most engineers have not noticed.