Interviews

An online auction looks like “a listing with a current price that goes up,” and if you model it that way you will lose the interview in the first five minutes. The trap is that an auction is not a CRUD row you update - it is a serialization problem wearing a shopping-site costume. The moment two people bid on the same item at the same instant, you have a race: which bid is higher, which one wins, what is the new current price, and did the loser get told they were outbid. Multiply that by a “hot” item - a rare sneaker drop, a graded Charizard, a concert ticket - where thousands of people pile in during the last ten seconds, and the naive “read price, compare, write price” pattern shreds itself into lost updates and double-wins. Then remember there are 100M active listings and each one has a hard deadline, and every one of those deadlines must fire close to on time, or the auction that “ended at 9:00:00” is still taking bids at 9:00:04 and someone is furious. ...

“Let users buy and sell crypto” hides two different, both-irreversible problems welded together. Inside the exchange, Coinbase is a matching engine: for a popular pair like BTC-USD it holds its own order book, matches your buy against someone’s sell by price-time priority, and the moment two orders cross, a trade has happened and cannot be un-happened. Outside the exchange, Coinbase is a custodian on a blockchain: it holds your coins, watches public chains for your deposits, and signs withdrawals that broadcast to Bitcoin or Ethereum where a confirmed transaction is permanent - no chargeback, no reversal, no support ticket that claws it back. So the core invariant is brutal on both sides: never let a user trade or withdraw a balance they do not have, never double-credit a deposit or double-broadcast a withdrawal, and never let the internal ledger disagree with what is actually on-chain. ...

“Let a user buy and sell stocks” sounds like a form that writes a row. Then you notice where the money and the shares actually live. Robinhood does not match your buy against someone’s sell - an exchange does that. Robinhood is the broker: the stateful intermediary that holds your cash and your positions, reserves your buying power the instant you place an order, forwards that order to a real exchange or market maker, tracks it through a lifecycle it does not fully control, and settles the fill back into your portfolio - all while showing you a portfolio value that moves with the market in real time. A fill at the exchange is irreversible. You cannot un-buy 100 shares of AAPL. So the broker’s core invariant is brutal: never let a user place an order they cannot cover, never lose or duplicate an order sent to the exchange, and never let the positions ledger disagree with reality. ...

Venmo looks like a wallet with a Twitter feed bolted on, and that framing is exactly what makes it interesting. The money side demands strong consistency and an immutable ledger - a balance that goes negative from a race is theft, a double-send is a refund and an angry user. The social side demands fan-out, ranking, and privacy - a feed of “Alice paid Bob for dinner” that must respect who is allowed to see what, at read rates 100x the write rate. And sitting across both is fraud: an account takeover draining a balance, a scammer collecting payments for goods that never ship, a stolen card funding a top-up that gets clawed back. Get the ledger right but the fraud wrong and you lose real money; get fraud right but the feed wrong and you leak who paid whom. ...

“Host code and let people review changes” sounds like a CRUD app with a diff view. It is not. Under the hood you are running a fleet that stores 100M Git repositories, each a content-addressed object database with its own history, serving the Git wire protocol (which is a chatty, stateful negotiation, not a REST call), computing diffs and merges on demand, fanning out webhooks to CI on every push, and - the genuinely hard part - indexing and searching across all public source code on earth so a query for a function name returns in a few hundred milliseconds. Every one of those is a different system with a different bottleneck. ...

LinkedIn looks like Twitter with a suit on. It has a feed, it has profiles, people follow each other. So candidates walk in ready to reuse the Twitter fan-out answer and get about four minutes in before the interviewer asks the question that breaks it: “This person is a 2nd-degree connection. How did you compute that?” Now you are not designing a feed. You are designing a graph query engine that answers “are these two of my billion users within three hops of each other” in under 100ms, on a graph with 500 billion edges. ...

“Design Tinder” sounds like Instagram with a nicer gesture. Show a photo, swipe left or right, if two people both swipe right they can chat. The interviewer lets that toy version sit for about a minute, then drops the number that breaks it: 2 billion swipes a day. That is roughly 23,000 writes per second on average and 70,000+ at peak, every single one of them a tiny row that says “user A has an opinion about user B,” and every one of them potentially the second half of a mutual match that has to fire a notification within a second. ...

Reddit reads like three easy problems stapled together. Posts in communities: a table. Voting: a counter. Comments: a tree. Say it out loud and the interviewer starts pulling threads. “A vote must feel instant but the displayed score must not be a live sum of a billion rows.” “The front page is sorted by hot, which is a function of both score and age, so the sort order of every post changes every second even when nobody votes.” “One popular post has 40,000 comments nested twelve levels deep and must paginate.” “A brigade of 5,000 bot accounts can drive a post to the top of a subreddit in ninety seconds, and you have to notice before it happens.” ...

Stack Overflow looks like a CRUD app. Post a question, others post answers, everyone votes, one answer gets accepted, and a number next to your name goes up. Say that in an interview and the follow-ups arrive fast. “The question page is read a thousand times for every time it is written, and it must show a live-ish score, the accepted answer pinned first, and the rest sorted by score - all in under 200ms.” “Reputation is a running total over every vote you have ever received; you cannot re-sum a billion vote rows on every profile load.” “Search is not a LIKE '%...%' query - a user typing python list comprehension slow must get the canonical answer ranked above ten thousand near-duplicates, and that ranking blends text relevance with votes, recency, and acceptance.” “There are 100M questions and 1B answers; that does not fit on one box.” ...

People hear “build Zoom” and reach for the WebRTC tutorial: two peers, an SDP exchange, media flows directly, done. That works for a 1:1 call and detonates the moment a third person joins, and it is not even in the same universe as a 1000-person all-hands. The core problem in video conferencing is not “how do two browsers connect” - that is solved by WebRTC and I have written about it elsewhere. The core problem is fan-out of live media in a room of N participants under a hard sub-200ms latency budget, and the topology you pick to solve it - mesh, MCU, or SFU - determines whether the product exists at all. ...

A shopping cart sounds like a toy problem. “Store a list of item IDs and quantities for a user, let them add and remove, show it back.” You could do it with a row per user and a JSON blob and be done in an afternoon. Then the interviewer starts adding constraints and every easy answer falls over. The cart has to follow the user from their phone to their laptop to the Alexa in the kitchen, and show the same items on all three within a second. It has to survive the user closing the tab and coming back a week later. It has to stay writable during a Prime Day sale when a hundred million people are hammering “add to cart” on the same few thousand doorbusters at the same instant. And - the hard one - the cart cannot lie about inventory: if the warehouse has 100 units of a limited item, you must not let 500 people put it in their cart, walk to checkout, and each expect it to be there. ...

“Move 1PB to the cloud” sounds like a copy job, and people design it like one: point a script at the source, rsync to an S3 bucket, wait. Then the interviewer drops the two numbers that change everything. The link is 10 Gbps. The files are in active use during the migration. Now do the arithmetic: at 10 Gbps, wire-speed and perfect, 1PB takes about 9.5 days of continuous transfer. Real throughput after overhead and contention with production traffic is half that, so ~20 days. And for those 20 days the source data keeps changing underneath you, so whatever you copied on day one is already stale by day two. ...

People hear “build Slack” and reach for a chat toy: a messages table, a WebSocket, insert on send, push to whoever is connected. That works for a demo and falls apart the instant you write down the real numbers. The largest org has 100K members. A single busy channel in that org - #general, #incidents, #announcements - can have tens of thousands of people watching it live. When someone posts, who do you deliver to, and how? Do you write a copy of that message into 50,000 inboxes (fan-out on write) and drown on a viral post, or do you store it once and make every reader come find it (fan-out on read) and drown on the read side instead? That single question - how a message gets from one sender to N readers - is the spine of the whole design, and Slack’s answer is different from Twitter’s or Facebook’s because Slack’s unit of delivery is the channel, not the follower graph. ...

Everyone models an ad server as a lookup: “the user opens the feed, we fetch an ad, we show it, done.” The interviewer lets that sit for a moment and then piles on the constraints that make it a real system. There are not ten ads to choose from, there are millions of live campaigns; the best ad for this user has to be chosen from that pool in under 50 milliseconds while the feed is already rendering; advertisers set budgets and if you overspend theirs you eat the cost, if you underspend it you lose their trust and their business; the spend has to be paced evenly across the day, not blown in the first hour; a large fraction of clicks are bots and you must not charge advertisers for them; and all of this runs at 100 billion impressions a day. An ad server is not a lookup. It is a real-time per-impression auction over a targeted candidate set, constrained by budgets and paced over time, with a fraud filter in the loop - and the ad shown is just its output. ...

Almost everyone reaches for Google Docs the moment they hear “document editor,” and almost everyone is answering the wrong question. Google Docs is a real-time collaboration problem: two people typing into the same sentence at the same millisecond, operational transforms, CRDTs, convergence. That is a specific and hard sub-problem, and it is not what Notion or Wikipedia are. Notion and Wikipedia are async document systems: you open a page, you edit it, you save it. Someone else might edit it an hour later, or a minute later, but the design does not live or die on sub-200ms convergence of concurrent keystrokes. It lives or dies on three other things - how you store a document made of structured blocks, how you keep a full version history without exploding storage, and how you search across tens of millions of documents fast. ...

A car drives through a toll lane at 30 km/h, an overhead antenna reads its RFID tag, and by the time the nose of the car reaches the barrier the boom has lifted and a rupee amount has left a prepaid wallet. That is the whole product in one sentence, and the interviewer will let you feel good about it for about a minute before pointing at the parts that are actually hard. The barrier has to decide in under half a second while the wallet that funds the toll lives in a different bank’s ledger a network hop away. The same tag gets read three times because the car crawled under the antenna. The plaza in a valley loses connectivity for twenty minutes and cars keep coming. And the one thing that absolutely cannot go wrong - the number in the wallet - has to stay exactly right across 100 million debits a day even though two lanes, a retry, and a settlement job might all touch the same balance at once. ...

“Design a flash sale” sounds like a shopping-cart problem until you write down the actual numbers: Burger King runs a promo, the app has 50 million people who will all tap the same button in the same minute, and there are exactly 6,000,000 free-burger coupons to give away. Not 6,000,001. Not 5,999,998. Exactly six million, then the button says “sold out” and everyone else goes home. The interviewer is not testing whether you can serve a page. They are testing whether you can run a single shared counter down from 6M to 0 under a 50-million-user stampede without ever letting it go negative, without handing one person two coupons, and without the whole app falling over. ...

“Book a train ticket” sounds like inserting a row. Then you look at Tatkal. At 10:00:00 sharp, a few days’ worth of demand for a scarce quota lands in a single second. Two or three million people press “Book” against a train that has maybe eighty Tatkal seats. The seats sell out in ten to twenty seconds. Every one of those millions must get a truthful answer - a confirmed seat with a berth number, a waitlist position, or a clean rejection - and no seat may ever be sold twice, because a double-booked berth is two paying passengers standing in the same coach at midnight. This is not a CRUD service with a form in front. It is a scarce-inventory contention problem where the read load is enormous, the write load is fierce and concentrated, and correctness on the write path is absolute. ...

“Design MakeMyTrip” sounds like a shopping app: a user types two cities and a date, a list of flights comes back, they pick one and pay. The interviewer lets that run for a minute, then asks the question the toy version cannot answer. A user in Bangalore types “BLR to DEL, 12 August, 1 adult” and expects, in under two seconds, a ranked list of every way to make that trip - direct flights and connections - across 50-plus airlines, each with a real bookable price, layover, and total duration. MakeMyTrip does not own a single seat. The inventory lives behind dozens of airline APIs and Global Distribution Systems, each slow, rate-limited, priced per query, and disagreeing about what a fare costs from one second to the next. ...

“Let users log in” is the request that hides an entire distributed system. You need to store a password without ever storing the password, verify it in a way that is slow for attackers but fast enough at 100K logins a second, hand out a credential the user carries around, revoke that credential the instant an account is compromised, survive a leaked database dump, layer on a second factor, and let people sign in with Google without you ever seeing their Google password. Every one of those is a place the system breaks, and most of them are places where breaking means a breach, not a slow page. ...