Amazon Phone Screen Interview: What You Have 45 Minutes to Prove
- The Amazon phone screen combines a LeetCode-medium coding problem (25-30 min) with 1-2 Leadership Principle behavioral questions (10-15 min) in a single 45-minute slot.
- Pattern recognition beats problem count: two pointers, sliding window, trees, hash maps, BFS/DFS, and linked lists cover most of what shows up.
- Testing is an explicit scoring dimension at Amazon — trace through an example and name an edge case before declaring done.
- LP answers live in the Action section of STAR (target 50% of your time there), not in Situation and Task setup.
- The hiring committee reads written feedback, not raw scores — every clarifying question you ask and every edge case you name becomes quote-able evidence.
- Silence is a red flag: the interviewer can only document what you say, so a correct silent solution leaves the behavioral section of the feedback doc empty.
- Prepare five versatile LP stories rather than 16 narrow ones — most stories support multiple principles.
You pass and you get an onsite. You fail and you wait six months, staring at the "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 entire time.
Knowing this going in changes how you prepare.
The Amazon Phone Screen Is Your First Real Filter
Amazon's full interview loop runs three stages:
- Recruiter screen (30 minutes, no code): your background, why Amazon, basic cultural fit
- Technical phone screen (45-60 minutes): coding plus behavioral, the topic of this guide
- Onsite loop (4-5 rounds): coding, system design, behavioral, Bar Raiser
The recruiter screen is basically a vibe check. It rarely cuts people. The phone screen is where candidates actually get eliminated, because it is run by an engineer, not HR. The feedback that engineer writes after the call determines whether the onsite team ever reads your resume.
That last part matters more than most candidates realize. 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:
| Segment | Time | What It Tests |
|---|---|---|
| Behavioral (1-2 LP questions) | 10-15 min | Leadership Principle alignment |
| Coding problem | 25-30 min | DSA, problem solving, narration |
| Wrap-up and your questions | 5 min | Optional signal |
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 code editor, or a screenshare with a plain text file. Some earlier assessments use HackerRank. Either way: you write code, they watch, and you talk while you write. No autocomplete. No running it to check. 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 that show up in candidate reports:
- Two pointers and sliding window: minimum window substring, longest substring without repeating characters, subarray sum equals k
- Trees: level-order traversal, lowest common ancestor, validate a BST
- Hash map plus array: two sum variants, group anagrams, top-k frequent elements
- Linked list: reverse nodes in k-group, merge two sorted lists, find the cycle start
- BFS and DFS: number of islands, word ladder, clone graph
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. You should reach O(n) or O(n log n) for most mediums. Explaining why O(n²) is acceptable in a specific case can also pass, as long as you actually know why.
- Testing. Amazon's rubric includes testing as an explicit scoring dimension. 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 within the first two minutes. Most phone screen rejections come from candidates who jump straight to implementation before articulating an approach. Walk through your thinking, name the data structure you plan to use, explain why it fits the problem. Then start writing.
The interviewer can only document what you say. Silent fast coding gives them nothing to put in the feedback doc. You can write a perfect solution and leave the interviewer staring at an empty page.
Leadership Principles Are Half Your Score
Every behavioral question in an Amazon interview maps to one or more of the 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
STAR format: 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.
Two things that kill LP answers, and they both kill a lot of candidates:
"We" without specifics. Interviewers will always follow up with "What did you specifically do?" If your answer cannot survive that question, rewrite it before the call. "Our team shipped it on time" tells them nothing about you. They are interviewing you, not your team.
The outcome was fine, but you owned nothing. Amazon scores for your individual decisions and actions. "I raised the concern in the design review and suggested the alternative approach" is strong. "Things worked out eventually" is not a story. That is a passive observer hoping a question goes away.
The Amazon Ownership Leadership Principle and Bias for Action Interview Question guides break down exactly what scores for each of those principles.
How Many LP Questions to Expect
One to two questions, each with follow-ups. The full block runs 10-15 minutes. 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.
How the Interviewer Actually Scores You
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 whether you earned a recommendation of Strong Hire, Hire, No Hire, or Strong No Hire.
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 edge case on strings with duplicate characters unprompted, and verified correctness by tracing through the example before submitting" is what gets you the call. The difference is entirely what you said out loud.
Second, correct code with no narration leaves the LP box empty. If you solved the problem silently and said nothing about your reasoning, the behavioral section of the feedback document is blank. And blank boxes read as a miss, because there is literally nothing to argue for you in the committee room.
For more on how the hiring committee reads these documents, see The Interviewers Liked You. Now the Hiring Committee Decides..
How to Prepare
Four Weeks Out
Focus on pattern recognition, not problem count. You want to identify the structure of a problem in the first two minutes, not after fifteen. Work through twenty medium problems across the core patterns. Time yourself. If you cannot identify an approach within five minutes, read the editorial, categorize the problem, and add it to your pattern log.
The Amazon Software Engineer Interview guide covers what happens after you pass the phone screen. Worth reading for context on how to frame your full prep arc.
One Week Out
Prepare your behavioral stories. Write them down, then say them out loud, timed, to a wall or a patient friend. 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 one: identify which LPs it supports, note the specific action you took, quantify the result where possible, and prepare for "what would you do differently?" as a follow-up. That last one comes up more than people expect and usually catches candidates who memorized an outcome but did not actually think about it.
Voice-based mock practice closes the gap between knowing an answer and being able to deliver it under pressure. SpaceComplexity runs realistic voice mock interviews with LP-aligned feedback, which is considerably closer to the actual phone screen than reading flashcards in your head.
Day Of
Warm up with one solved problem before the call. Something you have done before. You want pattern-matching active, not your brain doing cold-start calculations on a live call.
Log in five minutes early. Have the Chime link open. Connection issues happen, and spare time buys composure. Nothing like a three-minute "can you hear me now?" loop to drain whatever calm you had going in.
In the first two minutes of the coding segment: read the problem twice, ask one clarifying question, state your initial approach out loud. Then start typing.
What Trips Up Strong Engineers
Jumping to the optimal solution without narrating. Explaining a brute force, then optimizing aloud, generates more interviewer signal than silently writing a clean solution. The reasoning process is the evidence. Skipping it to look fast is a self-own.
Over-preparing for hard problems. The phone screen is almost always medium difficulty. Two weeks of hard problems before a phone screen is the wrong use of time. You are not being tested on your ability to crack a novel graph problem in 30 minutes. You are being tested on whether you can demonstrate 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. The difference is specificity. 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 simultaneously. See Technical Interview Communication for the habit that prevents this.