Amazon is the most popular product company target for Indian engineers — and also the one with the highest failure rate not because of DSA, but because of Leadership Principles (LPs). Most candidates from TCS, Infosys, and Wipro prepare 300 LeetCode problems and zero LP stories. They get filtered in round 2.
The brutal truth: Amazon interviewers are explicitly trained to probe for LP evidence in every round. There is no "skip the behavioral" option at Amazon. If your LP stories are weak, it doesn't matter how clean your code is.
Here's exactly what happens after you apply or get a referral for Amazon India:
Conducted on HackerRank. 2 coding questions (medium to hard difficulty). Auto-graded — no partial credit for wrong output. Also includes work styles survey (LP proxy).
1-2 DSA problems + 2-3 LP questions. Done via Chime (Amazon's tool) or phone. Purpose: filter before expensive onsite loop.
Each round has a designated interviewer with a role: coding, system design, or LP-heavy. All rounds include LP questions regardless of focus.
| Round Focus | Typical Duration | What to Expect |
|---|---|---|
| Coding Round 1 | 60 min | 1-2 DSA problems + 2 LP questions |
| Coding Round 2 | 60 min | 1-2 DSA problems + 2 LP questions |
| System Design | 60 min | Design problem (scale) + 1-2 LP questions |
| Bar Raiser | 60 min | Harder LP probe + 1 DSA or design curveball |
All interviewers submit written feedback with LP ratings. HM and Bar Raiser review. Compensation offer is made if approved — usually within 1-2 weeks of loop.
Amazon's LPs aren't just corporate values — they're a structured hiring framework. Every interviewer is assigned specific LPs to probe. Here's what each means in practice:
Show you start with what the customer needs, not what's technically easy. Story: when you pushed back on a feature because users didn't need it, or caught a bug that would have affected customers.
Act beyond your job description. Story: when you fixed something that wasn't your task, or took responsibility for a production incident even though it wasn't your code.
Find simpler solutions or new approaches. Story: when you proposed a novel solution, simplified a complex process, or automated manual work.
Have strong judgment. Story: when you predicted a technical risk before it happened, or called a bad design decision early.
Self-directed learning. Story: when you picked up a new technology on your own, or learned a domain outside your role to solve a problem.
Raise the bar for your team. Story: when you mentored a junior, conducted effective interviews, or helped someone improve their skills.
High quality, refuse shortcuts. Story: when you caught a quality issue others missed, or added tests/monitoring that prevented a future incident.
Ambitious vision. Story: when you proposed a large-scale change, or reframed a small problem as a platform opportunity.
Move fast, calculated risk. Story: when you launched something despite uncertainty, or made a decision with incomplete information and explained your reasoning.
Achieve more with less. Story: when you optimized cost, reduced infra spending, or solved a problem without asking for more resources.
Honest, credible. Story: when you admitted a mistake, gave honest feedback even when uncomfortable, or shared bad news directly.
Data-driven, detail-oriented. Story: when you dug into metrics/logs to find a root cause others had missed, or insisted on understanding the data before making a decision.
Push back, then commit. Story: when you disagreed with a manager or team decision, expressed it clearly, but executed the final call fully once decided.
Hit goals, handle obstacles. Story: when you completed a high-stakes project under pressure, or navigated scope changes to still deliver.
Team wellbeing, inclusion. Story: when you supported a struggling team member, created a safe environment for feedback, or improved team dynamics.
Long-term societal impact. Story: when you considered ethical implications, accessibility, or environmental impact of a technical decision.
Amazon expects structured answers. Rambling or vague stories fail. Use STAR with 40% emphasis on Result — Amazon cares about outcomes, not effort.
The Bar Raiser is one of the most misunderstood parts of the Amazon interview. Here's what you need to know:
| Aspect | Details |
|---|---|
| Who is a Bar Raiser? | A trained interviewer from a completely different team — not your hiring team |
| Their mandate | Ensure the hire raises the team's average, not just meets it |
| Can they veto? | Yes — even if all other interviewers say "hire", the Bar Raiser can block it |
| How to identify | Usually the last round; may have a different background from the role |
| What they probe | Deeper on LPs — especially Ownership, Deliver Results, Have Backbone; may ask curveball DSA |
| What impresses them | Intellectual honesty, pushback on ambiguous questions, meta-reasoning about tradeoffs |
Amazon's coding rounds are medium-to-hard difficulty with an emphasis on correctness, edge case handling, and clean code. They value production-ready thinking over clever one-liners.
| Topic | Frequency | Key Patterns |
|---|---|---|
| Arrays & Strings | Very High | Two pointers, sliding window, prefix sum |
| Trees (BST, Binary Tree) | Very High | DFS/BFS, LCA, path sum, serialize/deserialize |
| Linked Lists | High | Reverse, detect cycle, merge, find middle |
| Graphs | High | BFS, DFS, topological sort, union-find |
| Dynamic Programming | Medium | 1D/2D DP, knapsack, subsequence |
| Stacks & Queues | Medium | Monotonic stack, LRU cache, BFS queue |
| Hash Maps & Sets | High (utility) | Frequency map, two-sum, grouping |
| Heaps | Medium | Top-K elements, merge K sorted lists |
These are reported frequently by candidates — exact questions change, but patterns repeat.
Amazon's system design round tests whether you can design real distributed systems at Amazon scale (millions of req/sec, global distribution). The focus is on scalability, reliability, and operational excellence — all LP-aligned.
Assume components will fail. Design for multi-AZ, circuit breakers, retries with exponential backoff, and graceful degradation.
Mention metrics, dashboards, alarms, and runbooks. Amazon engineers own their services end to end — "you build it, you run it."
Tie your design choices to cost. Caching reduces DB calls → cost savings. Frugality is an LP. Show cost-aware architecture.
Know when to use eventual consistency vs strong consistency. Amazon services often choose availability over consistency (AP in CAP).
If you're currently at a service company targeting Amazon, here's a realistic structured plan:
Amazon India offers are structured differently from Google/Microsoft — with a heavier emphasis on RSUs and signing bonus:
| Level | Base Salary | RSU (annual vest) | Signing Bonus | Total (Year 1) |
|---|---|---|---|---|
| SDE-I | ₹30-40 LPA | ₹15-25 LPA | ₹10-20 LPA | ₹55-85 LPA |
| SDE-II | ₹40-60 LPA | ₹30-50 LPA | ₹20-35 LPA | ₹90-145 LPA |
| SDE-III (Sr.) | ₹60-80 LPA | ₹60-100 LPA | ₹30-50 LPA | ₹150-230 LPA |
| Principal SDE | ₹80-120 LPA | ₹100-200 LPA | Negotiable | ₹250-400+ LPA |
Prepflix's structured interview courses are designed by an ex-Microsoft engineer with IIT Kanpur background — covering DSA patterns, system design, and mock interviews.
Start Prep Free →Always prepare 2-3 questions per round. This signals genuine interest and helps you evaluate the team:
Join thousands of Indian engineers who have used Prepflix to move from service companies to Amazon, Google, and Microsoft.
Start Structured Prep →