Amazon Interview Questions

Amazon states the process typically runs three to six weeks end to end, though it can stretch longer for senior or specialized roles, or when scheduling across multiple interviewers takes time. Entry-level candidates should expect at least two to three weeks between the first screen and a final decision.

The OA is a timed test most common for SDE, data, and some operations roles, usually combining coding or aptitude problems with a work style survey. It screens candidates before a human phone screen, so treat it as a real gate rather than a formality.

A recruiter phone screen is a 20 to 30 minute conversation about your background, motivation for Amazon, and basic fit for the role, not a deep technical test. Recruiters are also checking whether your expectations on level, location, and compensation line up with the role before investing further interviewer time.

Expect foundational questions about your resume, why Amazon, and one or two Leadership Principle behavioral stories, alongside role-appropriate technical basics for technical roles. The bar is on clear communication and genuine examples rather than polished frameworks.

No, the core shape (screen, then loop, then bar raiser) stays consistent, but the content differs a lot. An SDE loop leans on coding and system design, a PM loop leans on product sense and metrics, and operations or business roles lean on process and Leadership Principle stories.

The loop is a set of back-to-back interviews, historically in person and now often virtual, where each interviewer covers different competencies and Leadership Principles. Amazon deliberately assigns overlapping but distinct focus areas so the full loop covers the role's core requirements without redundant coverage.

A bar raiser is a specially trained interviewer, usually from a different team than the one hiring, whose job is to protect hiring quality across the company rather than fill one specific opening. They sit in on the loop, ask their own questions, and have real influence in the hiring decision even though they are not the hiring manager.

Start by picking six to eight concrete work or project stories that show initiative, a mistake you owned, and a customer or user impact, then map each one to a couple of Leadership Principles. Pair that with practicing the technical basics expected for your specific role, since entry-level loops still test fundamentals seriously.

It means every new hire should make the team stronger than it was before, beyond simply filling a headcount. That is the entire reason the bar raiser role exists, and it is also why interviewers are trained to push back on borderline candidates rather than default to a yes.

No, coding assessments apply to software, data, and some technical operations roles. Non-technical roles like HR, marketing, or many business roles skip coding entirely and focus on case-style, behavioral, and role-specific competency questions instead.

It is a personality-style questionnaire that asks how you'd behave in workplace scenarios, designed to gauge alignment with the Leadership Principles before a human ever reviews your answers. There are no objectively right or wrong answers, but consistency across similar questions matters more than trying to guess a desired profile.

Most entry-level candidates go through one or two screening conversations followed by a loop of three to five interviews, sometimes fewer for internship or new-grad-specific pipelines. The exact count depends on role and team, so always confirm with your recruiter.

Early rounds tend to ask about a time you disagreed with a teammate, a time you made a mistake, or a time you went beyond your role to help a customer. These map cleanly to principles like Have Backbone, Ownership, and Customer Obsession.

Recruiters sometimes share which principles an interview will cover if you ask directly, since Amazon wants candidates to prepare well rather than guess blindly. It is a reasonable, common question to raise during your recruiter screen.

Giving vague, team-focused answers ('we did this') instead of specific, first-person accounts of what you personally did, decided, and learned. Amazon interviewers are trained to probe for your individual contribution, so vagueness reads as a weak signal even if the outcome was genuinely good.

Amazon generally does not share detailed interviewer feedback due to legal and process reasons, though your recruiter may offer a brief, high-level reason. Candidates who are rejected can typically reapply after a waiting period, often around six months to a year depending on the role.

It usually runs one to three weeks, mostly driven by scheduling availability across multiple interviewers and the recruiter coordinating calendars. Candidates should stay proactive and follow up with their recruiter if more than two weeks pass with no update.

Since the shift during the pandemic, most Amazon interview loops, including onsite-equivalent rounds, run virtually over video call, though some roles and locations still bring finalists onsite. Confirm the format with your recruiter so you can prepare your setup accordingly.

Amazon's culture leans casual, so business casual is generally more than sufficient and overdressing is not expected or required. What matters far more is a quiet, well-lit space and a stable connection for virtual rounds.

Amazon avoids the vague concept of general culture fit and instead evaluates specific Leadership Principle alignment through your behavioral stories. That structured approach is meant to reduce bias compared to a gut-feel culture read.

A recruiter phone screen is conversational and non-technical, while a technical phone interview, often with an engineer or hiring manager, includes live coding or role-specific technical questions in addition to a couple of behavioral ones. Both may happen before you reach the full loop.

It comes up in nearly every screen and matters more than candidates often expect, since Amazon wants people who genuinely want to work there rather than treat it as one offer among many. A specific, researched answer tied to the team or mission beats a generic one about scale or growth.

Every loop interview also maps to one or more Leadership Principles, so even a coding round typically ends with a couple of behavioral questions. Amazon deliberately blends technical and behavioral assessment rather than separating them into fully distinct rounds.

State clearly that you're not certain, then reason through what you do know out loud rather than guessing silently or freezing. Amazon interviewers weigh problem-solving process heavily, and Are Right, A Lot rewards good judgment under uncertainty, not perfect recall.

The hiring manager usually runs one of the loop interviews, often focused on role fit and ownership-style questions, and typically has the strongest say alongside the bar raiser in the final decision. They are also generally the person who communicates a verbal offer if you're selected.

Yes, interviewers write detailed notes and submit written feedback shortly after each session, which then feeds into a debrief meeting. This documentation-heavy approach is part of why Amazon interviews can feel more formal than other tech companies.

All interviewers, including the bar raiser, meet to discuss their independent written feedback and reach a hiring decision together, rather than any single interviewer deciding alone. The bar raiser can push back on a borderline hire even if the hiring manager wants to move forward.

Very specific: name the project, the timeframe, the actual decision you made, and the measurable or observable result. Generic examples about teamwork in general, without a concrete situation, tend to score poorly regardless of how well they're delivered.

Yes, internships, class projects, part-time jobs, and even significant personal projects are all fair game as long as you can speak to them in specific, first-person detail. Amazon does not require full-time work history for strong behavioral answers.

The OA is typically an automated, unproctored or lightly proctored test taken independently on your own schedule, while the coding phone screen is a live conversation with an actual interviewer watching you think and code in real time. The live round weighs communication and reasoning far more than the OA does.

Recruiters are generally flexible and will work with your availability, especially if you're balancing interviews with a current job. It's reasonable to ask for a reschedule if you need more preparation time, though repeated delays can slow your candidacy.

Look into the specific team or org you're interviewing for, recent product launches relevant to that space, and Amazon's Leadership Principles in your own words rather than memorized definitions. Generic knowledge about Amazon as a company matters less than understanding the team you'd actually join.

It happens, especially for generalist SDE or business roles where Amazon runs a central pipeline and matches successful candidates to teams afterward. In those cases the loop tests general competency rather than one team's specific stack or domain.

Write out five to seven real work or project stories first, before touching any technical prep, since behavioral readiness is often the bigger gap for new candidates. Then layer in role-specific technical practice once you have solid stories to draw from.

Mostly yes, questions are phrased as 'tell me about a time when...' prompts that expect a structured, specific answer, though the exact Leadership Principle behind each question varies by interviewer. Recognizing the format helps you prepare flexible stories that can flex across several principles.

Interviewers want to hear about decisions you made without waiting for direction, problems you caught before they became bigger, and trade-offs you owned even when the outcome was uncertain. A mid-level answer should show initiative beyond your assigned tickets or tasks.

Most mid-level loops run four to five interviews plus the bar raiser, similar in count to entry-level loops but heavier in technical and scope-related depth per round. Some specialized roles add an extra round for domain-specific assessment.

For technical roles, expect harder problems solved with less guidance, plus an expectation that you proactively discuss edge cases, complexity trade-offs, and testing strategy without being prompted. Interviewers also probe your reasoning when you hit a wrong path, beyond just whether you eventually reach a solution.

Beyond a single technical answer, interviewers ask how you would approach ambiguous, larger-scope problems, looking for structured thinking, prioritization, and awareness of trade-offs across teams or systems. This applies to technical, product, and operations roles alike, just with different subject matter.

A strong example describes a moment where surface-level metrics looked fine but you investigated further and found a real problem, such as auditing a process, digging into logs, or questioning a metric that didn't add up. The key detail is showing the habit of checking rather than assuming.

Focus on a real disagreement where you respectfully pushed back with data or reasoning, and be honest about the outcome, whether you were right, wrong, or somewhere in between. Amazon values people who commit fully once a decision is made, even if they initially disagreed.

At entry-level, interviewers mostly check whether you can solve the problem correctly. At mid-level, they weigh how efficiently and independently you get there, whether you consider multiple approaches, and whether you communicate trade-offs proactively rather than only when asked.

Not formal management, but yes, some form of driving a project or initiative end to end, even a small one, matters at this level. Interviewers listen for evidence you can operate with real autonomy rather than needing constant direction.

Expect questions about a time you refused to ship something below quality, caught a problem others missed, or pushed for more testing or rigor despite time pressure. The strongest answers show a genuine tension between speed and quality that you navigated thoughtfully.

Be explicit about the size and impact of what you worked on, whether that's users affected, revenue involved, or the number of systems or teams touched, since vague scope makes it hard for interviewers to calibrate your level. Numbers, even rough ones, help ground the story.

The bar raiser digs harder into consistency across your stories at this level, cross-checking whether your claimed level of ownership matches what a typical 3-6 year professional would realistically have driven. Inflated or vague claims tend to get caught here.

Expect scenario questions involving a metric decline, a process bottleneck, or a resourcing trade-off, where you're asked to structure an approach and defend your prioritization. Amazon looks for a clear, logical framework rather than one specific 'correct' answer.

Shift preparation time from purely technical practice toward refining scope and impact framing in behavioral stories, since technical competence is assumed and the differentiator becomes judgment and ownership. Reviewing past performance reviews or project retrospectives can surface strong material.

Underselling their own role in team successes, or conversely overselling scope in a way that unravels under follow-up questions. Both mistakes come from not having rehearsed the specific, honest details of a story beforehand.

Some informal mentoring or onboarding of junior teammates is a good signal at this level and fits well under Hire and Develop the Best, though formal management experience is not required. Even helping a new hire ramp up counts as a valid example.

Non-engineering roles won't face formal system design, but they will face process design questions, such as how you'd structure a workflow, a reporting cadence, or a cross-team handoff to avoid failure points. The underlying skill being tested is the same structured thinking, just applied to process instead of software.

Expect at least two or three probing follow-ups per story, such as what you'd do differently, how a stakeholder reacted, or what data you used to make the call. Prepare stories with enough real detail to sustain that depth of questioning.

Interviewers listen for a time you made a reversible decision quickly rather than over-analyzing it, and for awareness of when a decision was actually high-stakes and irreversible enough to warrant more caution. The nuance between the two is part of what's being tested.

Describe a time you solved a problem with existing resources or a simpler approach instead of requesting more headcount, tools, or budget. Amazon values resourcefulness as a mindset, not simply cutting costs for its own sake.

Own the failure clearly, explain the actual root cause rather than deflecting blame, and describe the concrete change you made afterward. A mid-level answer should show a mature, systemic fix, beyond just a personal lesson learned.

Yes, especially for roles that sit between teams, expect questions about influencing people you don't manage, handling disagreement with a more senior stakeholder, or getting buy-in without formal authority. This maps closely to Earn Trust and Have Backbone.

Roughly two to three minutes is typical, long enough to cover real context and outcome but short enough to leave room for follow-up questions. Rambling past four or five minutes usually signals the story wasn't tightly prepared.

It should reference specific teams, products, or problems relevant to the role you're applying for, showing you've thought about where your experience actually fits, rather than a general statement about company reputation or scale.

Senior technical loops typically include a dedicated system design round where you're asked to design a real service or feature from scratch, covering scalability, failure handling, and data consistency trade-offs. Interviewers push on your reasoning for each choice rather than accepting a memorized architecture pattern.

Senior questions probe for leadership through influence, such as driving alignment across multiple teams or changing a widely held opinion with data. The expectation is that you shaped outcomes beyond your immediate team, past simply delivering your own workstream well.

A strong example describes proposing a direction that expanded beyond the original ask, backed by a rationale for why the bigger bet was worth the added risk or investment. Interviewers want to see the judgment behind the ambition, beyond just an ambitious idea.

Through questions about driving a decision when you didn't have direct authority over the people involved, and how you built consensus or escalated appropriately when consensus wasn't possible. Concrete examples of written documents, data, or proposals used to persuade carry real weight here.

The bar raiser scrutinizes whether a candidate's stated scope and impact genuinely match what's expected at the target level, since senior title inflation is a known failure mode Amazon actively guards against. Expect harder calibration questions about the actual size and difficulty of what you led.

Ask clarifying questions first to scope the problem realistically, state your assumptions explicitly, then design incrementally, starting simple and adding complexity as you justify it. Amazon interviewers are evaluating your process for handling ambiguity as much as the final design.

It shows up as setting or raising a team-wide quality bar, such as introducing a review process, a testing standard, or a metric that didn't exist before, rather than just personally producing high-quality work. The signal is influence over standards, not individual diligence alone.

Usually five to six rounds, often including a dedicated system design or strategy round, one or more deep-dive behavioral rounds, and the bar raiser, sometimes stretched across a longer single day given the added depth per round.

A senior-level answer should include what organizational or process gap allowed the failure to happen, and what structural change followed, beyond a personal lesson. Amazon wants evidence you can turn a failure into a durable fix at the team or system level.

Interviewers expect coverage of data modeling, API contracts, scaling strategy, failure and recovery handling, and monitoring, with the candidate driving the conversation forward rather than waiting to be prompted on each area. A senior candidate should also proactively flag what they'd cut under time pressure.

Clear, structured answers that lead with the outcome or key point before backfilling detail, since Amazon's internal culture favors written clarity and this style is expected to carry into how you speak. Rambling or burying the conclusion is read as a real weakness at this level.

Beyond a single service, expect questions about designing for organizational scale, such as a platform multiple teams will build on, with deep attention to extensibility, migration paths from existing systems, and long-term maintenance cost, beyond initial correctness.

Amazon's internal culture distinguishes one-time good intentions from durable mechanisms, so staff-level candidates should describe a process, tool, or review cadence they created that continued working without their constant involvement. This shows systemic thinking rather than heroics.

Expect questions about a time you set direction for a whole team or org, including how you built the case, secured buy-in from stakeholders with competing priorities, and measured whether the bigger bet actually paid off over time.

The bar raiser weighs whether the candidate's influence genuinely extended beyond their immediate reporting line, since staff-level impact claims are the most prone to exaggeration, and pushes hard on specifics like who exactly adopted the candidate's proposal and why.

It's framed around consistently delivering outcomes across multiple initiatives or teams over a sustained period, not a single project win, with attention to how the candidate prioritized among competing demands under real resource constraints.

Describe the actual trade-off calculus you used, including business risk, migration cost, and team capacity, and be honest about what you deprioritized and why. Amazon values pragmatic sequencing over an idealized 'fix everything' narrative.

A story where you took responsibility for an outcome outside your formal job description because it was the right thing for the business, including following through long after the immediate crisis or urgency had passed.

Through open scenario questions asking how you'd prioritize across competing initiatives with limited resources, where interviewers assess whether your reasoning holds up under pushback and whether you can articulate what you deliberately chose not to do.

A credible answer includes both the substance of your disagreement and how you eventually aligned the organization, whether by changing minds with data or by committing fully once the decision was made, showing maturity in both directions.

Interviewers usually expect enough hands-on depth to be credible on technical trade-offs, paired with breadth across systems or domains sufficient to make cross-team architectural calls. Pure depth without organizational awareness tends to read as still mid-level in scope.

Given Amazon's document-driven culture, staff candidates are often asked how they've used written narratives to drive a decision, and interviewers listen for structured, persuasive reasoning rather than a purely verbal pitch style.

Focus on what broke as things scaled, how you diagnosed the actual bottleneck, and what durable change you put in place, since Amazon wants evidence of systems-level problem solving rather than just adding more people.

The staff version typically shows the candidate operating with less oversight, setting the agenda rather than executing someone else's, and demonstrates that their decisions shaped how multiple teams or a whole function operates going forward.

This newer Leadership Principle asks leaders to consider the wider impact of Amazon's scale on customers, employees, and society, so leadership-track candidates may be asked how they've weighed broader consequences, beyond narrow business metrics, in a major decision.

Through questions about restructuring a team, changing reporting lines, or redefining a team's charter, with interviewers probing the reasoning behind the structure and how you measured whether it actually improved outcomes afterward.

Candidates should speak to a track record of building bench strength, such as promoting multiple people into leadership roles or establishing a talent pipeline, rather than a single mentoring anecdote. The scale of impact on the talent pool is the differentiator here.

Through open questions about setting a multi-year direction for an organization, including how the strategy was communicated, how progress was tracked, and how the plan adapted when market or business conditions shifted.

An example that reshaped how a business unit or org operates, with a clear before-and-after, including how the candidate secured executive-level buy-in and resourcing for a bet that carried genuine organizational risk.

Leadership-track candidates are expected to show resource discipline across an entire budget or org, such as reallocating spend toward the work with the biggest payoff or defending against scope creep, rather than a single individual cost-saving example.

Stories about navigating organizational politics honestly, delivering unwelcome news to executives or the board-level audience, or rebuilding trust after a public team failure, since leadership-level trust is tested under real stakes, not routine situations.

By asking for specific counterexamples, such as a time your leadership approach failed or needed to change, since candidates who can only describe successes tend to raise doubt about self-awareness at this level.

The bar raiser at this level often has significant organizational weight themselves and focuses heavily on whether the candidate's judgment and Leadership Principle alignment would hold up in ambiguous, high-stakes, cross-org situations, beyond familiar ones.

Through direct questions about managing out low performers or turning around a struggling team, looking for a fair, process-driven approach rather than either excessive leniency or unnecessary harshness.

Full ownership of the outcome, a clear-eyed account of the systemic causes, and concrete evidence of what changed afterward at a structural level, since leadership candidates are expected to fix systems, beyond individuals.

Through a sustained track record across multiple planning cycles, with attention to how the candidate handled trade-offs when results and timelines were both genuinely at risk, beyond a single successful launch.

Expect additional conversations with senior stakeholders or an executive beyond the standard loop, sometimes focused specifically on organizational fit and long-term vision alignment rather than repeating earlier competency-based questions.