- Process Overview & Timeline
- Online Assessment (OA)
- Phone Screen
- Onsite/Virtual Loop Structure
- DSA Prep Plan
- JavaScript Fundamentals & Polyfills
- UI Coding / Component Building
- React Deep Dive
- HTML, CSS & Accessibility
- Front-End System Design
- Leadership Principles (Behavioral)
- Bar Raiser Round — Special Notes
- 8-Week Study Plan
- Day-Before & Day-Of Checklist
- Real Question Bank (Reported by Candidates)
- Resources
Reported end-to-end timeline runs 2–5 weeks:
- Apply online → resume screen
- Online Assessment (OA) — sent within 1–2 weeks of applying
- Phone Screen (~60 min) with one engineer
- Virtual Onsite Loop — 4–5 rounds, 45–60 min each, usually same day or split over two days
- Debrief + Bar Raiser calibration → decision
Amazon explicitly states the process can vary by team — some loops are React-friendly, some restrict you to vanilla JS/HTML/CSS, and some FEE loops include a pure DSA round even though the role is "front end." Always ask the recruiter what stack is allowed before the loop.
Candidate reports consistently describe two parts:
- Coding section: 1–2 LeetCode-style problems (easy–medium), auto-graded with test cases. Plain algorithms — arrays, strings, hashmaps, trees.
- Work-style/Leadership Principles survey: scenario-based multiple choice mapped to the 16 LPs — there's no universally "correct" answer, but you should pick the option that reflects ownership, customer obsession, and bias for action.
- Some 2024–2025 reports mention a UI building component baked into the OA itself (e.g., "build a component that can add/delete rows in a table") instead of a separate round — be ready to type real JS/HTML in a constrained editor with no framework.
Prep target: Solve comfortably within 25–30 min per problem, no IDE autocomplete.
~60 minutes, one Amazon engineer, structure commonly reported as:
- 5–10 min: background, resume walk-through, motivation for Amazon
- 2 Leadership Principle questions (STAR format)
- 1–2 LeetCode-style problems, easy → medium, sometimes a JS-flavored DSA problem (e.g., implement a debounce, then a graph traversal)
- Q&A
Verbalize your thought process constantly — interviewers explicitly note that candidates who go silent while coding are marked down even if the final solution is correct.
The most consistent loop reported (Blind, Medium, GreatFrontEnd) is 4–5 rounds, each blending 2 LP questions + 1 technical challenge:
| Round | Typical Content |
|---|---|
| Round 1 | 2 LP questions + 1 frontend whiteboard component build (vanilla JS or React, ask first) |
| Round 2 | 2 LP questions + implement/polyfill a library API (e.g., build a mini version of _.debounce, EventEmitter, or a Promise utility) |
| Round 3 | 2 LP questions + 1 pure DSA problem (often graph — solvable via BFS/DFS) + a follow-up that escalates difficulty (e.g., add topological sort) |
| Round 4 (Hiring Manager) | 3 LP questions + front-end system design (e.g., design a typeahead, infinite scroll feed, or notification widget) |
| Round 5 (if present, often Bar Raiser) | Heavy LP focus, can include a second technical round or deep dive on your resume project |
Key signal across all rounds: Amazon explicitly tests semantic HTML, accessibility (ARIA, keyboard nav), scalable/testable code structure, and edge-case handling — not just "does it work."
Even as a frontend candidate, expect 2–4 pure algorithmic problems across the loop. Reported topics, ranked by frequency:
- Arrays & Strings — sliding window, two pointers, prefix sums
- Hashmaps — frequency counting, grouping, two-sum variants
- Trees — BFS/DFS traversal, serialize/deserialize, lowest common ancestor
- Graphs — most commonly cited "hard" round; solvable via BFS or DFS, with a topological sort follow-up reported multiple times
- Linked Lists — reverse, detect cycle, merge
- Stacks/Queues — valid parentheses, monotonic stack
- Recursion/Backtracking — occasionally, lighter than at pure SDE loops
Target list: Blind 75 / NeetCode 150, plus LeetCode's "Amazon" company-tagged list filtered to Easy + Medium (Hards are rare for FEE). Budget 60–70% of DSA time on Arrays/Strings/Hashmaps/Trees, 20% on Graphs, rest on everything else.
Practice discipline: Always talk out loud, write brute force first, then optimize, then discuss time/space complexity unprompted.
This is the highest-leverage category for FEE specifically — recur far more often than generic DSA.
thisbinding (4 rules: default, implicit, explicit,new), arrow functions and lexicalthis- Closures and the module pattern
- Prototypes and prototypal inheritance,
Object.create - Event loop, microtasks vs macrotasks,
async/awaitvsPromise.then - Hoisting,
var/let/const, temporal dead zone, scope chains - Currying, partial application, memoization
debounceandthrottleArray.prototype.map / filter / reduce / flatPromise.all / Promise.race / Promise.allSettled(and a basic Promise/A+ implementation)- A simple Pub/Sub or EventEmitter
bind/call/applypolyfills- Deep clone / deep equal
- A basic virtual DOM diffing function (asked at the FEE II level occasionally)
Prep target: Be able to write each of the above cold, in under 10 minutes, with edge cases (e.g., this context, cancel/flush for debounce, error short-circuiting for Promise.all).
The single most distinctive part of Amazon's FEE loop vs. a generic SDE loop. Reported components, almost verbatim across years of Glassdoor/Blind posts:
- Accordion (then a follow-up: make it accessible with correct ARIA roles/states, then add full keyboard support)
- Data table with add/delete row functionality, sorting, and sometimes pagination
- Todo list (CRUD + local state management)
- Signup/login form with client-side validation
- Tabs component
- Modal/dialog with focus trapping
- Star rating widget
- Typeahead/autocomplete (sometimes appears here instead of in system design)
What's actually being graded:
- Component decomposition and state management approach
- Semantic HTML choices (not div-soup)
- Accessibility — ARIA roles,
aria-expanded, keyboard support (Tab/Enter/Arrow keys/Escape) - Edge cases: empty states, rapid clicks, race conditions on async data
- Clean event handling (delegation where relevant) and cleanup (removing listeners, clearing timers)
Confirm with your recruiter or interviewer up front whether React or vanilla JS is expected — some loops explicitly restrict you to vanilla JS + DOM APIs.
When React is permitted, expect both conceptual and applied questions:
- Reconciliation and the virtual DOM — what triggers a re-render
useStatevsuseReducer, when to lift state up vs colocateuseEffectdependency arrays, cleanup functions, common pitfalls (stale closures)useMemo/useCallback— real-world cases, not just definitions- Controlled vs uncontrolled components
- Custom hooks — be ready to extract one live (e.g.,
useDebounce,useFetch,useLocalStorage) - Context API vs prop drilling vs external state libraries — trade-offs
- Performance: list virtualization, memoization boundaries, avoiding unnecessary renders
- Error boundaries and Suspense (lighter, but can come up at FEE II)
Frequently underestimated — Amazon interviewers probe this directly, not just through component-building rounds.
- Semantic HTML — when to use
<button>vs<div onClick>, landmark elements - Accessibility: ARIA roles/states/properties, focus management, screen-reader behavior, color contrast, keyboard-only navigation paths
- CSS layout: Flexbox vs Grid trade-offs, box model, specificity/cascade, responsive design (media queries, fluid typography)
- Performance: critical rendering path, render-blocking resources, lazy loading, debouncing scroll/resize handlers
- Browser APIs: localStorage/sessionStorage, IntersectionObserver, Web Workers basics
Reserved for the Hiring Manager round or final loop slot. Solved conceptually + light pseudo-code in vanilla JS/HTML/CSS, not full implementation.
Reported prompts:
- Design a typeahead/autocomplete component (debouncing, caching, race-condition handling, abort controllers)
- Design an infinite-scrolling feed (windowing, data fetching strategy, placeholder/loading states)
- Design a notification/toast system
- Design a client-side data table with sort/filter/pagination at scale
- Design a real-time chat widget (websockets vs polling trade-offs)
- Design a form builder/validation framework
Structure your answer like this:
- Clarify requirements and scale (data size, devices, offline needs)
- Component/data architecture diagram (verbally or sketch)
- State management strategy
- API contract and data fetching/caching
- Performance, accessibility, and error/edge-case handling
- Testing strategy
LP questions appear in every single round, not just a dedicated round — typically 2 per technical round, 3 in the hiring-manager round. This is roughly half the total interview signal.
Customer Obsession · Ownership · Invent and Simplify · Are Right, A Lot · Learn and Be Curious · Hire and Develop the Best · Insist on the Highest Standards · Think Big · Bias for Action · Frugality · Earn Trust · Dive Deep · Have Backbone; Disagree and Commit · Deliver Results · Strive to be Earth's Best Employer · Success and Scale Bring Broad Responsibility.
- Customer Obsession — "Tell me about a time you made a decision that was unpopular but right for the customer/user."
- Ownership — "Tell me about a project you owned end-to-end."
- Earn Trust — "Describe giving difficult feedback to someone senior, or admitting a mistake."
- Dive Deep — "Tell me about a time you found the root cause of a tricky frontend bug others missed."
- Bias for Action — "Describe a time you made a decision with incomplete information."
- Have Backbone; Disagree and Commit — "Tell me about disagreeing with your manager/designer and what you did."
- Deliver Results — "Tell me about hitting a deadline despite obstacles."
- Build a story bank of 10–12 STAR stories from real projects, each one tagged to 2–3 LPs it can serve.
- Structure: Situation → Task → Action → Result, with the Result quantified wherever possible (latency reduced, bugs cut, adoption increased).
- For each story, write 5 likely follow-up/probing questions and rehearse answers — Bar Raisers dig deep into "why," "what would you do differently," and "what was the data."
- Don't reuse the same story for two LPs in the same loop — interviewers compare notes.
- The Bar Raiser is an interviewer from outside the hiring team, present specifically to keep the hiring bar consistent and can veto a hire even if every other interviewer says yes.
- Expect the most aggressive follow-up questioning of any round — they will probe inconsistencies in your story timeline, push on "what was YOUR specific contribution" in team projects, and ask what you'd do differently in hindsight.
- Technical content may be lighter, but don't assume it's behavioral-only; some FEE Bar Raiser rounds still carry a coding component.
| Week | DSA | JS/Front-End | LP/Behavioral |
|---|---|---|---|
| 1 | Arrays, strings, hashmaps (15 problems) | this, closures, prototypes, event loop |
Draft 5 STAR stories |
| 2 | Two pointers, sliding window | Implement debounce/throttle, Array polyfills | Draft remaining 5–7 stories |
| 3 | Trees (BFS/DFS, traversals) | Build Accordion + Modal (vanilla JS, then add a11y) | Practice 6 LPs out loud |
| 4 | Graphs (BFS/DFS + topo sort) | Build Data Table (CRUD, sort) | Mock interview: 2 LP + 1 coding |
| 5 | Linked lists, stacks/queues | React: hooks deep dive, build custom hook | Practice remaining LPs |
| 6 | Mixed review (timed, 25 min/problem) | Promise.all/race, EventEmitter, mini virtual DOM | Mock interview: full round simulation |
| 7 | Amazon-tagged Leetcode Medium set | Front-end system design (typeahead, infinite scroll) | Full mock loop (3–4 rounds) w/ a friend |
| 8 | Light review only — no new topics | Review weak components, rebuild from memory | Polish stories, rest, logistics check |
- Confirm with recruiter: vanilla JS or React allowed? Whiteboard/collab tool used (CoderPad, Amazon's internal tool, etc.)?
- Re-read your 10–12 STAR stories once; don't memorize word-for-word, internalize the structure
- Set up a quiet space, test camera/mic/screen-share tooling in advance
- Have water nearby; loops can run 4–5 hours across multiple rounds
- Prepare 2–3 thoughtful questions per interviewer (team's biggest frontend challenge, how they balance LP "Frugality" vs. tooling investment, etc.)
- Remember: narrate your thinking constantly — silence is graded down even when the final answer is correct
Coding/DSA
- Graph problem solvable by BFS or DFS, with a topological-sort follow-up
- Build a function to add/delete rows in a data table with test cases
- Implement an API found in a frontend utility library (debounce/throttle/EventEmitter style)
- Standard Leetcode medium (arrays/strings/hashmap) in the OA and phone screen
UI/Component
- Accordion (then: make accessible with ARIA → then: add full keyboard support)
- Data table with add/delete and sort
- Todo list with full CRUD
- Signup form with validation
System Design
- Frontend system design solved in vanilla JS/CSS/HTML including DOM API (final onsite round)
Behavioral
- "When was a time you faced an issue while working on a project?" (root-cause/ownership)
- "Tell me about a time you disagreed with a decision and what you did."
- "Describe a project you're most proud of and your specific role."
- "Tell me about a time you had to simplify a complex problem for stakeholders."
- LeetCode — Amazon company-tagged problems, filtered Easy/Medium
- GreatFrontEnd — Amazon Front End Interview Guide (UI components, JS implementation questions)
- Glassdoor — "Amazon Front End Engineer Interview Questions" (search recent postings for team-specific variance)
- Blind (teamblind.com) — search "Amazon FEE" for loop breakdowns by YOE
- Amazon's official Leadership Principles page — read the original definitions, not just summaries
- NeetCode 150 / Blind 75 — DSA pattern coverage
- Mock interviews (with peers or recorded solo runs) — the single most cited prep method for fixing "thinking out loud" weaknesses