Amazon backend interview questions and process

He solved it in eighteen minutes. Clean, optimal, well tested. Then the interviewer said, "Nice. Now tell me about a time you had to deliver something with incomplete information," and he blinked, because this was the coding round, and the coding round is for coding. He gave four minutes of vague, tenseless narration about "the team" doing "some refactoring." The code was perfect. The round was not.

That is the thing everyone learns too late about Amazon backend interview questions: there is no purely technical round. Every interviewer is assigned two or three leadership principles to probe, and they will spend a third of your coding hour on them. Add a bar raiser from outside the hiring team who can veto, and you get a loop where technical strength alone does not clear the bar. I built Greenroom after freezing in an interview I had prepared hard for, so this guide covers what Amazon asks and how to answer both halves out loud.

The Amazon backend engineer interview process in 2026

• Online assessment — for many roles, especially in India: two timed coding problems plus a work-style survey and sometimes a work-simulation exercise.
• Technical phone screen — around an hour: coding, plus at least two leadership principle questions in the same session.
• Onsite loop (virtual) — typically four to five rounds: two or three coding, one system design, and one bar raiser, with behavioral questions in every one.
• Bar raiser — an experienced interviewer from outside the hiring team whose job is protecting the company-wide bar. They can veto.
• Debrief — interviewers align on leadership principle evidence, not just "did they solve it." Written notes decide the outcome.

Our Amazon leadership principles guide covers the behavioral half in depth, and the Amazon data engineer guide covers the data-platform variant of the same loop.

The coding rounds: medium problems, split attention

Amazon's coding problems sit mostly at LeetCode medium: graphs and BFS/DFS, trees, heaps and top-K, intervals, hash-map counting, sliding window, and occasional dynamic programming. Nothing exotic.

The difficulty is the split hour. You get roughly 35 minutes of coding and 20 of behavioral, so a problem you would comfortably finish in 40 minutes becomes a problem you must finish in 30. Practise under that clock, not a generous one.

Two Amazon-specific habits. First, they like production-shaped follow-ups: what if the input arrives as a stream, what if this runs on ten thousand machines, what does it cost. Second, they genuinely value working code over elegant code — get something correct running, then improve it aloud.

# top-K by frequency: an Amazon staple, and the follow-up is always "now stream it"
import heapq
from collections import Counter

def top_k(nums, k):
    counts = Counter(nums)                     # O(n) pass to build frequencies
    return heapq.nlargest(k, counts, key=counts.get)   # O(n log k), not O(n log n)

# streaming variant: keep a heap of size k, never materialise the full sort
def top_k_stream(stream, k):
    counts = Counter()
    for item in stream:
        counts[item] += 1                      # bounded memory only if the key space is bounded
    return heapq.nlargest(k, counts, key=counts.get)

Say the honest limitation out loud: "this is bounded by the number of distinct keys, not by k — if the key space is unbounded I would need count-min sketch and accept approximate counts." Volunteering that tradeoff is a direct hit on Dive Deep. Our DSA coding interview preparation guide covers the problem list.

System design at Amazon

Design prompts are service-shaped and ownership-flavoured: design an order service, a notification system, an inventory tracker, a rate limiter, a URL shortener, or the backend for a delivery-tracking feature.

• Requirements and numbers first. Orders per second, peak-to-average ratio (say "Diwali" or "Prime Day" and mean it), payload size, retention.
• Service boundaries and ownership. Amazon is built from small services owned end to end by small teams. Draw the boundary and say who is on call for it.
• Failure isolation. What happens when a downstream dependency is slow rather than down — timeouts, circuit breakers, bulkheads, and a degraded experience rather than a cascade. This is the single most Amazon-shaped question in design.
• Idempotency. Every retry must be safe. Order placement is the canonical example; describe the idempotency key and where it is stored.
• Consistency per feature. Inventory decrement needs strong guarantees; a recommendation carousel does not. Say which and why.
• Queues and back-pressure. What happens when the consumer falls behind — buffer, shed, or degrade. See our Kafka interview questions guide.
• Cost. Amazon is one of the few places where "and this is roughly what it costs to run" earns real credit under Frugality.
• Operations. Metrics, alarms, a rollback plan, and what the on-call sees.

Our distributed systems interview questions and caching strategies guides cover the vocabulary, and the Amazon backend engineer prep page has a round-by-round checklist.

Leadership principles inside technical rounds

This is what people under-prepare. In a coding round, the behavioral questions map to specific principles: Deliver Results, Dive Deep, Ownership, Earn Trust, Bias for Action, Are Right A Lot, and Invent and Simplify.

Answer in STAR format, in first person singular, with a number. "We improved latency" scores nothing; "I found the N+1 query in the checkout path and cut p99 from 1.4 seconds to 380 milliseconds" scores. Prepare eight to ten stories and map each to two or three principles so you are never stuck without material.

Expect follow-ups: what was the data, what did you do when it did not work, what would you do differently, who disagreed. Memorised stories collapse at follow-up two; lived ones do not.

The bar raiser round

The bar raiser is an experienced interviewer from outside the hiring team, trained to protect the company-wide bar rather than fill the role, and they can veto an otherwise clean loop. The round is mostly behavioral with unusually persistent probing, and often one broad technical question to check depth.

What works: five or six lived stories with numbers, rehearsed out loud to three follow-ups deep, plus a genuine failure story you can discuss without defensiveness. What fails: a polished story that thins out the moment someone asks what the data actually said. Our tell me about a time you failed guide covers that specific shape.

LeetCode, Grokking, ChatGPT — where each fits

• LeetCode — Amazon-tagged mediums, practised under a 30-minute clock to simulate the split hour.
• Grokking / Designing Data-Intensive Applications — the second is the better investment for the failure-isolation and consistency vocabulary the design round rewards.
• The AWS Architecture Center and the Amazon Builders' Library — Amazon's own published writing on timeouts, retries with jitter and circuit breakers is essentially the answer key for the design round.
• A written STAR bank — eight to ten stories, each mapped to principles and each containing a number. Write them once, then never read them again; speak them.
• ChatGPT — good for generating principle-mapped questions from your resume. It will not notice that your story used "we" eleven times, which is the exact thing that sinks these rounds.
• Greenroom — the spoken layer. Ari, the AI interviewer runs bar-raiser-style follow-ups out loud and scores structure, specificity and whether you owned the work. Honest tradeoff: Ari will not verify your algorithm's correctness, so pair it with LeetCode.

How to prepare for the Amazon backend interview

• Week 1 — Amazon-tagged LeetCode mediums under a 30-minute clock, always finishing with a production follow-up: stream it, scale it, price it.
• Week 2 — write eight to ten STAR stories, each with a number, each mapped to two or three leadership principles. First person singular, always.
• Week 3 — design an order service, a notification system and a rate limiter out loud, with timeouts, circuit breakers, idempotency and cost in each.
• Final week — rehearse every story to three follow-ups deep out loud, run two full spoken mocks in the split format, and read the role-specific prep page the night before. Nothing new in the last 48 hours.

Interviewing across comparable loops? The Meta backend engineer guide covers scale-first design, the Google backend engineer guide covers a harder algorithm bar, and the Uber backend engineer guide covers a very similar bar raiser round.

Frequently asked questions

What is the Amazon backend engineer interview process?

For many roles it starts with an online assessment of two timed coding problems plus a work-style survey, followed by a technical phone screen of about an hour that mixes coding with leadership principle questions. The onsite loop is typically four to five rounds — two or three coding, one system design and a bar raiser — with behavioral questions in every round, and the debrief aligns on leadership principle evidence rather than only on whether you solved the problem.

Does Amazon ask behavioral questions in the coding round?

Yes, and this is the most common surprise. Every interviewer is assigned two or three leadership principles to probe, so a one-hour coding round is usually about 35 minutes of coding and 20 minutes of behavioral questions. Practise your coding under a 30-minute clock rather than a generous one, and have leadership principle stories ready to deliver inside a technical session.

What is the bar raiser round at Amazon?

It is a round run by an experienced interviewer from outside the hiring team whose job is protecting the company-wide hiring bar rather than filling the role, and they have veto power over an otherwise clean loop. It is mostly behavioral with unusually persistent follow-ups, often with one broad technical question to check depth, so prepare five or six lived stories with numbers rehearsed out loud to three follow-ups deep.

What system design questions does Amazon ask backend engineers?

Prompts are service-shaped: an order service, a notification system, an inventory tracker, a rate limiter, or a delivery-tracking backend. Strong answers begin with numbers including the peak-to-average ratio, then define service boundaries and who owns them, then failure isolation with timeouts, circuit breakers and bulkheads, idempotent retries, per-feature consistency, back-pressure when consumers fall behind, an honest cost estimate, and what the on-call engineer sees.

How should you answer leadership principle questions as a backend engineer?

Use STAR in first person singular with a real number in the result. Saying we improved latency scores nothing, while saying you found the N plus one query in the checkout path and cut p99 from 1.4 seconds to 380 milliseconds scores directly against Dive Deep and Deliver Results. Prepare eight to ten stories, map each to two or three principles, and rehearse them out loud because memorised stories collapse at the second follow-up.

How hard is the Amazon backend interview?

The algorithm bar is moderate — mostly LeetCode medium — so raw problem difficulty is rarely what ends a loop. What ends loops is the split hour, where candidates lose a third of every round to behavioral questions they have never spoken aloud, and the bar raiser, who probes stories to a depth that exposes anything rehearsed but not lived.