Amazon Phone Screen Interview: What You Have 45 Minutes to Prove

You pass and you get an onsite. You fail and you wait six months, staring at a "Thank you for your interest" email. The Amazon phone screen is not a conversation. It is a binary filter run by an engineer who has already interviewed five people this week and has a Slack message blinking at them the whole time.

Knowing this changes how you prepare.

The Amazon Phone Screen Is Your First Real Filter

Amazon's loop runs three stages:

Recruiter screen (30 min, no code): background, why Amazon, basic cultural fit.
Technical phone screen (45-60 min): coding plus behavioral. The topic of this guide.
Onsite loop (4-5 rounds): coding, system design, behavioral, Bar Raiser.

The recruiter screen rarely cuts people. The phone screen is where candidates get eliminated, because it is run by an engineer, not HR. The feedback that engineer writes determines whether the onsite team ever reads your resume.

You are not just performing for your interviewer. You are generating their raw material.

What the 45 Minutes Actually Look Like

The phone screen packs two completely different tests into a single timeslot. Here is the budget:

0 ────── 10 ────── 25 ────── 40 ── 45
│ Intro │   Behavioral    │   Coding (25-30 min)        │ Q&A │
│ 2 min │    (LP block)   │  problem statement → code   │     │
└───────┴─────────────────┴─────────────────────────────┴─────┘

The order is not fixed. Some interviewers open with behavioral, some close with it. Assume either order, so you are not caught off guard when the first question out of their mouth is "Tell me about a time you disagreed with a technical decision" and your brain is still booting up for arrays.

The platform is usually Amazon Chime with a shared editor, sometimes HackerRank earlier in the funnel. Either way: you write, they watch, and you talk while you write. No autocomplete. No run button. Just you, a blinking cursor, and the sound of your own typing.

What the Coding Half Actually Tests

Expect One Medium. That Is the Standard.

One problem, medium difficulty. LeetCode medium is the target zone, which means a brute-force solution usually exists and the interview tests whether you can climb from that to something reasonable.

Common patterns from candidate reports, in rough order of frequency:

Hash map plus array (two sum variants, group anagrams, top-k frequent): the most common phone-screen bucket, because the brute force and the O(n) optimization both fit in 25 minutes.
Two pointers and sliding window (minimum window substring, longest substring without repeating chars, subarray sum equals k): the O(n²) → O(n) jump is the signal.
Trees (level-order, LCA, validate a BST): recursion plus one invariant. Easy to score, hard to fake.
BFS and DFS (number of islands, word ladder, clone graph): rarer at phone screen than at onsite. Boilerplate eats time.
Linked list (reverse k-group, merge two sorted, cycle start): common at onsite, rarer here.

Amazon rarely invents novel problems at the phone screen. The question will look like something you have seen before with one constraint changed. Recognition gets you to the board. Adapting to the twist is what gets you through.

Four Things That Get You Through

Correctness. A brute force that runs beats an elegant solution that crashes on edge cases. Every time.
Complexity. Reach O(n) or O(n log n) for most mediums. Amazon's SDE prep tells candidates to "consider the runtime complexity" and keep improving it. O(n²) can still pass when n is tightly bounded (n ≤ 1000), as long as you say so out loud: "Given n ≤ 1000, O(n²) is 10⁶ ops. I would rather lock in correctness here." Silently writing O(n²) without naming the tradeoff is the dead version of the same call.
Testing. Amazon's SDE prep page is explicit: candidates should write "scalable, robust, and well-tested code" and "check for edge cases and validate that no bad input can slip through". Trace through the example, check an edge case, and say "I would also test the empty array case" before you declare done.
Communication. The interviewer is writing a detailed feedback document after the call. They need your reasoning in words, not just code.

Before touching the keyboard, ask one clarifying question. "What should I return if the array is empty?" takes ten seconds and signals exactly the right instincts. See Ask These Clarifying Questions First for the short list worth having ready on every problem.

The Mistake That Kills Most Candidates

Starting to code in the first two minutes. The counterintuitive bit: interviewing.io's 100K-interview study found that 4-4-2 candidates (strong code/solve, weak comms) advanced 96% of the time, and 3-3-4 candidates were 3x more likely to be rejected. So why narrate? Because the floor drops out when comms hits 1. Silent fast coding is how a 2 becomes a 1. Walk through your thinking, name the data structure, explain why it fits. Then write.

The interviewer can only document what you say. A perfect silent solution leaves them staring at a blank page.

Leadership Principles Are Half Your Score

Every behavioral question in an Amazon interview maps to one or more of Amazon's 16 Leadership Principles. Before your call, the interviewer was assigned two or three specific LPs to probe. Every follow-up question they ask is trying to extract signal for those assigned principles.

Think of it as 16 buckets, and your job is to fill two or three of them in 10-15 minutes. You do not know which buckets they got assigned. So you prepare stories that are versatile enough to land in multiple.

LP questions that show up frequently at the phone screen:

Customer Obsession: Tell me about a time you prioritized the customer over a technical preference.
Ownership: Tell me about a time you took responsibility for something outside your formal scope.
Bias for Action: Tell me about a time you made a decision without all the information you wanted.
Earn Trust: Tell me about a time you disagreed with a teammate and how you resolved it.
Dive Deep: Tell me about a time you discovered a problem that others had missed.

How to Answer

Amazon's own SDE prep tells candidates to "use the STAR method": Situation, Task, Action, Result. The trap everyone falls into is burning time on S and T. The Action section is where the LP evidence lives. Keep Situation plus Task to 20% of your answer. Spend roughly 50% on Action, 30% on Result.

Generic vs. scoring Ownership answer:

Generic:
"We had a bug causing dropped checkout sessions. The team
investigated and shipped a fix. We learned a lot about debugging
in production."

Scoring:
"3% checkout drop after a Friday deploy. No one owned it. I
claimed it, built a session replay query that isolated the bug
to iOS 17 + Safari, shipped the patch Sunday, and wrote a runbook
so the next on-call could catch it in under 20 minutes."

The second one fills the bucket: action, data, artifact, durable change. The first names nothing.

Two things kill LP answers. "We" without specifics: interviewers will follow up with "What did you specifically do?" and "our team shipped it on time" survives nothing. And the outcome-was-fine non-story: Amazon scores your decisions, not your team's luck.

The Amazon Ownership Leadership Principle and Bias for Action Interview Question guides break down what scores for each.

You Will Get One or Two LP Questions, Each With Follow-Ups

Each runs 5-7 minutes with follow-ups. Prepare four or five distinct stories that each support multiple LPs. The same story can work for both Ownership and Bias for Action. Do not prepare 16 stories. Prepare five versatile ones, and know each one well enough to pivot mid-answer when the follow-up changes direction.

You Are Writing Your Own Feedback Doc

Amazon's feedback system is written, not numeric. After the call, the interviewer writes a document describing what you said, how you approached the problem, which LP behaviors you demonstrated, and the recommendation: Strong Hire, Hire, No Hire, Strong No Hire.

Think of the interviewer as a court stenographer on a deadline. They are typing what you say. Anything you do not say out loud does not exist in the document. Anything in the document is what the hiring committee debates.

The hiring committee reads the written feedback, not just the recommendation. This has two real consequences.

First, vague answers are invisible. "The candidate performed adequately" does not get you an onsite slot. "The candidate identified the two-pointer approach within three minutes, named the duplicate-character edge case unprompted, and traced the example before submitting" does. The difference is entirely what you said out loud.

Second, correct code with no narration leaves the LP box empty. Blank boxes read as a miss, because there is nothing to argue for you in the committee room.

For more on how the committee reads these documents, see The Interviewers Liked You. Now the Hiring Committee Decides..

Prepare in Layers, Not in a Sprint

Four Weeks Out

Focus on pattern recognition, not problem count. Identify a problem's structure in the first two minutes, not after fifteen. Work through twenty mediums across the core patterns. Time yourself. If you cannot name an approach within five minutes, read the editorial, categorize it, and add it to your pattern log.

The Amazon Software Engineer Interview guide covers what happens after you pass.

One Week Out

Prepare your behavioral stories. Write them down, then say them out loud, timed. Most candidates who prepare LP answers have a written version they have never spoken. The phone screen is spoken. The written draft is scaffolding, not the product.

Build five stories. For each: which LPs does it support, what specific action did you take, what result can you quantify, and what would you do differently? That last follow-up catches candidates who memorized the outcome but never thought about it.

Voice-based mock practice closes the gap between knowing an answer and delivering it under pressure. SpaceComplexity runs realistic voice mock interviews with LP-aligned feedback, closer to the actual phone screen than reading flashcards in your head.

Day Of

Warm up with one solved problem before the call. Pattern-matching active, not cold-start.

Log in five minutes early. Connection issues happen, and spare time buys composure. Nothing drains your calm like a three-minute "can you hear me now?" loop.

In the first two minutes of the coding segment: read the problem twice, ask one clarifying question, state your initial approach out loud. Then type.

What Trips Up Strong Engineers

Over-preparing for hard problems. The phone screen is almost always medium. Two weeks of hards before a phone screen is the wrong use of time. You are not being tested on cracking a novel graph problem in 30 minutes. You are being tested on whether you can run a working process on a recognizable pattern.

Generic LP stories. "I always put the customer first" is not a story. "I pushed back on a feature that reduced support ticket volume but confused new users, and made the case with a two-week retention comparison from a cohort analysis" is a story. Specificity is what fills the LP buckets.

Going silent when stuck. If you are blocked, name the block. "I am trying to figure out whether I need this partition to be stable" is signal the interviewer can document. Silence for 45 seconds is a red flag on both the technical and communication dimensions at once. See Technical Interview Communication for the habit that prevents this.