Amazon Coding Interview Questions (2026): Patterns, Problems & Prep

Amazon Coding Interview Questions: what the 2026 loop really tests

Searching for Amazon coding interview questions usually turns up the same thing: a wall of tagged LeetCode links and no sense of what the room is actually like. That is the opposite of how the loop runs. An Amazon coding round is a timed working session — two problems, a shared editor, and an interviewer who waits for your solution to run and then starts pushing: on the complexity, on the edge cases, and on what happens when the input gets ten thousand times bigger.

This is a map of that loop for 2026 — the stages from the amazon online assessment through the onsite, the handful of coding interview patterns that account for most of the questions, and the follow-ups that decide whether a working answer becomes an offer. It is framed the way the screen is framed: not "here are the exact questions" but "here is the pattern, here is the kind of problem it shows up in, and here is the probe that separates a passing answer from a memorised one." Read it as a prep plan, because the code is table stakes — the round is won on what you say when someone asks "why that, and not the other thing?"

How the Amazon coding loop runs (2026)

Amazon's process is not one interview; it is a loop of four to six, and coding shows up in more than one of them. A typical path for a software engineer is an online assessment first, then a phone screen, then an onsite of several back-to-back rounds — a mix of coding, system design, and Leadership Principles — with one specially-trained interviewer, the bar raiser, sitting in as an independent evaluator. The coding questions lean medium difficulty, occasionally hard, and the quiet signal the interviewer is reading is how quickly and cleanly you get to the optimal answer.

The rounds below are modelled on how the Amazon loop runs, not scraped from any candidate's recall. What matters for prep is the shape: two problems per round, a clock, real code that compiles and runs, and a follow-up after every submission.

Inside the Online Assessment (90 minutes)

The amazon oa questions are the gate most candidates hit first. In the modelled version of this round you get 90 minutes and two problems, auto-graded against visible and hidden test cases, so correctness is checked the same way the real assessment checks it — your code has to actually pass, not just look right. The two problems usually sit in the medium band: a graph traversal, a dynamic-programming count, a matrix problem. Pacing is the hidden skill — a single problem you cannot finish is worse than two you solve at eighty percent, so budget the clock and get something running early.

The onsite coding rounds (60 minutes each)

The onsite coding rounds run 60 minutes apiece, two of them, and they climb in difficulty — the second is where the hard problems live. Here the interviewer is in the room (by voice), so the performance is half the grade: you narrate the plan before you type, you handle the edge cases out loud, and you answer the follow-ups one at a time. The same problem that is a clean pass in silence can fail here if you cannot explain why your approach is correct and what it costs.

The coding patterns Amazon tests

You do not need five hundred problems; you need the dozen coding interview patterns that account for most of them, and the judgment to recognise which one a new prompt is wearing. These are the same leetcode patterns every FAANG screen reuses, but Amazon leans hard on graphs, trees, and dynamic programming, and it always circles back to complexity. The table is the shortlist: the pattern, the kind of problem it shows up in, and the follow-up that decides the round.

Two pointers, sliding window and hashing (the warm-ups)

These open many screens because they are fast to pose and reveal a lot. The two pointer technique turns an O(n²) scan of a sorted array into one linear pass; the sliding window technique does the same for "longest / shortest / count of" substring and subarray questions. The trap is never the syntax — it is proving the window is correct: say out loud when it grows, when it shrinks, and why the best answer is always inside it.

# Sliding window skeleton: grow on the right, shrink on the left when invalid
left = 0
for right in range(len(s)):
    add(s[right])
    while invalid():          # a rule broke — pull the left edge in
        remove(s[left]); left += 1
    best = max(best, right - left + 1)

Hashing is the other warm-up: a dictionary turns a repeated lookup into O(1), which is why two-sum and group-anagrams are openers. The follow-up is always the hidden cost — "what is your key, and what is the memory at a billion rows?" — so name the space tradeoff before you are asked.

Trees, graphs and BFS/DFS (the core)

If one family decides an Amazon onsite, it is this one. Breadth-first search for level-order and shortest-path-in-an-unweighted-graph; depth-first search for path sums, island counting, and connectivity. Have the breadth-first template automatic, because half the tree and grid questions are a variation on it.

from collections import deque

def level_order(root):
    if not root:
        return []
    q, out = deque([root]), []
    while q:
        level = []
        for _ in range(len(q)):          # one full level at a time
            node = q.popleft()
            level.append(node.val)
            if node.left:  q.append(node.left)
            if node.right: q.append(node.right)
        out.append(level)
    return out

Graphs add one more move: topological sort for ordering problems like course schedule, where the real question hiding inside is "is there a cycle?" Narrate the cycle check — a node left with non-zero in-degree, or a grey node seen twice in a DFS — and you have answered the follow-up before it lands.

Heaps, backtracking and dynamic programming (the senior signal)

These are where a mid-to-senior loop is won. A heap keeps the top-K without sorting everything — O(n log k) instead of O(n log n) — which is the entire point of k-closest-points and merge-k-lists.

import heapq
# Top-K: keep a heap of size k, evict the smallest — O(n log k), not O(n log n)
heap = []
for x in items:
    heapq.heappush(heap, (score(x), x))
    if len(heap) > k:
        heapq.heappop(heap)

Backtracking (word search, combination sum) is judged on where you prune — an interviewer wants to hear the condition that stops a dead branch early. And dynamic programming interview questions — unique paths, word break, edit distance, house robber — are judged on two sentences: what is the state, and what is the transition. Say those cleanly and the code writes itself; fumble them and no amount of code recovers it. The last probe is almost always memory: "can you drop the 2-D table to a single row?"

What the bar raiser probes

Every Amazon onsite includes a bar raiser — a senior interviewer, deliberately from outside the hiring team, trained to hold a consistent bar and act as an independent check on the decision. In a coding round they are the source of the hardest follow-ups: not "does it run?" but "prove the complexity," "what breaks at scale," "what is the edge case you did not handle." Their job is to find the gap between a solution that works on the sample and an engineer who understands it.

Treat scale as a reflex, not a surprise. When a solution works, say the complexity unprompted, name the one input that would break it, and offer the fix — a streaming pass, a better data structure, a precomputed index. That is the move that reads as senior.

Leadership Principles inside a coding round

This is the part candidates miss: at Amazon the amazon leadership principles are not quarantined in one behavioral slot. An interviewer can lean on them anywhere, and in the onsite coding rounds they often will — a quick "tell me about a time you had to simplify a design under a deadline" can arrive between problems. Dive Deep, Bias for Action, and Deliver Results map almost directly onto how you work a problem: do you actually understand the mechanism, do you get something running instead of stalling, do you finish on the clock?

If the behavioral push is what unnerves you, drill it the way you drill code — out loud, against follow-ups. Zynter has a dedicated Amazon Leadership Principles deep dive round for exactly that.

How to prepare: a two-week plan

You do not need a hundred new problems in the last fortnight. You need the patterns automatic, the complexity reflexive, and a few answers you can defend while someone interrupts. Here is a realistic two-week pass for coding interview prep.

• Days 1–3: Drill the warm-ups — two pointers, sliding window, hashing — until you recognise them on sight. Write each solution, then say its time and space cost in one sentence.
• Days 4–8: Live in trees and graphs. BFS and DFS templates, topological sort, island counting, path sums. These are the highest-leverage days for an Amazon loop.
• Days 9–11: Heaps, backtracking, and dynamic programming. For each DP problem, say the state and the transition out loud before you code; practise dropping a dimension for memory.
• Days 12–14: Full timed rounds — two problems, clock running, narrating the plan and the complexity, with a Leadership Principles answer between them. The goal is to finish on pace while defending every choice.

The most common mistake in the last week is grinding more problems in silence. By day 12, reading another solution is not the bottleneck — speaking is. If you still want raw volume to drill the problems themselves, PipeCode is a sister platform built for exactly that; use it for reps, then come back here to rehearse defending them out loud.

The follow-ups that decide an Amazon coding round

Scan the right-hand column of the pattern table and the questions rhyme. Master these five cross-cutting follow-ups and you are ready for prompts that are not even on the list.

• "What's the time and space complexity?" → Say it unprompted, the moment your solution runs. Not knowing it is the fastest way to lose a round you technically solved.
• "Now it's a hundred million elements — what breaks first?" → Name the cost (memory, a full sort, a quadratic scan) then the fix (a heap, a stream, an index).
• "Why that data structure?" → Tie it to the access pattern: a hash for O(1) lookup, a heap for top-K, a deque for BFS. The structure is the answer; justify it.
• "What's the edge case you didn't handle?" → Empty input, one element, duplicates, a cycle, integer overflow. Volunteer one before you are asked.
• "Can you prove it's correct?" → Trace two rows by hand, or state the invariant your loop maintains. "Works on the sample" is not a proof.

Each of these maps straight to the four-dimension debrief Amazon's grading mirrors: do you reach the optimal solution (problem solving), narrate it clearly (communication), write code that runs (technical execution), and finish on the clock (time management)? Reading this list teaches you the answers. It does not teach you to deliver them while someone pushes back — that only comes from saying them out loud.

Frequently asked questions

Practise it on Zynter