INTERVIEW GUIDE

Amazon Software Engineer Interview: Questions & Process

Amazon's software engineer interview is two things stacked together: medium-difficulty data-structures coding and a relentless focus on the 16 Leadership Principles. Almost every behavioral question maps to an LP, and a 'bar raiser' joins your loop to keep the bar high. Expect an online assessment, a phone screen, then a 4-5 round virtual loop.

The interview process

1. Online assessment (OA) — ~105 min, async

Tests: two coding problems (arrays, strings, hash maps), a work-styles survey mapped to Leadership Principles, and a code-debugging / work-simulation section

2. Technical phone screen — 45-60 min, live coding

Tests: one or two DS&A problems in a shared editor, plus a Leadership Principles behavioral question or two

3. Coding loop rounds — 2-3 rounds, 45-60 min each

Tests: medium problems — trees, graphs, heaps, BFS/DFS, two pointers — with you narrating tradeoffs and Big-O out loud

4. Behavioral (Leadership Principles) — woven through every round

Tests: STAR stories scored directly against LPs like Customer Obsession, Ownership, and Dive Deep

5. Bar raiser — 45-60 min

Tests: an objective interviewer from another team probing both your coding and your LP stories to protect Amazon's hiring bar

Questions you're likely to get

Technical

Given a 2D grid of '1's (land) and '0's (water), count the number of islands.
Return the k most frequent elements in an integer array.
Find the k closest points to the origin from a list of coordinates.
Merge a collection of overlapping intervals into the minimum set of intervals.
Given a grid of fresh and rotten oranges, return the minutes until no fresh orange remains.
Two Sum: return the indices of the two numbers in an array that add to a target.
What's the time and space complexity of your solution, and how would it hold up at Amazon scale?

Role-specific

How would you debug a service that's intermittently returning 500s in production?
Design a simple rate limiter for an internal API. What data structures would you reach for?

Behavioral

Tell me about a time you had to dig deep into data to find the root cause of a problem. (Dive Deep)
Describe a time you took ownership of something that wasn't strictly your job. (Ownership)
Tell me about a time you disagreed with a teammate or manager and how you handled it. (Have Backbone; Disagree and Commit)
Give an example of a time you put the customer first even when it was the harder path. (Customer Obsession)
Tell me about a time you failed or missed a deadline. What did you learn? (Earn Trust)
Describe a time you delivered results under a tight constraint with limited resources. (Deliver Results)

Practice these problems live

Relevant LeetCode problems for the Amazon Software Engineer loop. Start a live, AI-run coding interview on any of them — or open the problem on LeetCode.

▶ Number of Islands· Medium · LeetCode #200

Number of Islands — the canonical Amazon grid BFS/DFS question.

▶ Top K Frequent Elements· Medium · LeetCode #347

Top K Frequent Elements — heap + hash map, an Amazon staple.

▶ K Closest Points to Origin· Medium · LeetCode #973

K Closest Points to Origin — heap problem Amazon asks often.

▶ Merge Intervals· Medium · LeetCode #56

Merge Intervals — tests clean sorting and interval logic.

▶ Rotting Oranges· Medium · LeetCode #994

Rotting Oranges — multi-source BFS, a frequent Amazon loop problem.

▶ Two Sum· Easy · LeetCode #1

Two Sum — common warm-up; nail the hash-map optimum fast.

How to answer (worked examples)

Tell me about a time you had to dive deep into data to solve a problem.

Pick a story where the obvious answer was wrong and the data proved it. Situation: the symptom everyone assumed the cause of. Task: why you owned digging in. Action: the specific metrics, logs, or queries you pulled and the dead ends you ruled out. Result: the real root cause plus a number (latency dropped X%, errors fell to near zero). Amazon's Dive Deep LP rewards the candidate who audits the details instead of trusting a summary.

Return the k most frequent elements in an array.

State the brute force first (count, sort by frequency — O(n log n)), then improve. Use a hash map for counts, then a min-heap of size k for O(n log k), or bucket sort for O(n). Say the complexity out loud before you code, handle ties and the k = array-length edge case, then walk a small example. Amazon scores how clearly you reason about tradeoffs as much as whether you reach optimal.

Tell me about a time you disagreed with a teammate or manager.

STAR, and explicitly name both LPs at play: Have Backbone (you respectfully pushed with data) and Disagree and Commit (once the call was made, you backed it fully). End with the outcome and what trust you built. Avoid stories where you were simply proven right and gloated — Amazon wants principled disagreement, not stubbornness.

What Amazon looks for

Coding that's correct AND narrated — you state complexity and tradeoffs before and while you code
STAR stories that map cleanly to specific Leadership Principles, with real metrics in the Result
Customer Obsession: you reason backwards from the customer, not just the ticket
Ownership and bias for action: you drive ambiguity to a decision instead of waiting
Self-awareness: you can tell a genuine failure story and what you changed
Red flag: vague 'we' stories with no measurable result, or hand-waving past edge cases and Big-O

FAQ

How important are the Leadership Principles, really?

Central. Amazon interviewers are explicitly assigned LPs to probe, and your behavioral answers are graded against them. Prepare 6-8 STAR stories ahead of time and tag each to 2-3 principles so you can redeploy them quickly.

How hard is the coding?

Mostly medium LeetCode-style: arrays, strings, hash maps, trees, graphs (BFS/DFS), and heaps. Amazon rarely goes deep into hard dynamic programming. Optimal-then-clean matters more than exotic tricks.

What is the bar raiser?

A trained interviewer from outside the hiring team whose job is to keep standards consistent and veto bar-lowering hires. They probe both coding and LPs and carry real weight in the debrief — treat that round as seriously as any other.

How long does the process take?

Often 3-6 weeks from OA to offer for new grads, though university timelines and team availability can stretch it. The debrief and decision usually happen within a few days of the loop.

Do I need to finish every coding problem perfectly?

No. Working code with clear communication, correct complexity analysis, and handled edge cases can pass even if you don't reach the absolute optimal. Silence and untested code hurt more than a slightly slower solution.

Practice the Amazon loop before you live it

The hardest part of Amazon isn't the code — it's delivering crisp Leadership Principles stories on demand while you also reason through a graph problem. Rehearse both out loud with OfferLoop's realtime voice coach so the LPs feel automatic when the bar raiser walks in.

Practice this interview out loud →

All Amazon interviews →Amazon Data Analyst interview →Amazon Data Scientist interview →Amazon Data Engineer interview →Amazon Machine Learning Engineer interview →

OfferLoop is an independent interview-practice tool and is not affiliated with, endorsed by, or sponsored by Amazon. All company names and trademarks are the property of their respective owners.

Interview formats vary by team, level and year, and this guide is compiled from general knowledge of publicly discussed hiring processes — treat it as preparation material, not an official description of Amazon's current process.