Interview Frameworks Compared — System Design

Summary#

Every interview-prep resource ships a numbered framework: 4-step, 7-step, 8-step, acronym-driven, SNAKE-style, PACELC-anchored. They’re all sketches of the same underlying conversation. Knowing which one to anchor on isn’t about correctness — it’s about which mental scaffold survives 45 minutes of pressure.

Why it matters#

A framework is a forcing function: it makes you cover ground you’d otherwise skip when nervous. Candidates who don’t anchor on any framework spend the first 15 minutes ping-ponging and the last 10 panicking that they haven’t talked about scaling yet. Candidates who anchor on the wrong framework over-invest in steps that aren’t graded.

The signal interviewers actually want: a candidate who runs a framework as scaffold, not script — uses it to navigate, deviates when the conversation goes interesting places, and returns without losing the thread.

How it works#

Most published frameworks reduce to the same backbone: understand → plan → sketch → drill → review. The variation is in how many sub-steps each phase gets and where the framework places its emphasis (data model? scale numbers? trade-offs?).

The 7-step walk-through (this site’s default)#

Clarify → Estimate → Contract → High-Level → Data → Detail → Evaluate. Emphasis: balanced. Step 1 (clarify) and Step 7 (evaluate) carry senior signal. Best for: general system-design loops at large companies.

The 4-step compression#

Requirements → High-level → Deep-dive → Bottlenecks. Emphasis: speed. Folds estimation into requirements and data model into high-level. Best for: 30-minute screens, prompts where the system is small enough that the data layer is obvious. Risk: skips capacity estimation visibly — common signal flag.

The 8-step / extended#

Requirements → Scale assumptions → API → Storage → High-level → Component details → Bottlenecks → Future improvements. Emphasis: rigor and explicitness. Separates “scale assumptions” from “capacity estimation” so you can quote target numbers before doing the math. Best for: infrastructure-heavy interviews where the data layer is the whole point (databases, storage, streaming systems). Risk: easy to spend 20 minutes on the first three steps and run out of time on architecture.

SNAKE-style mnemonics#

Scenario, Necessary (constraints), API, Knowledge (storage), Evolution. Emphasis: memorability. Same backbone, different names. Best for: candidates who think in acronyms. Don’t switch frameworks mid-loop just to match one.

PACELC-flavored#

Frame the entire design around the consistency / availability / latency trade-off. Less a framework than a lens — overlaid on whichever step framework you’re using. Emphasis: distributed-systems trade-offs. Best for: database, storage, replication-heavy designs.

Variants and trade-offs#

Strict step framework (4 / 7 / 8 steps) — predictable, easy to grade, easy to recover when nervous (“where are we?”). Risk: feels mechanical when the interviewer wants conversation, and skipping a step looks like an omission rather than a choice.

Lens-based (PACELC, NFR-first, failure-first) — more conversational, plays to senior interviewers who treat design as trade-off enumeration. Risk: easy to lose the thread; doesn’t force you to cover estimation or data model unless you remember.

The other axis is where the framework starts:

Requirements-first (most common): clarify functional + non-functional before drawing anything. Safe.
Scale-first: state your scale assumptions upfront, then design back from them. Common at companies that interview specifically for “10× problems”.
Failure-first: open with “what’s the worst expected failure?” and let the design fall out of that. Rare in interviews, common in real production design reviews.

What every framework agrees on

Strip the numbering and you’ll find the same five obligations: (1) understand the prompt before drawing, (2) ground the design in numbers, (3) define an interface, (4) sketch the major boxes, (5) close with trade-offs. If your answer hits all five, the framework name doesn’t matter. If it misses any, no framework will rescue you.

When this is asked in interviews#

Implicitly, in every system-design interview. The interviewer doesn’t ask “which framework did you use” — they ask “design X” and then grade against an implicit scaffold. The candidate’s scaffold needs to be recognisable enough that the interviewer can follow along.

Explicit framework questions are most common in:

Coaching / TPM interviews at companies that hire heavily for cross-team design (“walk me through how you approach a design problem”). The framework itself is the answer.
Senior-and-above bars where interviewers want to see meta-awareness (“which step do you think is the most undervalued?”).
Internship / new-grad system-design loops, where the interviewer wants to know you’ve seen frameworks before, regardless of which.

Common follow-ups:

“Where would you deviate from this framework, and why?”
“Which step do candidates most often skip, and what’s the cost?”
“Walk me through how you’d compress this to 25 minutes if I told you we only have 25.” (Answer: keep clarify and evaluate; compress data and detail; merge high-level into interface.)