Interviews

Facebook Marketplace looks like “Craigslist with photos,” and if you design it that way you will fail the interview. The naive read is a CRUD app: a listings table, a search box, a chat window. But every one of those three has a scale trap hiding in it. The listing store is easy until you remember that “500M active listings” means half a billion rows that are constantly created, edited, marked sold, and expired, each with several photos that dwarf the metadata. The search box is easy until you realize the query is not “find listings matching iphone” but “find listings matching iphone, priced under 30000, in category Electronics, within 10km of where I am standing, sorted by relevance and recency” - a keyword search and a geospatial search and a set of filters, all at once, over 500M documents, at ~150k queries a second. And the chat window is easy until you count the fraud: Marketplace is one of the most heavily-abused surfaces on the internet, so a scammer posting a fake listing and a stolen-goods reshipping scheme are not edge cases, they are the main event. ...

“Show live prices for every stock on every exchange to millions of people at once” reads like a websocket that pushes a number. Then you look at what is actually flowing. Global exchanges emit millions of price ticks per second across hundreds of thousands of symbols. You have millions of users connected, each watching a different handful of symbols, each expecting the number to move within a blink of it moving on the exchange floor. The problem is not “get a price,” it is fan-out: one tick for a hot symbol must reach potentially a million users’ screens in under 100ms, and you cannot afford to send every tick to every user or run a query per user per tick. ...

“Monitor the health of the cluster” sounds like a cron job that pings every box and pages someone when one goes quiet. Then you put 50,000 nodes behind it and ask for sub-second detection, and every easy choice breaks. Poll 50K nodes from one monitor and you cannot finish a sweep in a second. Trust a single missed heartbeat and every GC pause or 200ms network blip pages you at 3am. Auto-restart on the first miss and a flaky switch takes down a rack, then your remediation logic restarts all of it in a storm and you have turned a blip into an outage. The whole problem is doing three hard things at once: detect a real failure in under a second across 50K nodes, be sure it is real and not a false alarm, and act on it without making things worse. ...

Everyone thinks PagerDuty is a glorified SMS sender. “A monitoring tool posts an alert, you look up who is on call, and you text them. If they do not reply, you text the next person.” Then the interviewer starts asking the questions that turn it into a real system: how do you know who is on call right now when the schedule is a weekly rotation with a holiday override layered on top and the engineer is in a different timezone? When you say “escalate if not acknowledged within 5 minutes,” where does that 5-minute timer live so that it still fires if the machine holding it crashes? If the same outage trips 400 alerts in ten seconds, how do you page one human once instead of 400 times? And the thing that actually matters: the entire product is a promise that when production breaks at 3am, exactly one awake human gets woken up and, if they do not answer, the timer does not silently die - it escalates. A dropped page is the one bug this system is not allowed to have. ...

The whole point of a file-transfer service sounds like a solved problem: put the file on a server, hand out a URL, let people download. That works until the file is 10GB and a million people want it in the same hour. Now do the arithmetic the interviewer is waiting for: 10GB times 1,000,000 downloads is 10 petabytes of egress, and if half of them show up in the first hour you need roughly 10 PB / 3600s ≈ 2.9 TB/sec of outbound bandwidth from your origin. No single origin, no CDN tier you would willingly pay for, serves 2.9 TB/sec for one file. The server-centric model does not scale sub-linearly with popularity - it scales linearly, and popularity is exactly when it collapses. ...

Tapping “Like” is the smallest interaction Facebook has. It is one bit: you either like a post or you do not. It looks like a toggle on a boolean. It is not. Behind that single tap sits a counter that must be accurate (a user liking twice counts once, an unlike must decrement, the number cannot drift over a billion taps), durable (unlike a live viewer count, a like is a real fact the user expects to persist forever), and live (the number should tick up on every viewer’s screen as others tap, without a refresh). And then there is the part that actually breaks systems: a celebrity or a viral post can take 100,000 likes per second, all landing on the count of a single post. One row. One key. A firehose. ...

Live comments look like a solved problem until you put a number on it. A celebrity goes live, a million people are watching, and comments are pouring in at ten thousand a second. Every one of those million viewers is supposed to see new comments appear the instant they are posted. Do the multiplication and the system dies on the spot: 10,000 comments/sec times 1,000,000 viewers is 10 billion messages per second if you naively push every comment to every viewer. No fleet on earth moves 10 billion messages a second for a single post. ...

“23 people are looking at this hotel right now.” It is one line of text, a soft nudge that the room might not be here tomorrow. It looks trivial. It is not. To render that number you have to answer, for every one of a million product pages, a question that is genuinely hard at scale: how many distinct humans are looking at this page right now, updated live, refreshed as people arrive and leave, across a global fleet. ...

A wire transfer looks like the wallet transfer’s twin, and interviewers love it because it is not. In a wallet, “move 500 from Alice to Bob” is one UPDATE inside one ACID transaction because both accounts live in your database. A wire moves money between two different banks. The debit lives in your ledger; the credit lives in a bank you cannot see, reach transactionally, or roll back. There is no shared transaction. There is an external rail (Fedwire, RTGS, SWIFT, ACH) that is slow, at-least-once, and - once it settles - irreversible. You cannot ROLLBACK a wire. You can only send a second, compensating wire and hope. ...

One request hits your API gateway, which calls auth, which calls the user service, which calls three downstream services, two of which hit a cache and a database, one of which enqueues a job that a worker picks up 40ms later. That single user-facing click fanned out into 30 service calls across 12 machines, and it was slow - 1.2 seconds when it should be 200ms. Which hop ate the second? Logs won’t tell you: they are 30 disconnected lines in 12 different files with no thread that ties them together. Metrics won’t tell you: they say “p99 latency is up” but not which call in which request. The thing that ties them together - the single most valuable artifact in a microservice debugging session - is the trace: the full call tree of one request, every span timed and parented, so you can see exactly where the 1.2 seconds went. ...

“Notify me when AAPL hits $250” or “tell me when this Amazon item drops below Rs 1,999” sounds like a WHERE price >= target query. Then you look at the numbers. There are 100M active alerts. Stock prices update millions of times a second across tens of thousands of instruments. If you run that WHERE on every price tick you are doing millions of full scans per second over a hundred million rows, and you melt. The whole problem is the inversion: it is not “given a price, which alerts match” as a database scan, it is “given a firehose of price changes, fire exactly the alerts that just got crossed, once, within a second, without scanning anything you do not have to.” ...

An A/B testing platform is deceptively easy to describe and brutal to get right. “Show half the users the blue button and half the green button, then see which converts better.” Every part of that sentence hides a landmine. Which half - and does a returning user stay in the same half tomorrow, or does the button flicker between visits? What happens when there are not two experiments but three thousand running at once, some of them overlapping on the same page? How do you count 500M users worth of impressions and conversions per experiment without a nightly batch job that reports yesterday’s winner today? And the one that sinks most naive designs: how do you decide the green button actually won, versus won by random noise, without a statistician manually eyeballing a spreadsheet? The real problem is this: assign 500M users to variants across thousands of concurrent experiments deterministically and with sub-millisecond latency on the request path, capture a firehose of exposure and conversion events without losing any, and compute per-experiment statistical significance in near-real-time - all while guaranteeing that a user never flips variants mid-experiment and that overlapping experiments do not silently poison each other’s results. ...

Once a rider is matched to a driver, the interesting problem is not “who is my driver” - it is the little car crawling across the map toward the pin, and the number under it that says “4 min” and keeps updating. Both look trivial. Both hide the hard part. The car moving smoothly is the output of a fan-out system that takes one driver’s GPS ping and delivers it to the exact rider watching that trip, in under a second, five million times over. The “4 min” is the output of a routing engine that has to answer “how long from here to there, given the traffic right now” continuously for the entire duration of every trip, without recomputing a shortest path over a road graph on every single ping. ...

Everyone thinks the screen limit is a counter. “Each plan allows N streams, keep an integer per account, increment when a play starts, decrement when it stops, reject when it hits N. Done.” Then the interviewer asks the questions that decide whether it actually works: what happens when the player crashes and never sends the decrement, so the counter leaks upward until a paying family can never watch anything again; what happens when two devices in the same house both hit play in the same 50 milliseconds on the last free slot; how do you make that allow/deny decision fast enough that nobody notices it before their video starts; and how do you do all of it for 250 million subscribers with 100 million concurrent streams at peak. Now it is a real problem. ...

The whole problem is one sentence: the data does not fit in memory. You have 1TB to sort and 16GB of RAM per machine, so the data is roughly 64x larger than the memory you get to sort it in. Every classic in-memory sort - quicksort, the sort() in your standard library - assumes random access to the entire array. The moment the array is bigger than RAM, that assumption is gone, and the algorithm either crashes with an out-of-memory error or thrashes the page cache into oblivion. So the real question is not “which comparison sort,” it is “how do you order data you can only ever see a small window of at a time.” The answer, since the 1960s, is external merge sort: read data in chunks small enough to sort in memory, write each sorted chunk to disk, then merge the sorted chunks back together with a streaming k-way merge that only ever holds one small buffer per chunk in RAM. Scale that across a cluster and you get the distributed sort that wins the TeraSort benchmark. This post builds both, single machine first because the distributed version is just external sort with the partitioning done up front. ...

Surge pricing looks like a multiplication. Base fare times some number, show it to the rider, done. The interviewer lets that sit for about a minute, then asks the questions that break the toy: the number is different on this block than the next one over, it changes every 30 seconds, there are a million of these blocks worldwide all updating at once, a rider who sees 1.8x must be charged 1.8x even if the number moves while they are tapping “confirm,” a driver deciding whether to drive to the airport needs the surge there to still be real when they arrive 12 minutes later, and if you get the number wrong in either direction you either strand riders or enrage them. Surge is not a multiplication. It is a real-time distributed control loop over supply and demand, and the price is just its output. ...

Everyone thinks App Store rankings are a SELECT app_id, COUNT(*) FROM downloads GROUP BY app_id ORDER BY count DESC LIMIT 100. Count the downloads, sort, take the top 100, done. Then you look at a real store and the assumption falls apart in three separate ways at once. First, “trending” is not the same as “most downloaded” - a five-year-old app with a huge install base racks up more downloads per minute than a brand-new hit, yet the new hit is what is trending, so trending has to measure velocity, not volume. Second, there is not one chart, there is a chart per country times per category times per window (top free, top paid, top grossing), which is tens of thousands of distinct top-K lists that all have to stay fresh. Third, the windows are not all the same shape - “top 100 trending every minute” is a fast rolling score, “top 1000 daily” and “weekly” are rolling windows that must expire old events, and “top 1000 all-time” is a monotonic cumulative counter that must never forget anything. One naive GROUP BY cannot be all three. ...

There are two completely different things people call “a message queue,” and confusing them is the fastest way to fail this interview. One is a log - Kafka-shaped, an append-only tape where the broker is dumb, never deletes on read, and every consumer tracks its own position. The other is a broker - RabbitMQ-shaped, a smart mailbox where the broker owns each message, hands it to exactly one consumer, waits for an acknowledgment, and redelivers if that ack never comes. This post builds the second one, because the requirements name it: at-least-once delivery, priority queues, dead-letter queues. Those are broker features. A log does not track per-message delivery state, cannot prioritize one message over another sitting behind it, and has no notion of “this message was rejected three times, send it somewhere else.” A smart broker does. ...

Everyone thinks Google Analytics is a counter with a chart on top. “Drop a snippet on every page, count the pageviews, draw a line graph, done.” Then the interviewer piles on the constraints that make it a real system: it is not one website, it is billions of them, each a separate tenant that must only ever see its own data; it is not a thousand hits, it is 100 billion events a day landing from every corner of the internet; the product does not show one number, it shows a live “users on site right now” ticker and “sessions per day for the last 18 months” and “of everyone who saw the product page, what fraction added to cart then checked out” and “of the users who first showed up in March, how many came back in April.” Those are four completely different query shapes over the same firehose, and one of them (unique users) cannot even be answered exactly at this scale without melting. ...

“Design Google Calendar” sounds like a CRUD app: a user creates an event, it shows up in a grid, the phone syncs it. The interviewer lets that run for a minute, then asks the four questions the toy version cannot answer. First: a user creates “team standup, every weekday at 9am, forever” - do you really write one row per day until the heat death of the universe? Second: someone opens the scheduling assistant, picks eight coworkers across four timezones, and expects to see everyone’s free-busy for next Tuesday in under a second. Third: a billion users have reminders set, and each must fire within a few seconds of its due time even though “due time” depends on the attendee’s timezone and DST rules. Fourth: I edit an event on my laptop offline on a plane, my phone edits the same event, and both must converge without losing data when I land. ...