Structure your preparation around four pillars: DSA, system design basics, core CS subjects (OS, DBMS, computer networks), and resume projects you can defend in depth. Give DSA roughly half of your total prep time and focus on core patterns — arrays, hashing, two pointers, binary search, trees, graphs, and dynamic programming — before attempting random problems. Solving 250–300 problems with full understanding beats grinding 700 without revision. In the final 3–4 weeks, add timed mock interviews, because most candidates fail product-based company rounds on execution and communication, not knowledge.

Plan for 1.5–2 focused hours on weekdays and longer blocks on weekends, since experienced rounds expect a depth you cannot build overnight. Weight your prep towards LLD, HLD, and deep project discussions — interviewers assume DSA fluency at this level and probe how you design real systems and justify trade-offs. Reserve one weekend slot every week for a full 60-minute mock interview under real conditions. Start applying only when you can consistently solve hard mediums in under 30 minutes and talk through a system design without prompting.

Use a pattern-based plan: month one for arrays, strings, hashing, linked lists, stacks, and binary search; month two for trees, graphs, heaps, recursion, and dynamic programming; month three for revision, company-tagged problems, and timed mocks. Two focused hours daily with weekly revision beats irregular long sprints. Track every problem in a sheet with the pattern used and the mistake you made, and re-solve every failed problem after a week.

Never go silent — restate the problem in your own words, clarify constraints, and dry-run a small example to spot the pattern. Start with the brute-force solution, state its complexity, and improve it step by step, because interviewers evaluate your reasoning path far more than a memorised optimal answer. If you are still stuck, say which technique you are considering (hashing, two pointers, BFS/DFS, DP) and why. Asking for a small hint is acceptable; freezing completely is not.

Product company rounds revolve around a fixed set of patterns rather than thousands of unique problems: sliding window, two pointers, binary search on the answer space, BFS/DFS on trees and graphs, top-k problems using heaps, interval merging, and dynamic programming classics like LCS, LIS, and 0/1 knapsack. Memorising answers fails because interviewers twist the problem statement. Instead, master the underlying pattern, practise explaining your approach before coding, and always state time and space complexity.

Freshers are mostly tested on clean implementations of standard patterns, CS fundamentals, and raw problem-solving potential, so lists of DSA interview questions and answers for freshers stay close to arrays, strings, linked lists, and basic DP. In contrast, DSA interview questions and answers for experienced levels typically combine two or three concepts in one problem, add follow-ups on edge cases and scalability, and come paired with LLD or system design rounds where your past work is probed in depth. The core patterns stay the same; the bar for speed, code quality, and trade-off reasoning rises sharply.

Java is completely acceptable for interviews at almost every product-based company, including Amazon, so there is no need to switch if you are already comfortable with it. Interviewers judge your logic, complexity analysis, and code cleanliness, not the language. Just make sure you are fluent with Java collections like HashMap, PriorityQueue, and ArrayDeque, since fumbling syntax wastes precious interview minutes. Switch languages only for niche roles that mandate a specific one, such as some low-latency or HFT roles asking for C++.

GeeksforGeeks is a strong starting point — its company-wise archives, standard problem lists, and interview experiences are genuinely useful for Indian aspirants. On its own, though, it is rarely enough for product-based companies, because you also need timed practice on unseen problems, spaced revision, and a few full-length mock interviews. A good split: use GeeksforGeeks to learn patterns and read real interview experiences, then validate yourself by solving unseen problems without looking at any solution.

Learn a repeatable framework first: gather functional and non-functional requirements, estimate scale, define APIs, design the data model, draw the high-level architecture, and close with bottlenecks and scaling choices. Then study standard problems — URL shortener, chat system, news feed, rate limiter, notification system — and practise drawing each from a blank page. You do not need production experience to clear a system design interview; you need structured thinking, and mock interviews are the fastest way to convert reading into speaking confidence. SDE-1 rounds usually stay at basic HLD, while SDE-2 rounds push deeper into trade-offs.

Spend the first five minutes clarifying requirements and scope, the next five to ten estimating scale (QPS, storage, bandwidth) and defining APIs, and then move to the data model and database choice. Next, draw the high-level diagram, deep-dive into one or two components — caching, sharding, queues, replication — and finish by discussing bottlenecks, failure handling, and trade-offs. Narrate every decision out loud; a silent candidate loses the round even with a technically correct final design.

The classics repeat across companies: design a URL shortener, a Twitter/Instagram-style news feed, a WhatsApp-style chat system, a YouTube-style video platform, a ride-matching app, a rate limiter, a notification system, a web crawler, and a distributed message queue. For SDE-2 roles in India, expect LLD twists as well, such as a parking lot, BookMyShow, or Splitwise. Practising eight to ten of these end to end covers most system design interview questions you will realistically face.

Grokking the System Design Interview works well as a first pass because it walks through classic problems step by step in a fixed template, while the System Design Interview by Alex Xu goes deeper into diagrams, back-of-envelope math, and trade-offs, making it the better second pass and long-term reference. Most successful candidates combine one structured course with one book and then reinforce both by designing systems aloud. Neither resource replaces speaking through a design under mock conditions, which is where most people actually discover their gaps.

Self-study is enough if you have the discipline to follow a roadmap for three to four months and can honestly assess your own mock performance. A course or mentor earns its cost in three situations: you are moving from a service-based to a product-based company, you have failed interviews without clear feedback, or your timeline is under three months. Prioritise programmes that include live mock interviews and personalised feedback over ones that only resell recorded lectures — passive video content rarely changes interview outcomes.

A practical SDE interview preparation roadmap spans 12–16 weeks: weeks 1–4 on core DSA patterns, weeks 5–8 on advanced DSA with weekend HLD basics, weeks 9–12 on system design depth, LLD, and CS fundamentals revision, and the final month on company-specific questions, behavioural stories, and four to six full mock interviews. Two hours on weekdays plus longer weekend sessions is sustainable alongside a full-time job. Start applying once you are consistently solving mediums within 25–30 minutes, not after "finishing" every resource.

Amazon's process typically includes an online assessment, one or two phone screens, and a loop covering DSA coding, LLD or HLD, and a heavy behavioural section driven by Leadership Principles. Build your prep across three tracks: LeetCode practice weighted towards Amazon-tagged questions, twelve to fourteen personal stories written in STAR format and mapped to Leadership Principles, and weekly design practice. Many strong coders get rejected at Amazon for weak behavioural answers, so treat Leadership Principle preparation as seriously as coding.