Amazon interview process and practice questions

Behavioral questions

1. Tell me about a time you went well beyond what a customer asked for.

   A good answer covers

   • Who the customer was and what they actually needed, not just what they asked
   • What you did beyond the request, and why it was worth the extra effort
   • A measurable result for the customer

2. Tell me about a time you had to make a decision quickly without all the data.

   A good answer covers

   • Why waiting would have cost more than deciding
   • The data you did have and the risk you accepted
   • How you checked the decision afterwards and what you'd change

3. Tell me about a time you disagreed with your manager. What happened?

   A good answer covers

   • The disagreement, stated fairly from both sides
   • How you made your case, with data, and to whom
   • What you did once the decision was made, even if it went against you

4. Describe a time you dug into the details to find the root cause of a problem.

   A good answer covers

   • The symptom everyone saw and why the obvious explanation was wrong
   • The data, logs or metrics you went through yourself
   • The root cause, the fix, and what stopped it happening again

5. Tell me about a commitment you failed to deliver. What did you learn?

   A good answer covers

   • A real miss, owned in the first person
   • When you saw it coming and who you told
   • What you changed in how you plan or commit since

6. Tell me about a time you made something simpler for your team or your users.

   A good answer covers

   • What was complicated and who it slowed down
   • The simpler approach and how you got others to adopt it
   • Time, errors or cost saved afterwards

7. Tell me about a time you refused to ship something because it wasn't good enough.

   A good answer covers

   • The standard it fell short of and how you knew
   • How you handled the pressure to ship anyway
   • What the extra work prevented, ideally with a number

Role and technical questions

1. Walk me through a system you built or designed. What would break first if its traffic grew ten times?

   A good answer covers

   • A short picture of the system: its main parts and how data flows
   • The bottleneck at ten times the load, with a rough estimate
   • What you'd change first and the trade-off it brings

2. How would you design a service that tells customers when an out-of-stock item is back?

   A good answer covers

   • Clarifying questions: scale, channels (email, app), how fast it must be
   • Storing subscriptions and reacting to stock changes without polling everything
   • Not notifying the same person twice, and what happens under a sudden spike

3. A feature you launched is getting worse reviews than expected. How would you find out why?

   A good answer covers

   • Reading the reviews and the metrics before guessing
   • Splitting the problem: who is unhappy, since when, on which platform
   • A quick fix for customers now, and the deeper fix after

4. Tell me about a time you learned a new technology or domain quickly to deliver something.

   A good answer covers

   • Why you needed it and how little time you had
   • How you learned it: what you read, built or asked
   • What you delivered with it

Why Amazon? Fit and HR questions

1. Why Amazon? Which Leadership Principle do you relate to most, and when have you lived it?

   A good answer covers

   • A reason tied to the team or product, not only the brand
   • One principle, named once, with a short example
   • Why that way of working suits you

2. Which Amazon product or service would you improve, and how would you know your change helped customers?

   A good answer covers

   • A specific product and a real customer problem with it
   • The change you'd make and what you'd leave out
   • The metric that would tell you it worked

Tips

• Prepare two stories per Leadership Principle; one story can't cover the whole loop.
• Expect several follow-ups on one story: your exact part, the data, what you'd do differently.
• Say "I", give numbers, and end each story on the result.
• Don't name the principle you think is being tested; let the story show it.