How to Prepare for a System Design or Case Interview

In this chapter

A generic technical hour watches you do a slice of the craft: a bug, a chart, a protocol, a short problem.

A system design or case hour watches you scope a messy ask, choose a shape, and defend trade-offs under time. The whiteboard — physical or shared — is the work. If you prep only facts, you will dump architecture or frameworks and never decide.
The labels differ.

Engineering says system design. Consulting and product say case. Operations may say “how would you roll this out.” The shared test is the same: can you turn an unbounded prompt into a bounded problem, pick a first cut, and talk so another adult can follow.
If the invite is ambiguous, ask.

“Is this a scoped problem with a right-enough answer, or an open design / case?” Wrong genre wastes a week. The previous chapter still applies to the craft slice. This chapter is the hour where the problem is too big to finish.

Repeat the prompt.

Then ask questions that change the design, not questions that stall. Users, scale, what already exists, what “success” means, what you are not allowed to do (budget, latency, regulation, time to first value). Write the constraints where they can see them. If you skip this, you will design a different company.
Name a goal for the hour: “I want a working v1 for X, and a list of what v2 would change.” Interviewers grade the cut more than the encyclopedia.

A complete v1 with two honest holes beats a platform that serves every future request and ships never.
If they refuse to give numbers, pick defaults out loud and label them as assumptions.

“I’ll assume ten thousand daily users and a single region - tell me if that’s wrong.” Assumptions are a gift. Hidden assumptions are a trap.

Every serious design has a fork: consistency or availability, depth or speed of study, centralize or localize, build or buy, automate or staff.

Pick one fork that matters for this prompt and walk it. Say what you give up. If you cannot name a cost, you have not designed. You have listed parts.
Use the posting’s nouns.

A payments role should hear about failure, replay, and money. A clinic case should hear about patients, not “users.” A logistics case should hear about docks and windows. Generic “microservices vs monolith” with no domain is a blog, not an interview.
When they push back, treat it as data.

Change the design in front of them. Stubbornness reads as fragile. Instant collapse reads as no spine. The move is: acknowledge the constraint, say what it breaks, propose the next cut.

Structure the board: problem and constraints at the top, a simple picture in the middle, open questions at the side.

Narrate as you draw. Silence plus frantic boxes is a private conversation. They cannot hire a private conversation.
2
Check in.
- “Does this match the scale you had in mind?” twice in thirty minutes is not weakness. It is control. If you are lost, say the fork, not “um.” “I can go deep on data flow or on failure modes
- I’d start with failure because the posting is about incidents.” Then do that.
Leave time to sanity-check: load, cost, what happens when a piece dies, who operates this on a Sunday.

State the check. Finishing by restating the v1 and the two risks is a senior close. Finishing by adding one more box is a junior close.

Do three timed reps of problems that match the job’s domain, not a random list of famous design prompts.

Twenty-five to forty minutes. Voice on. Board or paper. One review: did you scope, did you choose, did you name a cost.
For cases, practice the math in public: units, a back-of-envelope, whether the number is even plausible.

Wrong arithmetic you catch yourself is recoverable. A story with no numbers, when the case is a number, is not.
Do not memorize a canonical “Uber design.” Interviewers have heard it.

They are listening for whether you can start from their prompt. Steal structure (scope, v1, trade-off, risk). Do not steal someone else’s system.

You are done when you can take a messy prompt, write constraints in one minute, propose a v1, defend one real trade-off, and check a failure or a number — out loud — without needing a script.
If this process also includes a take-home or work sample, that is the next chapter: timeboxed proof you can finish, not a whiteboard performance.

If the round is live craft instead, stay with the previous chapter. Do not drag a case framework into a debugging hour.

Generate questions from that job description — free preview, $2 for the full kit. No account. Paste a job description.