How to Crack the Amazon SDE Interview in India (2026 Guide)

Amazon is one of the most sought-after product companies for software engineers in India — and one of the most misunderstood from a prep standpoint. Most candidates treat it like an extended LeetCode session and walk in underprepared for the part that eliminates the most people: the Leadership Principles round.

This guide covers the full Amazon SDE interview process, what each round actually tests, and how to prepare for both halves.

The Amazon SDE Interview Structure

Amazon India typically runs the following rounds for SDE-1 (fresher/new grad) and SDE-2 (2–5 years of experience):

1. Online assessment (OA) — 2 coding problems in 90 minutes, on HackerRank. Difficulty ranges from medium to hard.
2. Technical phone screen — 1 coding question + a few clarifying discussions on your resume. Sometimes skipped for campus hires.
3. On-site / virtual on-site loop — 4–5 rounds of 45–60 minutes each, conducted back-to-back on the same day. Each round covers both DSA/coding and Leadership Principles (LP).

There is no separate "HR round" at Amazon. Leadership Principles questions are woven into every technical round. The interviewers debrief together after the loop and each one gets a vote: Strong Hire, Hire, No Hire, or Strong No Hire.

The Leadership Principles: What They Actually Test

Amazon runs its entire business on 16 Leadership Principles — from "Customer Obsession" to "Bias for Action." Every interviewer is assigned 1–2 LPs to probe in their round, and they are looking for evidence from your past behaviour, not your opinions.

The question format is almost always: "Tell me about a time when…"

• "…you had to make a decision with incomplete information."
• "…you disagreed with a manager and pushed back."
• "…you delivered results despite significant obstacles."

These are not warm-up questions. At Amazon, an otherwise strong technical performance can result in a No Hire if the LP answers are weak.

What "weak" looks like:

• Vague answers ("I always try to be customer-focused…")
• Using "we" throughout without saying what you specifically did
• No measurable outcome at the end of the story

What "strong" looks like:

• Crisp STAR format: Situation → Task → Action → Result
• Clear ownership ("I decided to…", "I pushed back by…", "I volunteered to…")
• A concrete result — even "we shipped 2 weeks ahead of schedule" or "the bug rate dropped by 40%"

Building Your LP Story Bank

You do not need 16 different stories. Five to seven well-built stories can flex across most LPs if you know which dimensions each one demonstrates.

Pick your best 5–7 experiences from projects, internships, or college work, and for each one note which LPs it covers. A story about a difficult technical decision under time pressure can cover: Bias for Action, Ownership, Are Right, A Lot, and Deliver Results — depending on how you frame it.

Do not memorise word-for-word scripts. Memorise the skeleton — the key facts, your action, and the metric — and let the words flow naturally. Scripted answers sound hollow in the room.

Coding / DSA: What Gets Asked

Amazon's coding bar is consistent across rounds. You will almost always see problems from these areas:

• Arrays and strings — sliding window, two-pointer, prefix sums
• Trees and graphs — BFS/DFS, LCA, serialisation
• Dynamic programming — medium complexity (coin change, knapsack variants)
• Heaps and priority queues — top-K problems, merge-K lists
• Linked lists — reversal, cycle detection, merging

SDE-1 questions typically sit at LeetCode Medium. SDE-2 rounds add harder mediums and the occasional Hard.

What Amazon interviewers notice beyond correctness:

• Do you clarify edge cases before writing any code?
• Do you state your time and space complexity unprompted?
• Can you optimise if they push back ("can you do better than O(n²)?")?
• Do you test your own code with an example before saying you're done?

Running through 150–200 LeetCode problems is less effective than running through 80 problems and practising the communication habits above on every single one.

System Design (SDE-2 and Above)

If you are interviewing for SDE-2, one of the five rounds will be a full system design session. Common prompts: design a URL shortener, design a notification service, design Amazon's recommendation feed.

The format interviewers expect:

1. Clarify requirements (2–3 minutes) — ask about scale, read/write ratio, latency requirements
2. High-level architecture — draw the key components and their interactions
3. Deep dive on one component — the interviewer will ask you to go deeper on one piece
4. Trade-off discussion — why this approach over alternatives?

Focus especially on: load balancing, caching strategies, database choice (SQL vs NoSQL and why), and handling failures gracefully. For Indian candidates preparing from scratch, System Design Interview by Alex Xu and the Grokking the System Design Interview course are the most commonly used resources.

Practical Prep Timeline

| Weeks out | Focus | |-----------|-------| | 8–10 weeks | LeetCode: 3–4 problems per day, all core topics | | 6–8 weeks | Build and drill your LP story bank (5–7 stories) | | 4–6 weeks | Mock LP rounds — answer out loud, time yourself | | 2–3 weeks | System design (SDE-2) or OA simulation (SDE-1) | | Final week | Review weak spots, light practice, rest |

A Note on the OA

Amazon's OA catches many candidates off guard because it includes a work simulation section alongside the coding problems — short scenarios asking how you would respond to a workplace situation. These are scored against the Leadership Principles. Answer the way a high-ownership, customer-first person would respond, not the way you think an "ideal" employee would. They are not the same thing.

What Separates Hired from Rejected

The candidates who make it through Amazon loops share one pattern: they treat the LP rounds with the same rigour they bring to DSA prep. They have practised their stories out loud, timed their answers, and refined them based on feedback — not just written them down in a doc and assumed they are ready.

Prepare both halves, and the loop becomes very predictable. Skip one, and the other rarely saves you.