Amazon Frontend Engineer Interview: Every Round, Decoded

Most frontend engineers show up to the Amazon frontend engineer interview having practiced trees, hash maps, and maybe a few React performance questions. They breeze through the DSA round. Then the next screen loads and the prompt says "implement debounce from scratch, no libraries." Their hand reaches for import, and there's nothing to import.

Then comes the behavioral round. Eight questions. One after another. All graded.

This guide covers every stage, what each one actually tests, and the parts that catch people off-guard. None of this is secret. Amazon publishes most of it. The problem is that most candidates don't read it until after their first loop.

The Process at a Glance

Stage	Format	Duration	What Gets Tested
Online Assessment	Async, coding platform	~90 min	UI building, basic DSA
Phone Screen	Video call	45-60 min	LP questions + frontend coding
Onsite Loop	4-5 virtual rounds	~55 min each	DSA, frontend fundamentals, system design, LPs
Debrief	Internal	1-2 weeks	Hiring committee decision

Amazon runs everything virtually. The loop usually spans one or two days. You'll code in CoderPad or an internal Amazon tool. One round will be with a Bar Raiser from outside your hiring team, someone you won't recognize until after the fact.

What the OA Actually Tests

You'll get the OA within a few days of applying. Two parts.

The first is UI building: a short spec, implement a component in HTML, CSS, and vanilla JavaScript. No React. No TypeScript. No Vite, no Create React App, no component library. Think a sortable table, a filterable list, or a multi-step form. The rubric rewards working code over clever abstractions. A component that handles edge cases cleanly beats an overengineered one that breaks.

The second is standard LeetCode-style DSA. Medium difficulty, mostly arrays, strings, and hash maps. You get test cases but no editorial. Time is the constraint. Finish both parts comfortably and you're ready for the phone screen. Finish neither and, well, you've just saved yourself two weeks of calendar hold.

Behavioral First, Then Code

The phone screen is 45 to 60 minutes and splits roughly in half. The first half covers Leadership Principles. Your recruiter may tell you to prepare two or three LPs specifically, or they'll say "review the LPs," which means all sixteen of them. Either way, you need structured STAR stories with concrete outcomes, ideally with numbers. "We improved performance" is the story that ends the conversation.

The second half is live frontend coding. Common formats: implement debounce, traverse a nested data structure, build something small with DOM manipulation. They want clean vanilla JS, not your React instincts. Narrate your thinking throughout. Silence is a score.

Every Round Has Two Scores Running

Every round in the loop has the same shape: 15 to 20 minutes of behavioral questions, then technical. The behavioral component is not a warm-up. It is not small talk. It is scored. Every interviewer submits written feedback on both dimensions, and the hiring committee reads all of it.

This is the part that surprises candidates who prepped for a standard FAANG loop. You can write beautiful code for 35 minutes and still leave the interview with nothing useful in your write-up if you spent the first 15 minutes giving vague, story-free answers about "collaborating with cross-functional teams."

The rounds cover four areas:

Data structures and algorithms
Front-end fundamentals
System design (mid-to-senior; sometimes omitted at L4)
Bar Raiser (heavily behavioral, sometimes technical too)

DSA with a Frontend Flavor

This round looks like a standard SWE coding interview, but the problems often have a frontend frame. You'll still see trees, strings, and hash maps. The context might involve DOM structures, component hierarchies, or browser event modeling. The DOM is an n-ary tree. Amazon knows you know that. They're checking if you know what to do with it.

Real examples reported by candidates:

Flatten a nested JSON object representing a component tree
Find all nodes at depth K in an n-ary tree
Reconstruct a tree from a serialized virtual DOM representation
LRU cache implementation
Top K frequent elements from a stream of user events

Difficulty is mostly medium, occasionally hard for senior roles. The interviewer is watching how you decompose the problem, not just whether you reach the optimal solution.

See DSA for Frontend Engineers for the patterns worth prioritizing.

The Vanilla JavaScript Round Most Candidates Don't Prepare For

This is where frontend engineers who over-rotated on LeetCode get exposed. The round exists because Amazon ships a lot of vanilla JavaScript internally, and "I usually use a library for that" is not an answer that works in production.

You need to implement core JavaScript utilities from scratch, no libraries.

Expect:

debounce(fn, delay) and throttle(fn, delay)
Promise.all and Promise.allSettled
Array.prototype.map, reduce, or flat from scratch
A deepClone that handles circular references
A simple event emitter with on, off, and emit

Beyond implementation, the round covers concepts. The event loop, microtask queue, closure behavior, prototype chain, this binding in different contexts, and the critical rendering path (reflow vs repaint). You may also build a small component from scratch: tabs, accordion, autocomplete. Accessibility and keyboard navigation come up for senior roles.

// Classic Amazon ask: implement debounce from scratch
// If your instinct was to import lodash, that's the whole problem
function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
}

Practice writing these in a blank editor, without autocomplete. The muscle memory matters under pressure. Do it until it's boring.

Plankton from SpongeBob: "I don't know. I didn't think I'd get this far." Caption: WHEN YOU PASS THE TECHNICAL INTERVIEW AND HR ASKS WHAT YOUR EXPECTED SALARY IS

Every React developer who just implemented debounce from memory for the first time.

System Design Means the Client Layer

For L5 and above this round is nearly certain. At L4 it appears in some loops and not others.

The prompts are product-oriented: design Amazon's product search typeahead, design checkout page state management, design a real-time notification system for the seller dashboard. The emphasis is on the client layer, not backend infrastructure. Walk through component architecture, data flow, API contract, performance constraints, and trade-offs.

The discussions interviewers look for: client-side vs server-side rendering for SEO-sensitive pages, WebSocket vs polling for live updates, virtualized lists for large catalogs, code splitting and lazy loading for large applications.

Draw things out. Use a whiteboard or shared doc. Silence during system design is a red flag in a way it isn't during a coding problem. During coding, silence means you're thinking. During system design, silence means you don't have anything.

Leadership Principles Are Scored in Every Round

Amazon has 16 Leadership Principles. They are evaluated in every single round, not just the behavioral one. If you read that sentence and thought "okay but the coding rounds are mostly coding," you are the candidate this section is for.

The principles that surface most in engineering interviews: Customer Obsession, Ownership, Dive Deep, Insist on the Highest Standards, Bias for Action, Deliver Results. For frontend specifically, Customer Obsession comes up often because the frontend is what the customer actually touches. The closer you are to the user, the more Amazon expects you to care about them.

You need five to seven STAR stories, each mapping to multiple principles. A story about pushing back on a deadline to ship proper accessibility support can hit Insist on the Highest Standards, Have Backbone Disagree and Commit, and Customer Obsession simultaneously. One story, three boxes checked.

The Bar Raiser may spend 30 to 40 minutes on behavioral alone, probing the same story from multiple angles. Vague answers land flat. "We improved performance" tells them nothing. "I profiled the bundle, found a 200KB dependency we weren't using, removed it, and cut LCP by 400ms" is what gets written down.

Read the Bar Raiser guide before your loop.

The Bar Raiser Holds Effective Veto Power

The Bar Raiser is an Amazon employee from outside your hiring team, trained specifically for this role. Their job is to evaluate whether you raise the overall bar at Amazon, meaning you should be better than at least 50% of current Amazonians in your role.

The round can be technical, behavioral, or both. You won't know going in. One candidate's 2025 experience: eight behavioral questions back to back, each drilling a different LP, no technical component at all. Another got a coding problem with LP questions woven through the whole hour. The Bar Raiser invents their own format.

Don't try to guess which round is the Bar Raiser. Treat every round like it might be. You'll find out which one it was when the process is over.

Screenshot of a rejection text message after 8 rounds of interviews

Eight rounds. The Bar Raiser voted no. This is why you prep the behavioral component.

The Mistakes That Actually Cost People the Offer

Mistake 1: Practicing React, shipping vanilla JS gaps. Amazon's official prep page and multiple recruiter reports confirm the restriction to HTML, CSS, and vanilla JS. Some phone screen interviewers explicitly say no React. Know vanilla JS deeply. Know it the way you know your own name.

Mistake 2: Treating LP questions as soft filler. Candidates who deliver weak behavioral answers in the first 15 minutes of a technical round start the coding portion already behind. Both scores go on the same write-up.

Mistake 3: Going silent during frontend fundamentals. Event loop and closure questions are conversational, not solve-and-move-on. Candidates who freeze leave interviewers with nothing to write. See technical interview communication for how narration changes the write-up.

Mistake 4: Skipping system design prep entirely. Even at L4, you might get it. Thirty minutes on frontend architecture patterns pays off disproportionately against candidates who never thought about it. The question isn't hard. The candidate who hasn't thought about SSR vs CSR is hard to write good feedback for.

Mistake 5: Writing generic LP stories. No ownership signal, no conflict, no measurable result. The Bar Raiser has seen this hundreds of times. It reads as someone who has read about Ownership without ever exercising it.

How to Spend Your Prep Time

Weeks 1-2: JavaScript fundamentals. Implement debounce, throttle, deep clone, Promise.all, a basic event emitter, and Array.prototype methods from scratch. Write each one in a blank editor. Then write it again the next day. Jake Archibald's event loop talk is the best 35 minutes you'll spend on this interview.

Weeks 2-3: DSA with a frontend lens. Focus on trees (n-ary, DOM traversal), hash maps, and string problems. LeetCode mediums only. For each problem, practice narrating your approach before writing code. Read how to approach coding interview problems.

Weeks 3-4: LP stories and system design. Write five to seven STAR stories, each mapped to three or four LPs. Then do two or three frontend system design sessions out loud: typeahead, infinite scroll, multi-step checkout. Talk through the trade-offs. Don't list them, walk through them like someone is asking follow-up questions.

Final week: Reps under pressure. You need mock interviews with someone pushing back on your reasoning. SpaceComplexity runs voice-based mock interviews with rubric feedback across all four dimensions including communication, which is the dimension Amazon weighs in every single round.

For senior roles, add two to three weeks for deeper system design and more complex DSA. After a long gap, eight to ten weeks is realistic.