system-design

The Interview Formats You’ll Face

What actually happens in the room, minute by minute, and how the format changes by company and level.

Prerequisites: What Is System Design? Time to read: ~12 minutes

The five formats

Most companies use one or two of these. Knowing which you’re walking into changes how you prepare.

1. The classic open-ended design round

“Design Instagram.”

45–60 minutes, a whiteboard or a shared drawing tool, one or two interviewers. You drive. They interrupt.

This is the default at Google, Meta, Amazon, Microsoft, Uber, and most scale-ups (Careem, Noon, Talabat, Motive). It’s what 90% of this repo prepares you for.

Rough shape of a 45-minute round:

Minutes	Phase	What you’re doing
0–3	Framing	Restate the problem. Confirm you understood it.
3–10	Requirements	Ask clarifying questions. Write down functional + non-functional. Scope aggressively.
10–15	Estimation	Users, QPS, storage, bandwidth. State assumptions out loud.
15–20	API + data model	3–6 endpoints. Core tables/entities.
20–30	High-level design	The boxes-and-arrows diagram. Walk one write path and one read path end to end.
30–42	Deep dives	Interviewer picks (or you offer) 2–3 components. Go three levels down.
42–45	Wrap-up	Bottlenecks, what you’d do with more time, your questions for them.

🚨 The most common failure is spending 25 minutes on requirements and estimation and never getting to a design. Watch the clock. Detailed treatment: The Framework.

2. The “scale this” / deep-dive round

“Here’s a service that does X. It’s at 1,000 QPS and works. It needs to handle 100,000. Go.” or “Walk me through how you’d design just the rate limiter.”

Narrower scope, much deeper. Common at Stripe, Datadog, Cloudflare, and for senior+ roles everywhere. Less about breadth of components, more about whether you actually understand one thing properly.

Prepare with: Part 10 — Performance, and the single-component case studies (rate limiter, distributed cache, job scheduler).

3. Low-level / object-oriented design (LLD)

“Design the classes for a parking lot / elevator / chess game / vending machine.”

45 minutes of class diagrams, interfaces, and design patterns. No servers, no databases, no scale. Very common in India and Pakistan (Tkxel, Systems Ltd, Arbisoft, and most product companies), at Amazon (as part of the loop), and at Uber/Flipkart-style companies.

Tests: encapsulation, SOLID, composition over inheritance, and whether you can extend your design when they add a requirement at minute 35.

→ Low-Level Design

4. Practical / take-home / architecture review

“Here’s a repo. Here’s a spec. Build a small service and write an ARCHITECTURE.md.” or “Here’s our current architecture. Critique it.”

Common at smaller and mid-size companies (Educative, Motive, many startups), sometimes replacing the whiteboard round entirely. Also common as a “pair design” session where you and an engineer design something together, collaboratively, in a doc.

What they’re testing: can you write down a design clearly, and do you make sane choices when nobody is prompting you.

5. Bar-raiser / cross-functional design

Amazon’s “bar raiser” and Google’s cross-team rounds often blend design with behavioral: “Tell me about a system you designed. Now, what would you change?”

Prepare a real system you worked on — even a university project — and be able to discuss its trade-offs honestly, including what was wrong with it. “I’d add a cache” is weak. “We had no idempotency on the payment callback, and we double-charged four customers before we caught it” is strong.

→ Behavioral Round

What changes by level

The question is often identical across levels. What differs is what a passing answer looks like.

	Junior (L3/SDE-1)	Mid (L4/SDE-2)	Senior (L5/SDE-3)
Drive	Interviewer guides you; you follow well	You drive; occasional nudges	You drive entirely, including scoping and time
Requirements	Ask a few questions when prompted	Ask unprompted, scope down explicitly	Challenge the premise; identify the real business constraint
Estimation	Can do it with help	Do it unprompted, correct order of magnitude	Use estimates to make decisions, not decorate
Design	Working single-region design	Correct use of cache/queue/shards with justification	Multiple viable designs compared; picks one and defends
Depth	One level: “we’d use Redis”	Two: “Redis with cache-aside, TTL 5 min, and here’s the invalidation path”	Three: “…and here’s what happens when the invalidation fails, so we use a short TTL as a backstop and accept ≤5 min staleness on this specific field”
Failure	Mentions it if asked	Handles main failure modes	Designs for them from the start; discusses blast radius
Trade-offs	Recognizes them	States them	Quantifies them and connects them to business impact
Operations	Not expected	Basic monitoring	Rollout, migration, on-call burden, cost

🎙️ The clearest single differentiator between mid and senior: a mid-level candidate says “we’ll use Kafka.” A senior says “we’ll use Kafka, which costs us operational complexity and at-least-once semantics we’ll have to dedupe against — the alternative was SQS, but we need replay for the analytics consumer, so the complexity is worth it here.”

Full rubrics: What Interviewers Score You On.

What changes by company tier

Tier	Examples	Emphasis
Service / consultancy	Tkxel, Systems Ltd, Devsinc, 10Pearls	LLD, OOP, SOLID, database design, REST APIs, practical framework knowledge. Less pure distributed systems.
Product companies (local/regional)	Motive, Educative, Arbisoft, VentureDive, Bazaar	Realistic scale (thousands–millions of users), pragmatic trade-offs, actual delivery ability. Distributed systems but not FAANG depth.
MENA/SEA scale-ups	Careem, Noon, Talabat, Tabby, Grab	High-scale consumer systems: geo, real-time, payments, marketplaces. Heavy on the case studies in Tier 2.
Big Tech	Google, Meta, Amazon, Microsoft, Netflix	Fundamentals + depth. Expect pushback on every claim. Estimation must be sound. Consensus, consistency, and failure handling come up.
Infra / dev-tools	Stripe, Datadog, Cloudflare, Confluent	Very deep on one thing. Expect narrow, brutal, specific.

→ Company Guides for company-by-company specifics.

Remote vs onsite

Most rounds are remote now. Practical differences that matter more than people expect:

You’ll use a shared drawing tool — Excalidraw, Miro, or a plain Google Doc. Practice in the tool. Fumbling with the UI burns real minutes and makes you look flustered. Have a blank Excalidraw tab open before the call starts.
Silence reads worse remotely. Narrate constantly: “I’m going to sketch the write path now.” In-person, the interviewer can see you thinking. On a video call, they see a frozen face.
Some companies use a doc, not a canvas. Practice describing architecture in text/ASCII too.
Check your setup 10 minutes early. Camera, mic, and the drawing tool. Every time.

🚨 Format-level traps

Treating a “scale this” round like an open-ended round. If they gave you an existing system, they don’t want a fresh greenfield design. Start from what exists.
Doing LLD in a distributed-systems round (drawing class diagrams when they asked for architecture) or the reverse. Ask which they want if the question is ambiguous: “Do you want me to focus on the service architecture, or the class-level design?” This is a good question, not a weak one.
Not asking how much time you have and how the interviewer wants to spend it. One sentence at the start — “I’m planning ~10 minutes on requirements and estimates, then the high-level design, then deep dives — does that work for you?” — makes you look like someone who has run design reviews.
Ignoring the interviewer’s hints. If they ask “what happens if that server dies?” three times, they are not curious. They are trying to give you points. Take the hint.

🛠️ Try it

Find out the format before you interview. It’s a completely legitimate question to your recruiter:

“Could you tell me what the design round looks like — is it an open-ended architecture question, a low-level/OOP design, or something more focused? And is there a preferred drawing tool?”

Recruiters answer this readily. Candidates rarely ask. It’s free information.

→ Glossary → ROADMAP.md

This site is open source. Improve this page.