Start with fundamentals — load balancing, caching, SQL vs NoSQL, replication, sharding, and message queues — then learn a repeatable framework: clarify requirements, estimate scale, define APIs, model the data, draw the architecture, and discuss bottlenecks and trade-offs. Study 10–15 classic designs such as URL shortener, rate limiter, chat app, news feed, and ride sharing, and rebuild them yourself instead of only reading. Spread the preparation over 6–8 weeks with one design every two days, and finish with mock interviews so you can present designs confidently out loud, not just on paper.

Make solo practice realistic: pick a prompt, set a 35–45 minute timer, sketch the architecture on paper or a whiteboard, and narrate your decisions aloud as if the interviewer were present. Then compare your design with strong reference solutions and note the gaps in caching, partitioning, or trade-offs you missed. The one thing solo practice cannot give you is feedback on communication and structure, so plan a few sessions with a peer or an experienced interviewer before your actual round.

Follow a fixed sequence: (1) clarify functional and non-functional requirements, (2) estimate scale — users, QPS, storage, bandwidth, (3) define the API, (4) design the data model, (5) draw the high level architecture, (6) deep-dive into one or two components such as caching, sharding, or queues, and (7) close by discussing bottlenecks and single points of failure. Keep talking throughout, justify every trade-off, and treat the interviewer as a teammate you are designing with rather than an examiner.

The most frequently asked include designing a URL shortener, rate limiter, chat app like WhatsApp, news feed like Instagram or Twitter, video platform like YouTube, ride-hailing app like Uber or Ola, typeahead search, web crawler, notification system, and a distributed message queue. Indian product companies often lean towards payment, wallet, and notification designs since they map to real business problems. Instead of memorising solutions, learn the underlying patterns — caching, partitioning, queues, and consistency trade-offs — because interviewers routinely twist the question mid-round.

It is a well-known online course that teaches system design through classic problems such as URL shortener, rate limiter, and web crawler using a repeatable template for each solution. For most candidates it works as a gentle first step because it quickly builds vocabulary and a basic framework. Since it is so widely known, interviewers now expect more than its standard answers, so pair it with varied practice, live discussion of unfamiliar designs, and timed mock rounds.

System Design Interview by Alex Xu (Volumes 1 and 2) is the most widely recommended system design interview book and does an excellent job of teaching step-by-step reasoning for classic high level design problems. Treat it as a foundation, not complete preparation. It covers HLD only, so if your interview also includes LLD or machine coding you need separate practice there, and you still must practise designing aloud under time pressure. Read a chapter, then immediately apply the concepts in timed mock sessions.

High level design (HLD) describes the overall architecture of a system — major components, services, databases, tech stack, and how data flows between them. Low level design (LLD) zooms into one component and defines its internals — classes, interfaces, relationships, design patterns, and often working code. Simply put, HLD answers "what are the parts and how do they connect," while LLD answers "how is each part actually built." In India, HLD rounds usually appear for mid to senior roles, while LLD and machine coding rounds are common even at 2–3 years of experience.

A practical sequence is: (1) strengthen OOP fundamentals — encapsulation, inheritance, polymorphism, abstraction, (2) learn SOLID principles with real code examples, (3) understand UML and class diagrams, (4) study core design patterns across creational, structural, and behavioural categories, (5) solve classic problems like parking lot, Splitwise, LRU cache, and elevator, and (6) implement complete working code, not just diagrams. End with feedback through peer reviews or mock interviews. Most people need 6–8 focused weeks on this path to become interview-ready.

Practise the way machine coding rounds actually run: fix one language, clarify requirements first, identify core entities, define classes and relationships, apply suitable design patterns, and produce clean, runnable code within 45–60 minutes. Start with 10–15 classic problems, then attempt unfamiliar ones to test adaptability, and review your own code for SOLID violations and tight coupling. Since self-evaluation in LLD is hard, get a few sessions reviewed by a peer or an experienced interviewer — they catch extensibility issues you will miss alone.

The classics repeat across companies: parking lot, Splitwise or expense sharing, BookMyShow or movie ticket booking, elevator system, LRU cache, cab booking like Uber or Ola, vending machine, logger framework, chess or tic-tac-toe, snake and ladder, and a notification system. Interviewers judge how you clarify requirements, choose entities, apply design patterns, and extend the design when new constraints are added. Practise each problem end-to-end with working code, because in machine coding rounds a compiling, well-structured solution matters more than a perfect diagram.

Focus on the patterns that map naturally to interview problems: Singleton for shared resources, Factory and Abstract Factory for object creation, Builder for complex objects, Strategy for interchangeable behaviour like payment methods, Observer for event and notification flows, Decorator and Adapter for extending behaviour, State for vending machines and elevators, and Command or Chain of Responsibility for request handling. Do not memorise definitions — interviewers ask you to justify where a pattern fits and what breaks without it, so learn each one through an implemented example.

Fix one language, then prepare pattern-wise: arrays and hashing, two pointers, sliding window, stacks and queues, binary search, linked lists, trees and BSTs, heaps, graphs with BFS and DFS, greedy, and dynamic programming. Aim for 250–350 well-understood problems rather than hundreds of rushed ones, and revisit every pattern you get wrong. Add weekly timed sessions where you code while explaining your approach, since communication is graded too. In the final weeks, shift to mock interviews and company-style questions to build stamina for a 45–60 minute round.

Freshers are tested heavily on fundamentals: array operations like rotation and Kadane's algorithm, string problems such as palindromes and anagrams, linked list reversal and loop detection, valid parentheses, binary search variants, sorting algorithms with complexities, tree traversals, hashmap problems, recursion, and basic dynamic programming like climbing stairs or coin change. Expect a follow-up on time and space complexity for every solution you give. Alongside DSA, many Indian companies also check CS fundamentals — operating systems, DBMS, networks, and OOP — so balance your preparation accordingly.

Java remains the most common DSA language in Indian interviews, so prepare in Java itself. Master the collections you will use daily — HashMap, HashSet, ArrayList, LinkedList, PriorityQueue, ArrayDeque, and TreeMap — and understand their internal working, since questions on how HashMap works come up very often. Use StringBuilder for string building, know how Arrays.sort works with custom comparators, and guard against integer overflow by using long where needed. Practise writing clean, compiling code with meaningful variable names, because interviewers assess readability along with correctness and complexity.

Yes — the gap mock interviews expose is usually communication, not knowledge. Many candidates solve problems quietly but struggle to think aloud, structure their approach, clarify requirements upfront, or recover when stuck, and these are exactly what interviewers grade. A good mock replicates the 45–60 minute pressure, forces you to defend your trade-offs, and ends with specific feedback you can act on. Do three to five mocks in the final month — with peers or with an experienced interviewer — and treat every piece of feedback as a checklist item for the next round.