--- title: System Design Interview Prep in India (2026): What Actually Gets You Through description: An India-specific guide to preparing for system design interviews at FAANG, Indian product companies, and US-remote roles — what to learn, in what order, and what to ignore. url: https://usegreenroom.app/blog/system-design-interview-prep-india last_updated: 2026-06-11 --- ← Back to blog System design · India # System design interview prep in India (2026): what actually gets you through May 28, 2026 · 13 min read ![System design interview prep in India (2026): what actually gets you through — cover illustration from Greenroom, the AI mock interviewer](/assets/blog/system-design-interview-prep-india-hero.webp) System design is the round that decides most SDE-2 and senior offers in India. The DSA round filters; the design round ranks. And the gap between candidates who pass and candidates who fail isn't usually knowledge — it's *structure*. People who know the same things lose because they can't sequence the conversation. This is an India-specific guide to system design prep. Most of the popular advice online (HiredInTech, Educative's Grokking, Alex Xu's books) is written assuming a US-FAANG-loop reader. Indian preppers face a different shape: more interviews at Indian product companies (Razorpay, PhonePe, Swiggy, Cred, Zomato, Atlassian Bengaluru), more US-remote loops at 10pm IST, and a market where "system design" can mean three different things depending on who's interviewing. ## The three things "system design interview" can mean in India Before you prep, figure out which one you're being interviewed for. They overlap but the prep weight is different. - **Classic high-level design (HLD).** "Design Instagram." "Design a URL shortener." 45–60 minutes, whiteboard or Excalidraw, expected to cover requirements, capacity estimation, API design, data model, deep-dive on one or two components. This is the Google/Amazon/Meta India default. - **Low-level design (LLD) / object-oriented design.** "Design a parking lot." "Design Splitwise." Class diagrams, interfaces, design patterns, sometimes actual code. This is the round Indian product companies — especially Flipkart, Swiggy, PhonePe — lean on heavily for SDE-2. - **Deep-dive on a real system.** "Walk me through a system you built. Why did you pick that DB?" No whiteboard, just conversation. This is what Staff+ and most US-remote roles increasingly do, because it filters for actual production experience. If you don't know which one you're getting, ask the recruiter directly. They will tell you. Indian recruiters are unusually candid about the round structure compared to US ones, because they want the loop to succeed too. ## What system design interviews actually test Most candidates think the round is about whether they know Kafka, Redis, and consistent hashing. It isn't. We have a longer piece on what system design interviews actually test but the short version: interviewers are evaluating four things in real time. - **Do you clarify before you build?** Jumping into a diagram in minute two without asking about scale, read/write ratio, or what "users" means is the most common failure mode for Indian candidates. It usually comes from anxiety, not ignorance. - **Can you make tradeoffs out loud?** "I'd use Cassandra here" is half an answer. "I'd use Cassandra because we're write-heavy and can tolerate eventual consistency for the feed — but if the requirement was strong consistency for payments, I'd reach for a relational store instead" is the answer. - **Do you go deep when pushed?** The interviewer will pick one component and ask you to drill in. If your whole answer was breadth, you'll stall here. Pre-pick a component you can defend at 3 levels of depth before they ask. - **Are you ego-flexible?** When the interviewer says "what if you had 100x the traffic?" the right move is to update your design, not defend the previous one. Indian candidates who came up through competitive programming sometimes treat this as adversarial. It isn't. ## The 8-week prep plan (working professional in India) This assumes you have a target loop 8–12 weeks out and you're working full-time. Adjust scale, not structure. ### Weeks 1–2: vocabulary You can't design a system if you don't have words for its parts. The first two weeks are pure vocabulary acquisition. Read Alex Xu Vol 1 cover to cover — but read each chapter, then close the book and re-explain the system out loud to a wall. If you can't articulate it, re-read. Also read Martin Kleppmann's *Designing Data-Intensive Applications* chapters 1–6. You don't need to finish DDIA — chapters 1–6 give you 80% of the conceptual vocabulary you need. Save the rest for after the loop. End of week 2 check: can you, unprompted, explain — leader-follower replication, multi-leader replication, the CAP theorem (without the meme version), eventual vs strong consistency, why hot partitions happen, what a write-ahead log is, and the difference between vertical and horizontal sharding? If yes, you're ready for week 3. If no, do another week here. ### Weeks 3–4: pattern library System design has a small number of repeated patterns. Once you've seen them, you'll see them everywhere. - Read-heavy systems (newsfeed, timeline) — fanout-on-write vs fanout-on-read. - Write-heavy systems (metrics, logs, location tracking) — buffering, batching, time-series DBs. - Strongly-consistent systems (payments, ledgers, bookings) — distributed transactions, saga pattern, idempotency keys. - Search/discovery (Twitter search, e-commerce search) — inverted indices, Elastic, ranking layers. - Real-time delivery (chat, notifications) — long-poll, WebSocket, server-sent events, pub/sub. - Geo systems (Uber, Swiggy delivery, Zomato) — geohashing, quadtrees, dispatch. For each pattern, design one canonical system. Force yourself to draw the diagram and narrate it out loud. Don't type. The skill you're training is verbal, not written. ### Weeks 5–6: low-level design (if you're targeting Indian product companies) This is where Indian prep diverges from US prep. Flipkart, Swiggy, PhonePe, Cred, and many Bengaluru product companies have a dedicated LLD round. Skipping LLD because you're prepping for Google India is a mistake — even Google India increasingly asks OOD for SDE-2. Cover: parking lot, elevator system, Splitwise, chess, food ordering, ride-sharing dispatcher, BookMyShow, library management. For each: draw the class diagram, identify which design patterns apply (strategy, factory, observer, state are the most common), and write the core 30 lines of code. The Indian LLD interviewer expects: clean interfaces, sensible separation of concerns, knowledge of when to use which pattern (and crucially: when *not* to use one). Over-engineering with patterns is a red flag. ### Week 7: real systems and deep-dives Now read 5–6 engineering blog posts from systems you actually use. This is the most underrated part of Indian system design prep. Specifically: - Razorpay's blog on idempotency for payments. - PhonePe's posts on UPI scale (these are very well-written and Indian-context). - Swiggy's engineering blog on dispatch and assignment. - Cred's blog on event-driven architecture. - For breadth: Uber, Stripe, Discord, Cloudflare engineering blogs. Reading these gives you concrete examples to cite. Saying "Razorpay uses idempotency keys with a 24-hour TTL because…" is dramatically more compelling than reciting a textbook definition. Indian interviewers especially appreciate references to Indian systems they themselves use. ### Week 8: mocks under real conditions This is the most-skipped, most-important week. Two mocks minimum, ideally three. Options: a senior friend (free, quality varies), Interviewing.io (free with caveats, mostly US engineers — useful if you're prepping for US-remote), an AI tool that does voice-based design (we build one, others exist), or your team lead at work if they're willing. The thing you're training in week 8 is *composure under interruption*. A good system design interviewer will cut you off mid-sentence, ask a tangential question, then bring you back. If you've only practiced by yourself, you've never trained that recovery skill. ![Greenroom's five-step framework for answering any system design interview question](/assets/blog/pool-system-design.webp) Five steps that work for any design question — practice saying them out loud. ## The India-specific things US guides skip ### Indian product company LLD is its own discipline If you're interviewing at Flipkart, Swiggy, PhonePe, Razorpay, Cred, Atlassian Bengaluru, Walmart Global Tech, or similar — you will face an LLD round, and US-targeted prep (Educative's Grokking System Design, Alex Xu) will leave you under-prepared. Use the LLD section of the Striver/takeUforward content, or "Low-Level Design Made Easy" type material, in addition to HLD. ### Capacity estimation in Indian numbers "100 million users" is the US default for back-of-envelope. Indian systems often operate at 500M–1B+ (UPI does ~14 billion transactions a month). When designing UPI-style or Aadhaar-style systems, use Indian-scale numbers and reference them explicitly. The interviewer will notice. ### Latency budgets for Indian users If you're designing a consumer system that will serve tier-2/tier-3 India, the network assumptions are different. 4G dominates, not fiber. Median p50 RTT to a Mumbai data center from a tier-3 city is 60–150ms, not 20ms. Mention this. Most candidates default to US/EU latency assumptions and miss obvious mobile-first optimizations. ### UPI, Aadhaar, ONDC — know them If you're interviewing in India in 2026, "design UPI", "design Aadhaar auth", "design ONDC discovery" are now common-enough prompts. You don't need deep expertise but you should have a high-level mental model: UPI is a real-time NPCI-routed messaging system; Aadhaar is a centralized identity with biometric/OTP auth; ONDC is a protocol layer for interoperable commerce. Read one good blog post on each. ### Behavioral context for design rounds Many Indian interviewers blend the design round with "tell me about a system you built." If your honest answer is "I worked on a CRUD API at a service company" — that's still answerable. Pick the most non-trivial decision you made (database choice, caching layer, retry logic) and defend it. Pretending you architected a distributed system from scratch is the wrong move and interviewers spot it immediately. Honesty about scope, ambition about reasoning — that's the right tone. ## What to skip - **Memorising "system design templates."** The 7-step template (requirements → estimation → API → data model → high-level → deep-dive → tradeoffs) is a scaffold, not a script. Reciting it robotically is worse than not having it. - **Alex Xu Vol 2 before Vol 1 is internalized.** Vol 2 is for Staff/Principal candidates. SDE-2 and Senior: stop at Vol 1 plus DDIA chapters 1–6. - **100-hour YouTube playlists.** Pick one Indian creator (Gaurav Sen, or Arpit Bhayani for deeper dives) and stick with them. Five hours of one good explainer beats fifty hours of channel-hopping. - **Designing 30 systems shallowly.** Six systems, three levels deep each, is more useful than thirty systems one level deep. Interviewers always push for depth; breadth without depth is the most common rejection signal. - **Memorising QPS-to-storage estimation formulas.** Know how to derive them. Memorised numbers fall apart the moment the interviewer changes a variable. ## The honest thing about practicing alone System design is the round where solo practice has the steepest diminishing returns. You can grind 200 DSA problems alone and meaningfully improve. You can't grind 50 system designs alone and meaningfully improve — because the skill is verbal, adaptive, and conversational. The best approximation if you can't get human mocks: design out loud, on a whiteboard or Excalidraw, while recording yourself. Then play it back. The first time you hear yourself fumble a tradeoff explanation is the moment the round starts to click. It's uncomfortable. Do it anyway. The second-best approximation: an AI tool that pushes back, asks "what if" questions, and forces you to defend choices. This is exactly the gap we built Greenroom for — voice-based design conversations with an interviewer (Ari) who actually interrupts and asks follow-ups, instead of accepting your first answer. ## One thing I wish someone told me earlier You will not "know" enough on the day of the interview. Nobody does. The senior engineers who pass these rounds aren't the ones who memorised more systems — they're the ones who built a habit of *thinking out loud while making tradeoffs*. That habit is the entire skill. If you take one thing from this guide: stop reading and start narrating. Pick a system right now — newsfeed, payment ledger, ride dispatch, doesn't matter — and design it out loud for twenty minutes. You'll learn more in those twenty minutes than in the next three hours of reading. If you want to practice system design conversations out loud — with an interviewer who pushes back when your tradeoffs are vague — Greenroom's free tier includes voice mocks with system design prompts tailored to your background. Try it at usegreenroom.app. And if you're earlier in prep, our piece on preparing for FAANG interviews in India covers the wider timeline this fits into. ## Frequently asked questions ### How many weeks do I need to prepare for system design interviews? About eight weeks of structured prep works for most working engineers: two weeks of building blocks, four weeks of guided problem practice out loud, two weeks of full mock rounds. Passive video-watching doesn't count toward any of it. ### What's different about system design interviews in India? Indian product companies often probe cost-consciousness and scale realism more than US guides assume, and many loops include a machine-coding or low-level design round US-centric material skips entirely. Prepare for both HLD and LLD. ### What should I skip in system design prep? Memorizing reference architectures for fifty systems, niche technologies you've never used, and any prep that doesn't involve speaking. Depth on one design you can defend beats breadth on ten you can only recite. ### How do I know if my design answers are good enough? If you can state requirements, defend your numbers, and name the failure modes without being prompted, you're at the bar. The reliable test is a mock with follow-ups — alone, you grade yourself too generously.