Posts

A key-value store looks like a solved problem for about thirty seconds. “Put a value under a key, get it back later, it is a hash map.” Then the interviewer says: it has to survive a machine catching fire, it has to stay writable when the network splits the cluster in half, it has to hold petabytes across thousands of nodes, and two clients are going to write the same key at the same instant from two different data centers. Now every easy answer is wrong. Which node owns a key when nodes are constantly joining and leaving? If you replicate a write to three nodes and one is down, do you fail the write or accept it? When two writes race, which one wins, and how do you even know they raced? And can the caller ask for “fast and maybe stale” on one request and “slow and correct” on the next? ...

Everyone thinks a monitoring system is a database with a graph on top. “Every server writes its CPU and memory somewhere, you draw a line chart, and you send an email when the line goes red.” Then the interviewer adds the constraints that turn it into a real system: it is not a hundred servers, it is millions of time series reporting every few seconds; the same metric name with a slightly different label becomes a brand-new series, so a careless user_id label can explode your storage a thousandfold overnight; a query for “p99 latency across the fleet for the last 30 days” must not scan a trillion raw points; and an alert that fires two minutes late during an outage is worse than useless because the pager is how you find out production is down. ...

A small-cap fund SIP page will show you one number: “18% CAGR since inception.” It will not show you that the same fund made you sit on a losing SIP for four straight years between 2018 and 2020, or that had you needed the money in December 2019 instead of December 2021, your 15-year outcome would have been 30% smaller on identical contributions. Small-cap SIPs do build serious wealth. But the headline return is an average that quietly assumes you held through the worst equity drawdowns available in the Indian market without flinching, and that you were lucky enough to redeem in an up-year. Change the exit year by 24 months and the entire result moves. This post runs the rolling 15-year windows so you can see what the holding period actually demands. ...

Everyone thinks a message queue is a list. “Producers push messages onto the back, consumers pop them off the front, done - it is a queue, the name is right there.” That mental model survives exactly until the interviewer asks the questions that make it a real system: what happens when the consumer crashes halfway through a batch, does the message come back or is it gone? What happens when you have a thousand consumers and one queue, how do they share the load without stepping on each other? What happens when the broker holding your messages dies, are the messages gone with it? And when the network retries a publish, does the message land once or twice, and who pays for the duplicate? ...

A video platform looks trivial for about five seconds: POST /video to upload, GET /video to play. Then you remember that one uploaded file is a 4GB 4K master that has to become a dozen different renditions, that a viewer on a train switching between 5G and a tunnel needs the stream to drop from 1080p to 240p without stalling, that the actual bytes are served to billions of people from machines physically close to them and never from your origin, and that the view counter under the video is being incremented tens of thousands of times per second on the popular ones. The upload button is the easy 1%. The real system is this: turn one giant immutable master file into many small streamable segments, store those segments once and serve them from the edge, let the player pick the right quality moment to moment, and count views and watch time at a scale where a naive UPDATE ... SET views = views + 1 would fall over on day one. ...

Everyone thinks a leaderboard is a SELECT ... ORDER BY score DESC LIMIT 100. “Store the scores, sort them, return the top 100, done.” Then the interviewer adds the real constraints: it is not just the top 100, a player who ranks 4,192,304th wants to see their own rank and the ten people around them; scores update constantly as millions of people play, and a single kill or a single point can move someone up thousands of positions; the board must feel live, so a score bump should show up in a second, not on the next nightly batch; and there is not one board, there is a global all-time board, plus a daily board, a weekly board, and one per region, all at once. ...

Everyone starts a web crawler the same way: a queue of URLs, a while loop, fetch, parse out the links, push them back on the queue, repeat. It works on ten pages. Then the interviewer turns it into the real problem: crawl the whole web - billions of pages - politely (never hammer one server), without downloading the same page twice, without getting stuck in an infinite maze of dynamically generated URLs, across hundreds of machines, and refresh it all continuously because the web changes under you. ...

Everyone thinks an ad click aggregator is a SELECT COUNT(*) ... GROUP BY ad_id. “Log every click, count the rows, show the advertiser their numbers, done.” Then the interviewer adds the constraints that make it a real system: it is not a thousand clicks, it is millions of clicks per second at peak; advertisers pay per click so a double-counted or dropped click is literally money moving the wrong way; the dashboard must feel live, so a click should show up in seconds, not in tomorrow’s batch; and the same numbers must also be provably correct at the end of the day for billing, even though clicks arrive late, out of order, and sometimes twice. ...

If you prep for an AI engineer interview by grinding gradient descent derivations and softmax cross-entropy, you will walk in ready for a job that mostly no longer exists. The role that companies are hiring for in 2026 is not “person who trains models.” It is “person who builds reliable systems on top of models they did not train.” Those are different jobs, and the interview loops have quietly split to match. ...

“Take 1 crore cover.” It is the most repeated line in Indian personal finance, and it is a psychological number, not a financial one. One crore feels large. It rhymes with “crorepati.” It sits neatly in a WhatsApp forward. None of that has anything to do with whether it would actually keep your family in their current life if you died tomorrow. The right cover is not a round figure you pick because it sounds reassuring. It is a number you calculate. And when you calculate it properly - replacing the income your family loses, clearing what you owe, funding the goals you promised, and subtracting what you already have - most earning Indians land somewhere between Rs. 1.75 crore and Rs. 3 crore. The round Rs. 1 crore is usually a serious shortfall dressed up as prudence. ...

“Design BookMyShow” looks like a catalogue app: list cities, list movies, list showtimes, take a payment, print a QR code. The interviewer lets that version breathe for about a minute, then drops the question the toy design cannot answer: a cricket final goes on sale at 10:00 AM, 2 million people hit the same match’s seat map in the same second, and seat H14 in the same stadium can only be sold to exactly one of them. Two people are staring at the same seat, both tap “pay,” both cards are valid. Who gets it, and how do you make sure the other one never gets a confirmation for a seat that is already gone? ...

A file sync service sounds like a glorified upload button until you count the bytes. The naive version is a single PUT /file that stores a blob and a GET /file that returns it - and it works right up to the moment a user edits one paragraph in a 2GB video project and your service happily re-uploads all 2GB over their home DSL line. Multiply that by 700M users across 4 devices each, all expecting a saved file to appear on every other device within seconds, and the upload button collapses. The entire engineering problem of Dropbox is this: move the minimum number of bytes to keep N devices holding identical file trees, while storing those bytes once no matter how many users or versions contain them, and reconciling edits that happen concurrently on devices that were offline and never saw each other. ...

Everyone thinks autocomplete is a LIKE 'prefix%' query. “Index the search terms, run a prefix match, return the top ten, done.” Then the interviewer adds the real constraints: the dropdown must update on every keystroke, so you are firing a query every ~50ms while someone types; it must feel instant, which means the whole round trip - network, lookup, ranking, render - has a budget under 100ms; the corpus is billions of queries and the popular ones shift by the hour; and “top ten” is not alphabetical, it is ranked by popularity, which a prefix index does not give you for free. ...

The pitch for Voluntary Provident Fund is seductive and, for most of your salary, correct: 8.25% compounded, tax-free, government-backed, no market risk. Point out to someone that an FD nets 5% after tax and they nod along; tell them VPF beats it hands down and they max it. The usual conclusion follows quickly: since 8.25% tax-free is worth roughly 12% pre-tax for a 30% taxpayer, and equity “only” does 11-12%, just pour everything into VPF and skip the volatility. ...

Most people buy a REIT or an InvIT because a screener showed a 6% or a 12% yield next to it, and 12% looks like a fixed deposit that quietly ran away from home. That number is almost always the wrong thing to anchor on. The yield on these instruments is not one thing. It is a blend of interest, dividend, and your own money being handed back to you, and each of those three is taxed differently and means something completely different for the future value of what you hold. ...

Everyone thinks a cache is a hash map with a size cap. “Store key-value pairs in RAM, evict when it fills up, done.” Then the interviewer makes it distributed: the data no longer fits on one machine, you have twenty cache nodes, and now the hard questions arrive. Which node owns a given key, and what happens to every other key when you add node twenty-one? How do you decide what to throw out when memory is full, and does that decision cost you a lock on the hot path? When the source-of-truth database changes, how does the stale copy in the cache get corrected without a thundering herd? And when one celebrity key gets ten million reads a second, how do you stop a single node from melting? ...

“Move 500 rupees from Alice to Bob” sounds like an UPDATE statement. Then you think about it. What if the request times out and the client retries - did the first one go through? What if the debit succeeds and the process crashes before the credit? What if two withdrawals from the same wallet run at the same instant and both read the old balance? What if the bank tells you a transfer succeeded but your database says it failed? What if a support agent needs to prove, three years later, exactly where a specific rupee went? The one-line update is actually a distributed system with an idempotency layer, an immutable ledger, a state machine per transaction, an integration with unreliable external banks and gateways, and a reconciliation job that catches the cases where all of that still drifted. ...

A document editor sounds trivial until you put two people in the same document. One editor is a text box that saves to a database: type, PUT /document, done. The interviewer nods, then asks the question that detonates the whole design: what happens when Alice and Bob both type into the same sentence at the same time? Alice inserts “Hello " at position 0 while Bob inserts “World” at position 5, their edits cross in flight over the network, and now each person’s copy of the document has to end up identical to the other’s - even though they applied the same two edits in a different order. Get that wrong and the document silently corrupts: characters land in the wrong place, text duplicates, people lose work. That is unacceptable in a system whose entire promise is “we will never lose your writing.” ...

Everyone sells NPS on the way in: the extra Rs 50,000 deduction under 80CCD(1B), the low-cost fund management, the equity exposure. Almost nobody walks you through the way out. And the exit is where NPS quietly changes character - from a market-linked wealth builder into a life insurance product you did not really choose to buy. Here is the part that surprises people at 60: you do not get to keep all your money. By law, at least 40% of your NPS Tier 1 corpus must be used to buy an annuity from an insurance company. You cannot withdraw it, you cannot SWP it, you cannot leave it in equity. It converts into a fixed monthly pension at whatever annuity rate insurers are offering that year. ...

Most “just use Postgres for everything” posts stop at the fun part. They show you that pgvector exists, that SKIP LOCKED gives you a queue, that tsvector does search, and then they wave their hands and tell you to collapse your stack. What they never tell you is where the floor gives out. Every one of these extensions has a specific number - a QPS, a row count, an ingest rate - past which it stops being clever and starts being a liability. ...