Last checked against Amazon's official hiring pages: 10 October 2026.
Amazon publishes more about its hiring process than most employers, so you don't need to rely on rumours. Its How We Hire hub lists four broad steps — online application, assessments, phone screening and the interview loop — and says the process differs from role to role. This guide explains what Amazon's own pages say about each step, then gives you a practical way to prepare.
An earlier version of this article mostly walked through the Leadership Principles with invented "real examples" and figures. We removed those. For the principles themselves, see our separate guide, Amazon Leadership Principles explained.
Step 1: Application
Apply through amazon.jobs and filter by location if you are looking for roles in India. Read the job description's basic and preferred qualifications carefully; they tell you which skills the loop is likely to probe. Keep a copy, because postings can close.
Keep preparing
Continue with Top 50 Interview Questions₹299 — coaching के एक महीने से काफ़ी सस्ता / far cheaper than a month of coachingStep 2: Online assessment
Many technical and university roles start with an online assessment (OA). Amazon's OA prep page for university SDE roles gives the components and their average times:
| OA for | Component | Average time |
|---|---|---|
| Full-time SDE | Coding assessment | 70 minutes |
| Full-time SDE | Workstyles Assessment | 15 minutes |
| Full-time SDE | Work Simulation | 60 minutes |
| Full-time SDE | Feedback Survey | 5 minutes |
| SDE internship | Coding Assessment, Workstyles Assessment and Feedback Survey (no Work Simulation) | About 90 minutes in all |
The page sets out clear rules for the coding portion. You may use publicly accessible online resources, such as language documentation, but not sites that need a login or private repositories, and browser usage is logged. Avoid copying and pasting, because Amazon expects your own code. Don't use print screen: the page warns that your session will be terminated and you will be locked out. The feedback survey at the end is required, and skipping it delays your results.
Practical advice from the same page: practise in the language you plan to use, take the unscored practice test, and if you get stuck, move on and come back.
Step 3: Phone screen
For many roles, a phone or video screen comes next. Amazon describes the content only as varying by role, so treat it as a smaller version of the loop: expect technical questions for technical roles and behavioural questions tied to the Leadership Principles. Have your best two or three stories ready.
Step 4: The interview loop
The loop is a set of one-to-one interviews with current employees, each focusing on different areas. Amazon's SDE II interview prep page is the most specific official description we found:
- Four 55-minute interviews with members of the software development community.
- Interviewers evaluate different technical and non-technical competencies, based on the Leadership Principles.
- Each interviewer typically asks two or three behavioural questions. Amazon says it won't ask brain teasers.
- Expect at least one software systems design question, and ask questions to complete and validate your design.
- Coding must be syntactically correct — "no pseudo code" — and should be scalable, robust and well tested, with edge cases checked and bad input handled.
- Use the STAR method, and include metrics or data where applicable.
Other roles have their own prep pages on the How We Hire hub, from front-end and data roles to product and program management, so read the one that matches your job.
Who the Bar Raiser is
Amazon's corporate article on how Amazon hires describes a Bar Raiser as an interviewer brought into hiring loops as an objective third party, trained after being nominated and accepted into the programme. It calls the role a steward of Amazon's 16 Leadership Principles, and says Bar Raisers help ensure a fair discussion among the whole loop and provide written feedback. You usually won't know which interviewer is the Bar Raiser, so treat every conversation as equally important.
The hub also mentions Candid Chats, an option to meet a member of an employee-led group during your process, and a route to request accommodations.
Worked example: how many stories do you need?
The SDE II numbers make the arithmetic simple. Four interviews with two or three behavioural questions each means roughly 8 to 12 behavioural questions across the loop (4 × 2 = 8; 4 × 3 = 12). One or two favourite stories won't stretch that far.
Here is an illustrative story bank for a fictional engineer with three years' experience. Each story can serve more than one principle, but each principle has at least two possible stories.
| Story (fictional) | Strongest principles it can show | Metric to quote |
|---|---|---|
| Cut API latency after customers complained | Customer Obsession, Dive Deep | p95 latency before and after |
| Took over a failing release no one owned | Ownership, Deliver Results | Release date met or missed, defects found |
| Replaced a manual report with a script | Invent and Simplify, Frugality | Hours saved per week |
| Disagreed with a design and later accepted the team's choice | Have Backbone; Disagree and Commit | What changed after the decision |
| Shipped a feature that underperformed | Learn and Be Curious, Are Right, A Lot | Adoption numbers and what you changed |
| Mentored a new joiner through an outage | Hire and Develop the Best | Time to independent on-call |
| Shipped a fix with partial data under a deadline | Bias for Action | Impact and what you checked later |
| Pushed back on a vendor's unsafe shortcut | Insist on the Highest Standards | Issue avoided |
Write each story in STAR form, keep it to about two minutes, and know the real numbers. If you don't have a metric, say what you observed rather than inventing one.
Preparing for the technical parts
- Coding: practise writing complete, compilable code in one language without autocomplete. Say your test cases out loud, including empty input, duplicates and very large values.
- System design (experienced roles): practise structuring a 35–45 minute design: requirements, API, data model, scaling, failure handling and trade-offs. Ask clarifying questions first, as Amazon's page recommends.
- Data and metrics: Amazon describes itself as data-driven, so for each project know how you measured success.
Our system design interview guide and STAR method guide go deeper on both.
A three-week plan
| Week | Focus |
|---|---|
| 1 | Read the role's prep page and the Leadership Principles; draft eight STAR stories; two coding problems a day |
| 2 | Take the OA practice test if you have an OA; one design problem every other day; tighten stories with real metrics |
| 3 | Two full mock loops (four interviews each) with friends; fix the weakest story and the slowest coding area |
Final checklist
- Read the How We Hire page for your exact role.
- If you have an OA, follow the rules on resources, copy-paste and print screen.
- Prepare 8 or more distinct STAR stories with real numbers.
- Write real code, not pseudo code, and test edge cases aloud.
- Ask clarifying questions before designing.
- Request any accommodation early through the official route.