The Interview Prep Playbook
Skip the giant reading list. This answers three questions fast — which rounds am I facing, what's my plan, and what do I do in the room — and links straight into the practice on this site.
Built for HLD, LLD, and DSA rounds at Amazon, Google, Meta, PhonePe, Uber, Stripe, Flipkart, and startups.
Step 1 — Which rounds are you facing?
Most loops test two or three of these. Figure out yours from the recruiter, then commit your time to the ones that count.
HLD — System Design
Open-ended "Design X." Tests architecture, trade-offs, and how you scale. 45–60 min, whiteboard/verbal.
39 designs to practice →LLD — Machine Coding
Build a working, modular OOP system in 90–120 min. Tests clean class design, patterns, extensibility.
Machine coding problems →DSA — Coding
Algorithmic problem solving under time pressure. Tests patterns, correctness, and communication.
390 problems + judge →Step 2 — Build your plan
Pick the row that matches you. The plan assumes ~1–1.5 focused hours a day.
- Nail fundamentals first (caching, DBs, queues).
- DSA is usually the main gate — spend most time there.
- 8 beginner/intermediate HLD designs; light LLD.
- All three rounds are in play — balance them.
- Master the 45-min framework + 12–15 HLD designs.
- Practice one full LLD build end-to-end weekly.
- Depth over breadth — advanced deep dives and trade-offs.
- Own the conversation; drive scoping and tech choices.
- Be ready to defend your real production work in the HM round.
Step 3 — What to do in the room (the 45-minute HLD framework)
The single biggest score driver isn’t knowing more tech — it’s running the interview with structure. Spend your time like this:
Clarify functional + non-functional requirements. Pin down scale (QPS, data size, read/write ratio). Write them down.
List core entities and one endpoint per requirement. This anchors the whole design.
Draw the boxes: client → edge → services → data. Introduce components only as a requirement forces them.
Go deep on 2–3 hard parts. For each: naive approach, why it breaks, the fix. This is where senior signal lives.
Call out bottlenecks, failure modes, and what you'd do with more time.
Full breakdown with scripts and the scoring rubric: The 45-Min Interview Framework →
What interviewers actually score
- Scoping — do you ask the right questions before designing?
- Architecture — right components, sensible data flow.
- Depth & trade-offs — can you defend why, not just what? (SQL vs NoSQL is asked in almost every round.)
- Communication — you drive; it’s a conversation, not a monologue.
You are not expected to design a production system. You’re expected to show structured thinking and trade-off awareness.
Step 4 — A curated path (not a reading list)
Twelve designs, in order, chosen so each one teaches a new pattern. Do these deeply — patterns transfer to any “Design X” you’re handed.
- URL Shortener — ID generation, caching, read-heavy scaling
- Rate Limiter — Redis token bucket, shared counters
- Key-Value Store — partitioning, replication, quorum
- Pastebin — object storage, CDN, TTL cleanup
- Chat System — WebSockets, delivery, offline queues
- Notification System — Kafka fan-out, retries, DLQ
- Twitter Feed — fan-out on write vs read, celebrity problem
- BookMyShow — distributed locks, seat holds, payment saga
- Digital Wallet — double-entry ledger, idempotency, saga
- Uber — geo-indexing, real-time matching, surge
- Stock Broker — order matching, event sourcing, CQRS
- Google Docs — CRDT/OT, conflict resolution, presence
Need the fundamentals behind these first? Start at System Design Fundamentals →. Targeting a specific company? See Company-Specific Prep →.
The 6 mistakes that sink interviews
- Jumping to a solution before scoping requirements. Spend the first 5 minutes clarifying.
- Over-engineering — a URL shortener doesn’t need Kafka and 8 microservices.
- Hand-waving scale — “just use a database” is not an answer at 100K QPS.
- Skipping trade-offs — every choice has a downside. Name it before the interviewer does.
- Monologuing — pause, check in, let the interviewer steer.
- Grinding random problems — study by pattern, not by count. 12 deep beats 30 skimmed.
FAQ
How many problems should I practice? 12–15 studied deeply. Understand the patterns; don’t memorize solutions.
Do I need exact numbers? No — just orders of magnitude: one Postgres ≈ 10K QPS, Redis ≈ 100K ops/sec, Kafka ≈ millions of events/sec. See back-of-envelope estimation.
Diagrams or text? Always draw. A simple box-and-arrow diagram communicates more than five minutes of talking.
They asked a system I didn’t prepare — now what? The patterns transfer. Caching, queues, DB choice, and real-time delivery show up everywhere. Apply what you practiced.
Is system design asked at my level? Rarely for new grads, yes for SDE-2 at most top companies, and with higher depth expectations for senior/staff.
Your daily routine
- 30 min — read one concept from Fundamentals
- 60 min — one HLD design (45-min timed attempt, 15-min review)
- 15 min — review the framework patterns, or solve one DSA problem
Keep going
- System Design Fundamentals — CAP, caching, sharding, queues, DBs
- The 45-Min Interview Framework — structure, scripts, scoring
- Company-Specific Prep — Amazon, Google, Uber, Flipkart, PhonePe
- LLD Fundamentals — for machine coding rounds
- DSA Problemset — 390 problems with an in-browser judge
SensAI