Build fundamentals first — scalability, load balancing, caching, SQL vs NoSQL, sharding, replication, message queues, and consistency trade-offs. Then study 10–15 classic designs like a URL shortener, chat app, news feed, ticket booking, and rate limiter, and practise sketching each end to end within 40–45 minutes. Do multiple passes of the same design, note the trade-offs you made, and reinforce everything with mock interviews so you can confidently defend your decisions.

Pick one problem every few days, set a 45-minute timer, and draw the complete design yourself — requirements, capacity estimates, API design, data model, and scaling choices — before looking at any reference solution. Compare your design with standard approaches, note the gaps, and redo the same problem after a week. Practising aloud in mock interviews with a peer or mentor closely simulates the pressure of the real round.

Follow a clear structure: clarify functional and non-functional requirements, estimate scale (users, QPS, storage), present a high-level block diagram, then deep-dive into data models, APIs, and bottlenecks. Keep talking through trade-offs instead of silently drawing, and if time runs short, prioritise the component the interviewer keeps probing. Interviewers evaluate the structure of your thinking as much as the final design.

The classics include designing a URL shortener, a WhatsApp-style chat app, an Instagram-style feed, a BookMyShow-style ticket booking system, an Uber-style ride matching service, a rate limiter, a notification system, and a distributed key-value store. These remain popular because they let interviewers test caching, sharding, consistency, and queueing decisions in a single discussion. Thoroughly practising these 8–10 designs covers a large share of what gets asked in India.

Grokking the System Design Interview is an online course that teaches a repeatable template for common design problems, while System Design Interview by Alex Xu is a two-volume book that walks through each design step by step with detailed diagrams. Many candidates use the course for quick pattern coverage and the book for depth, then reinforce both by re-attempting the same problems on their own whiteboard.

Prepare topic by topic rather than problem by problem — arrays, strings, hashing, two pointers, sliding window, linked lists, stacks, trees, heaps, graphs, recursion, and dynamic programming. Solve a fixed set of problems daily, revise patterns weekly, and maintain a mistake log of problems you got wrong. In the final 2–3 weeks, shift to timed mock interviews and company-tagged questions so the real round feels familiar.

Never jump straight into coding. Restate the problem, clarify edge cases, start with a brute-force approach and its complexity, then optimise step by step while thinking aloud. After coding, dry-run your solution on an example, state the final time and space complexity, and mention how you would handle edge inputs — this structure earns credit even when your first solution isn't optimal.

Freshers are usually tested on OOP concepts, SQL and core DBMS topics like joins, indexes, and transactions, OS and networking basics, HTTP and REST APIs, and deep knowledge of one programming language. Expect follow-up questions linking these to your projects — why you chose a schema, how your API handles errors, what happens under load. One small, well-explained project often impresses more than several half-finished ones.

For experienced candidates, the bar shifts from textbook theory to design judgement — expect deeper system design rounds, questions on scaling and reliability drawn from your actual projects, microservices and messaging decisions, and real debugging scenarios. Interviewers probe why you made certain architectural choices and what trade-offs you accepted, so prepare concrete stories from production work rather than memorised definitions.

Don't memorise answer lists — for each question, understand the underlying concept, write the answer in your own words, and say it aloud in under two minutes as if explaining to an interviewer. Group questions by theme (APIs, databases, caching, security, messaging) and connect each one to something you've actually built. This makes your answers sound natural and confident instead of rehearsed.

The bulk of questions come from arrays, strings, hashing, two pointers, sliding window, linked lists, stacks and queues, binary trees and BSTs, heaps, graphs (BFS and DFS), recursion, greedy techniques, and dynamic programming, along with time and space complexity analysis. If you're short on time, prioritise arrays, strings, hashing, trees, graphs, and DP — together they account for the majority of questions asked across product companies.

Service-based companies in India typically test fundamentals — arrays, strings, sorting, SQL, and sometimes aptitude — while product-based companies ask medium-to-hard problems on graphs, dynamic programming, and optimisation with strict time limits. Go deeper on patterns for product roles, focus on speed and accuracy for service roles, and always check recent interview experiences for the specific company you're targeting.

Yes — Java, C++, and Python are accepted almost everywhere, and interviewers judge your approach, not your language. Java is a safe choice because its Collections framework (HashMap, PriorityQueue, Arrays.sort) speeds up implementation, and for Java backend roles it also signals comfort with the stack you'll use on the job. Just make sure you're fluent with the standard library before interview day.

They're a strong starting point because they show what companies actually ask, but product-based interviews go deeper — you'll face follow-up "why" questions, twisted variants of standard problems, and design discussions that listed answers don't fully cover. Use such question banks to map the syllabus, then practise explaining, coding, and defending every concept yourself, ideally with feedback from mock interviews.