Elegant

The frontend system design round is about trade-offs, not diagrams

The Elegant team 5 min readinterview
The frontend system design round is about trade-offs, not diagrams

The frontend system design round scares people because it has no answer key, and that is precisely the point. The interviewer is not checking whether you drew the “correct” architecture — there isn’t one. They are testing whether you can name a trade-off, take a side, and defend it. A candidate who confidently recites one “right” design scores worse than one who says “we could render this on the server or the client; here’s the tension, and here’s why I’d pick server for this case.” The round rewards reasoning made audible, not boxes drawn neatly. Once you know that, the anxiety drops: you cannot be “wrong,” you can only fail to reason.

Each decision is a scale weighing two options against a chosen criterion A balance scale weighing SSR against CSR, labelled with the criterion (first paint vs interactivity), showing the round is about weighing, not finding one right box. SSR CSR first paint, SEO interactivity, cost the score is HOW you weigh, and that you pick
Every design decision is a scale: two viable options, a criterion that tips it, and a defended choice. The round grades the weighing, not a "correct" box.

Structure the conversation so the trade-offs surface

Ambiguity is the medium, so start by scoping — it both narrows the problem and shows you gather requirements. Then walk the design decision by decision, and at each one name the fork out loud:

1. Clarify:   "Who uses this? What scale? SEO relevant? Offline needed?"
2. Data:      "REST or GraphQL? I'd pick GraphQL here — the feed needs 4 joined
               resources and over-fetching would hurt on mobile."
3. Rendering: "SSR vs CSR — SEO matters for a public feed, so SSR the first page,
               then hydrate and paginate client-side."
4. State:     "Server data in a query cache, UI state local — not one big store."

Each line is a fork named and resolved, which is the exact signal being scored.

Make the criterion explicit, then decide

The move that separates strong candidates is stating the criterion before the choice. “It depends” is a non-answer; “it depends on whether SEO matters, and here it does, so SSR” is the answer. Tie each decision to a concrete driver:

Decision            Options              Criterion              Pick
------------------  -------------------  ---------------------  ----
render strategy     SSR / CSR / SSG      SEO + first paint      SSR
list data           paginate / infinite  discoverability        infinite + URL page
freshness           poll / websocket     update frequency       websocket (live feed)
image delivery      one size / srcset    device spread          srcset + lazy

You are demonstrating that you decide from requirements, not from habit — which is what senior engineering actually is.

Defend, but stay flexible

The final beat is defending your choice and acknowledging its cost, because every real decision has one. “I chose SSR for the first paint and SEO; the cost is server render load, which I’d cap with a CDN cache and revalidation.” That sentence shows you see both sides, which reads as maturity — whereas defending a choice as if it had no downside reads as inexperience. If the interviewer pushes back, treat it as a new constraint and re-weigh out loud rather than digging in; adapting to a new requirement is itself the skill. There are no correct boxes in this round — only a candidate who can name the fork, pick from a stated criterion, and own the trade-off. The design-search-experience, design-micro-frontends, and design-localized-app exercises are full rehearsals of exactly this reasoning, each with its own dominant trade-off to name and defend.