Interviews

A password manager looks like a trivial CRUD app. Store some login records, sync them across the user’s phone and laptop, auto-fill them into websites. One table, a REST API, done. The interviewer lets you believe that for about thirty seconds, then asks the one question that reorganizes the entire system: can your servers read the passwords they store? The correct answer - the only answer a serious password manager can give - is no. Not “we encrypt at rest with a key we hold.” No. The server must be structurally incapable of reading a single stored credential, even if the entire database is stolen, even if a rogue employee has root, even if you are legally compelled to hand over everything. ...

Single Sign-On sounds like a login screen. It is not. It is a token factory that a hundred applications trust, sitting at the center of an organization, deciding on every single request across every single app whether the person holding a bearer string is who they claim to be and whether they are allowed to do the thing they are asking to do. You log in once, at one place, and then Gmail, Docs, Drive, Photos, YouTube, and three hundred internal tools all believe you without ever seeing your password. The magic is not the login. The magic is that one central authority mints credentials the other apps can verify, and can un-mint them the instant something goes wrong. ...

“Scan a QR, money leaves your HDFC account and lands in a shopkeeper’s SBI account in three seconds” sounds like one API call. It is not. HDFC and SBI are two different companies with two different databases that will never share a transaction. There is no UPDATE that touches both. In between sits a switch (NPCI) that neither holds the money nor owns either account, yet has to guarantee that the payer’s account is debited exactly when and only when the payee’s account is credited - across two banks, over a network, inside a 5-second timer, ten billion times a month, and it has to be provably correct afterwards when the regulator asks. The one thing you cannot do is the obvious thing: a single distributed transaction that locks both banks. Banks will not give you a lock. So the entire design is about moving money atomically-in-effect across systems that refuse to coordinate. ...

Everyone pictures a CAPTCHA as a picture of squiggly text. “Render some distorted letters, ask the user to type them, check the string, done.” Then the interviewer adds the constraints that turn it into a real system: it is not one page, it is a service in front of every signup, login, password reset, and checkout across thousands of sites, so it must answer in the tens of milliseconds before the form submits; it is not thousands of solves, it is millions of challenges per second; the thing it is fighting adapts - the moment you ship a challenge, someone builds a solver, a farm of humans, or an ML model to beat it, so a static challenge is dead on arrival; and the verdict it returns crosses a trust boundary - the browser is hostile, so a naive “you passed” flag is trivially forged and replayed. The whole problem is adversarial by construction. ...

Reverse image search looks like a search problem, and it is - but not the kind you get from an inverted index of words. A user hands you a picture, not a query string, and asks “where does this appear, and what looks like it.” There are no keywords to match. The only thing you have is pixels, and pixels are the wrong unit: the same photo re-saved as a JPEG, cropped by 5%, watermarked, or scaled to a thumbnail is byte-for-byte a completely different file, yet to a human it is obviously “the same image.” So the core of the problem is not string matching or even byte matching - it is turning an image into a representation where visual similarity becomes geometric closeness, and then finding the closest points to a query among 100 billion of them, in under a second. ...

You hold your phone up to a speaker in a loud cafe, capture five seconds of a song you half-recognize, and a moment later the screen names the track, the artist, and the exact timestamp you were listening to. There is background chatter, the audio is compressed by a cheap phone mic, the recording started somewhere in the middle of the song, and the match is drawn from a catalog of over 100 million tracks. And it comes back in under three seconds. ...

There is a small category of infrastructure that is boring on the surface and terrifying underneath: the thing that every other service leans on to agree with itself. A distributed lock service is that thing. It answers questions that sound trivial and are not: who is the current leader of this shard, which one of these three replicas is allowed to write right now, has the config changed, is node 4,812 still alive. Every microservice in a 10,000-node cluster calls it, often on a hot path, and if it hands back a wrong answer even once - two leaders, two lock holders, a stale config - you get split brain and data corruption that surfaces days later. ...

Google Translate looks like a text box: you type “hello,” you get “hola,” done. That intuition survives one short sentence. The moment you ask “hello” to become fluent Japanese, or you paste a 40-page PDF, or two people hold a live spoken conversation across a language barrier, the box turns into a distributed system whose real job is to run large neural machine translation (NMT) models on GPUs/TPUs at sub-second latency, across 100+ languages meaning 10,000+ possible language pairs, while translating billions of words a day - and to do that without lighting a datacenter’s worth of accelerators on fire. The interesting part is not “map word A to word B.” It is: a stateless serving tier that turns arbitrary input (a phrase, a whole document, a web page’s DOM, a stream of speech) into segments, batches those segments across users to keep expensive accelerators busy, routes each segment to the right model for its language pair, caches the enormous repeat-translation traffic so most requests never touch a GPU, and streams partial results back fast enough that a conversation feels live. Let me build it properly. ...

An object store looks like a hash map with two methods: PUT(key, bytes) and GET(key) -> bytes. That framing is exactly why it is hard. A hash map lives in one process’s memory; this one holds trillions of objects and exabytes of bytes across hundreds of thousands of disks in dozens of datacenters, and promises that once a PUT returns 200 OK the bytes will still be there in a thousand years - eleven nines of durability, meaning if you store ten million objects you expect to lose one every ten thousand years. The naive version is a directory on a big disk behind an HTTP server, and it dies the first time a disk fails, the first time one key gets a billion reads, and the first time the index of keys outgrows a single machine. Everything real about S3 is the machinery that keeps a dumb key-value interface alive when the disk will fail, the datacenter will burn, and the keyspace will not fit anywhere. ...

Find My looks like a location-tracking problem and it is, but the interesting half is a paradox: you must locate a device that is offline - powered-off phone, an AirTag with no radio but Bluetooth, a laptop in a stranger’s bag - using a network of a billion other people’s devices, while guaranteeing that the company running the network can never see where any device is, and that the strangers doing the finding can never be identified or turned into a tracking tool. An online device reporting its own GPS is the easy case. The hard case is: a lost AirTag has no GPS, no cellular, no wifi - it can only whisper over Bluetooth. Someone else’s iPhone walks past, hears the whisper, knows its own location, and has to get that location back to the owner - without the passer-by learning what they found, without Apple learning who found what or where, and without a stalker being able to slip an AirTag into your bag and watch you on a map. ...

Stories look like a photo feed with a countdown, and people design them like one. That is the trap. A story is not a permanent post you happen to hide after a day - the 24-hour lifetime, the ordering, and the read patterns are all fundamentally different from a feed, and they push the design in directions Instagram’s main feed never has to go. Three things make Stories their own animal. First, everything is ephemeral: a story exists for exactly 24 hours and then it is gone, so the entire data model is built around a TTL and auto-expiry rather than durable storage. Second, ordering is not ranked, it is per-viewer state: the story tray at the top of the app is sorted by “who has stuff I have not seen yet,” which means the sort key is a function of me, the viewer, not a global score. Third, the read amplification is brutal: 5B story views a day, most of which are cheap “has anything new happened” tray checks that must return in tens of milliseconds. The media bytes are the easy part (that is a solved CDN problem, same as any photo/video service); the hard part is the seen/unseen state and the tray, so that is where I spend the depth. ...

You say “Alexa, what’s the weather in Bangalore tomorrow?” and about eight hundred milliseconds later a speaker on your kitchen counter says “Tomorrow in Bangalore it’ll be partly cloudy, with a high of 31 degrees.” In that under-a-second window the device woke up on the word “Alexa,” streamed your voice to a data centre, turned the audio into text, figured out that this is a weather question about a specific city and a specific day, called a weather service, turned the answer back into a sentence, synthesized that sentence into speech, and streamed the audio back to the speaker. Any one of those steps done slowly blows the illusion that you are talking to something that understands you. ...

Everyone thinks fraud detection is a set of if statements. “Block logins from Nigeria, flag transactions over $5000, rate-limit signups per IP, done.” Then the interviewer piles on the constraints that make it a real system: it is not a rulebook run once a night, it is a synchronous gate in front of every login, every payment, every signup, and every message send - so it must return a verdict in the tens of milliseconds before the user’s request proceeds; it is not thousands of events, it is billions of events per day; the signal it needs (this card was used in three countries in the last hour, this device fingerprint has 40 accounts, this IP just failed 200 logins) lives in history, so scoring means joining live events against a huge, constantly-updating memory; and the fraudsters adapt, so the model that caught them yesterday is stale today, which is why the model has to be retrained daily on fresh labels and hot-swapped without downtime. ...

Email looks like a solved problem. It is 40 years old, the protocol fits on a napkin, and every framework ships a send_mail() in three lines. So when the interviewer says “design Gmail,” the temptation is to draw a box called “mail server” and move on. That box is where the interview goes to die. The real problem is that email is not one system. It is at least four, wired together and each hard at a different scale. You have to receive mail from the entire internet over SMTP, a protocol you do not control and cannot rate-limit at the source, from senders who range from your own users to botnets. You have to store it durably forever, because people treat their inbox as a filing cabinet and never delete anything. You have to make every user’s mailbox fully searchable in milliseconds, which at billions of messages means an inverted index the size of a small country. And you have to filter spam and malware on the way in, at line rate, before it ever touches a mailbox. 1.8B users, billions of messages a day, attachments up to 25MB, and a storage bill that only grows. Let me build it properly, one hard part at a time. ...

An unknown number rings your phone and, before you pick up, the screen says “Rajesh Kumar - Reported as spam 240 times.” You have never saved that number. Your phone has never seen it. So where did the name come from? The trick behind Truecaller is deceptively simple to state and genuinely hard to build: millions of other people have that number saved in their address book under some name, and Truecaller has quietly aggregated all of those private address books into one giant global reverse phone directory. You uploaded your contacts once; so did 350M other people; the union of everyone’s contacts is the product. ...

A CDN sounds like a caching proxy you already know how to build: put an Nginx in front of the origin, set a TTL, done. That intuition survives about one slide. A real CDN is a globally distributed system whose entire job is to put a copy of someone else’s bytes physically close to every human on earth, keep those copies fresh (or provably safe to serve stale), route each request to the right box in the right city without the client knowing any of the plumbing exists, and do all of this while sustaining billions of requests per second and ~100 Tbps of egress without ever letting the origins behind it feel the load. The interesting part is not “cache a file.” It is: thousands of points of presence spread across the planet, each independently caching, each pulling from a shared origin through a tiered hierarchy that collapses cache-fill traffic, all fronted by a routing layer that steers a viewer in Lagos to a box in Lagos, plus an invalidation system that can purge a stale object from every edge on earth in seconds. Let me build it properly. ...

A DNS resolver sounds like a lookup table: a client asks “what is the IP for example.com,” you return an A record, done. That intuition survives about one query. A real recursive resolver is a globally distributed system whose whole job is to turn a name into an address by walking a delegation tree of servers it does not own, cache the answer for exactly as long as the record’s TTL allows and not one second more, hand back the geographically right address so a user in Mumbai gets the Mumbai edge of the site they asked for, and do all of this in under 50ms at p99 while sustaining trillions of queries per day. The interesting part is not “look up a name.” It is: thousands of resolver nodes spread across the planet behind one anycast IP, each running a recursive engine that chases NS delegations from the root down while a multi-tier cache absorbs 90%+ of traffic, each honoring per-record TTLs so answers are fresh without hammering authoritative servers, and each returning ECS-aware answers so the address you get is close to you - all while a single slow or dead authoritative server upstream must never stall the box. Let me build it properly. ...

Jira looks like a CRUD app with extra menus. Create a ticket, assign it, drag it across a board, close it. Say that in an interview and the hard parts arrive in the first follow-up. “Every org defines its own fields - one team has a Story Points number, another has a Severity dropdown and a Customer picker - and users search across all of them with JQL like project = PAY AND status IN (Open, Reopened) AND assignee = currentUser() AND "Story Points" > 5 ORDER BY priority DESC.” “A ticket cannot jump from Open straight to Closed if the workflow says it must pass through In Review first, and the transition may run validators and fire a post-function.” “There are 100K organizations and 1B tickets total, most orgs tiny and a few enormous, and complex queries are the common case, not the exception.” ...

An online learning platform looks like “YouTube with a login” for about a minute, and then the differences bite. Video is only one plane of it: the actual product is a learner working through a structured course - watching a lecture, then taking a quiz that gets graded instantly, then submitting a programming assignment that runs against a test harness, then having every one of those actions bump a progress record that decides whether they have earned a certificate. The video is stateless and cacheable; everything wrapped around it is stateful, per-learner, write-heavy, and correctness-sensitive in a way a video counter never is. A wrong view count is a rounding error nobody notices. A wrong grade or a certificate issued to someone who did not finish is a support ticket and a trust problem. ...

Everyone thinks matchmaking is “put waiting players in a list, grab the first ten, start a game.” That works in a hackathon demo with fifty players. Then the interviewer piles on the real constraints: the ten players you grabbed have to be close in skill or the match is a stomp and everyone rage-quits; they have to be in the same region or the connection lags to death; the ping between them has to be low even within a region; nobody should wait more than about thirty seconds staring at a “finding match” spinner; and the two teams you form out of those ten have to be balanced against each other, not just individually skilled. And you are doing this for 10 million people queued at the same time, continuously. ...