System-design interviews are the part of the loop where most senior candidates blow it — not because they don't know the patterns, but because they over-prepare on the wrong patterns. The interviewer wants to know how you think under ambiguity. You spent the last weekend memorising consistent-hashing diagrams.
Here's a working framework. We use it at Cruto when we generate company-specific prep, and it's the same framework that holds up across staff-level interviews at FAANG, payments companies, and pre-IPO startups.
Step 1: Treat the prompt as the data, not the question
The interviewer says "design a URL shortener." You think you got the same prompt the last person did. You didn't.
The actual question is in the constraints they didn't say. Are they at a company with 50M DAU or 500? Are reads heavy or writes heavy? Is the analytics requirement an afterthought or the entire reason this thing exists? Different answers give you different correct designs.
So before you draw a single box: ask. Five clarifying questions, ranked by how much they change your design. "What's the read-write ratio?" beats "Should we support custom URLs?"
Step 2: Reach for the boring tool first
Junior candidates reach for Kafka. Senior candidates reach for Postgres. Staff candidates reach for "do we need this at all?"
The unwritten rule of the system-design interview: if a single Postgres instance can do the job, that's the right answer for the first 10 minutes. You add complexity in response to a constraint, not in advance of one. When the interviewer adds "now imagine 1B writes/day," you scale up. Not before.
Step 3: Show your taste in trade-offs
Every system-design question is a trade-off question wearing a costume. The interviewer is checking whether you can articulate what you're giving up — strong consistency, latency, operational simplicity, cost — and whether your trade-off matches the constraint they handed you.
Concretely: when you reach for eventual consistency, say so out loud, and say what kind of staleness the user-facing API can tolerate. When you reach for a queue, say what happens when it backs up. When you reach for sharding, say what queries become 10x more expensive.
Step 4: Practice on the company you're interviewing with
This is where generic prep falls down. The company you're interviewing with has a domain. Stripe is going to ask payments-shaped questions. Datadog is going to ask metrics-pipeline-shaped questions. Doordash is going to ask geographically-distributed-state-shaped questions.
If you can spend 30 minutes reading the company's engineering blog before the interview, do it. Notice the words they keep using. "Idempotent" comes up a lot in payments orgs. "Hot keys" comes up in metrics. The interview will use those words back at you, and answering with them is how you sound like someone they want on the team.
This is exactly why we built Cruto's interview prep around the company you applied to. When you mark a Stripe job as Applied, the mock interview is in the persona of a Stripe staff engineer who has read the job description. The questions reference idempotency keys and ledger-style accounting because that's what Stripe interviews actually probe.
Step 5: Time-box the answer
System-design interviews are 45-60 minutes. A good answer fills the time. A great answer leaves room for the interviewer to ask their follow-ups.
Here's a clock that works:
- 0-5 min: clarifying questions, scope
- 5-10 min: functional requirements + back-of-envelope estimates
- 10-25 min: high-level boxes-and-arrows design
- 25-40 min: deep-dive on one or two components the interviewer flags
- 40-50 min: failure modes, scaling, what you'd build first if you only had a quarter
- 50-60 min: their questions, your questions back to them
What to skip
Memorising every consensus algorithm. Drawing CAP triangles unprompted. Listing every AWS service you've ever heard of. None of those signal seniority. They signal recency-bias from a YouTube playlist.
What we do at Cruto
When you mark a job Applied on Cruto, we generate a system-design question keyed to the company's stack and the posting's stated responsibilities. After you take it, the live mock interview will probe the same axis — but in the persona of someone who works at that company. The repetition is what makes it stick. Try it free.