Questions companies actually ask

Google leans toward scale and data-intensive problems: crawlers, indexing, autocomplete, distributed storage. Expect the follow-up to be what happens at a billion of something, and expect the estimation to be checked rather than accepted. Meta favours social graph problems, news feed, friend recommendation, live comments, where fan-out and the celebrity case are the crux and where the interesting answer is usually a hybrid.

Amazon presses on operational ownership and cost, in keeping with its leadership principles, and it is the loop where the behavioural round carries the most weight relative to the technical ones. Uber and Lyft go to geospatial matching, surge and the state machine of a trip. Stripe and payment companies go to consistency, idempotency and what happens when a retry arrives after a timeout.

The steering that follows from this is modest and worth doing. At a payments company, volunteer idempotency before being asked. At a social company, raise the celebrity case yourself. At Amazon, say what it costs to run and who gets paged. None of that is gaming the interview; it is answering the question the domain actually poses, which is what a colleague there would do.

Be careful with how much weight this carries, though. Loops vary by team more than by company, interviewers bring their own preferences, and any published mapping of company to emphasis is indicative rather than sourced. Treat it as a prior to update rather than as a script, and drop it the moment the interviewer indicates otherwise.

The one universally safe move is to ask what they care about. Which part of this would you like me to go deeper on is a question every interviewer is glad to answer, and it replaces guessing about emphasis with knowing it.

The questions have barely changed in years. What separates candidates has shifted toward the dimensions that used to be extra credit, and at senior level they are now part of the answer rather than a bonus attached to it.

Expect to be asked what it costs to run, what happens at three in the morning when it breaks, who is paged, and how it is rolled back. A design with no answer to those reads as unfinished, because it describes a topology rather than a system somebody has to operate. Saying this runs about two hundred a month, and if the cache tier fails we serve stale for up to five minutes rather than going down, is the differentiator.

Migration is the other under-prepared dimension. Almost nothing is built on an empty field, so being asked how you would get there from the system that exists is both realistic and revealing. The strong answer is incremental: run both, move traffic gradually, keep a way back, and have a signal that tells you which is behaving better.

Some loops now run without a whiteboard at all, asking you to design aloud and then revising the requirements mid-way to see how the design bends. That format rewards the same habits as the written one: state assumptions, keep the reasoning audible, and say which decisions the change invalidates rather than quietly patching the diagram.

None of this replaces the technical core. It is the layer that turns a correct answer into a credible one, and it is the layer most candidates leave out, which makes it the cheapest available way to be memorable for the right reason.

Pick six problems that span the underlying decisions rather than twenty that repeat the same one. A feed, for fan-out on write against fan-out on read. A chat system, for held connections and delivery guarantees. A ride match, for geospatial indexing and assignment. A rate limiter, for algorithms and distributed counter state. A video service, for the pipeline and the cost of precomputation. A payment flow, for idempotency and consistency under an ambiguous timeout. Between them those six exercise almost every decision the common pool draws on, which is why six done properly beats twenty read about.

Do each one out loud, against a timer, in the format you will actually face. The constraint in the real thing is the clock and the talking, not the knowledge, and both are trainable in a way that reading is not. Forty five minutes, spoken, with a diagram you are producing while you speak, is a genuinely different exercise from thinking the same thoughts silently, and the gap between the two is where most well-prepared candidates lose the round.

Then redo one with a changed constraint, which is the highest-value drill available because it rehearses the thing interviewers actually do. Ten times the traffic. A hard consistency requirement where you had assumed staleness was fine. A regulatory rule that the data cannot leave a country. A budget a tenth of what you implicitly assumed. Watch whether your design bends or breaks, and notice which decisions you have to unwind: those are the ones that were load-bearing, and knowing which they are is most of what senior judgement looks like from outside.

Record yourself once, however unpleasant that is, because the recording tells you things no amount of self-assessment will. The usual findings are the same across most people: long silences during the hard part, assumptions stated once and then quietly contradicted, a component named and never justified, and no time left for the failure modes. Each of those is cheap to fix once seen and invisible from the inside.

Keep a written list of the numbers you keep having to look up, and stop looking them up. Requests per second from a daily total. Storage per year from a row size. The latency ladder from memory to cross-continental. A quorum size for a given failure tolerance. Those are the arithmetic you will do under pressure, and doing it from memory is the difference between a fluent five minutes of estimation and a stalled one.

Finally, do at least two of the six with another person rather than alone, because the part you cannot rehearse by yourself is being interrupted. Someone pushing on a decision, asking for a number you did not prepare, or steering you away from the part you wanted to talk about is the actual format, and the first time it happens should not be the real thing.