Amazon 2026 New Grad Timeline and Interview Experience
Role: Frontend Engineer, or perhaps Full Stack Engineer. During the interview, the hiring manager said there could be an opportunity to move toward full-stack work within the team later.
I just finished interviewing for an Amazon Frontend Engineer role this week. I wanted to share the full process, the interview content, and the resources I used to prepare in case they help other people looking for work.
Timeline:
June 2 — Applied on the company website.
June 3 — Received the online assessment.
June 12 — Completed the online assessment. I had not checked my email much and only noticed it close to the deadline, so I barely made it.
July 2 — Asked to schedule the phone screen.
July 3 to July 7 — Emailed back and forth with HR to confirm a time. It was not efficient, and a scheduling conflict pushed the interview into the following week.
July 8 — Finally confirmed the time.
July 16 — Phone screen with behavioral questions and frontend coding.
July 28 — Learned that I had passed the phone screen and started scheduling the final round, a virtual onsite. After scheduling, I learned that I was interviewing for the EC2 Pricing team under AWS.
August 13 — Final round with two interviews: a senior engineer, who briefly reviewed my resume and covered frontend fundamentals and frontend coding, and the hiring manager, who asked behavioral questions and a DSA-like problem.
August 19 — Bar Raiser, entirely behavioral.
Interview Experience
R1: Phone Screen
The interviewer was a very kind senior engineer. We chatted for a few minutes at the beginning, and the overall atmosphere was relaxed, which reduced my stress a lot.
Behavioral questions: I was first asked to choose an experience, and the interviewer built the questions around it. Had I done anything to improve something or acted outside my responsibility? Was there anything I did not do at the time that I would do better if I could start again?
Coding: I had to design a user interface from a provided image and implement its behavior. The page had three numbered buttons. Clicking a button opened the corresponding floating window and rendered data returned from a request; the window could also be closed. The buttons, floating windows, and content layout all had to match the image.
We used a live-code editor with no keyword suggestions. I wrote everything by hand and could not look anything up, though I could ask the interviewer questions at any time. My impression was that every detail did not need to be completely correct. Covering most of the important points and showing command of the concepts was enough to pass.
R2: Hiring Manager Interview
The interviewer was a very nice manager. I began with a short self-introduction and was then asked why Amazon.
Coding: Suppose the backend sends an array in which each item is a map containing a comment ID, the parent comment ID, and the comment text. The comment system supports multiple levels of nesting, and I had to print every comment in a hierarchical structure.
I spent about 30 minutes on the problem. The code itself took only about 20 minutes, but during both the initial design and the coding, the interviewer asked many clarifying questions, so I spent a lot of time explaining my reasoning. I built an N-ary tree, which worked. After the interview, I looked into it and felt that a hash map might be the optimal solution.
Behavioral question: Describe a past experience in which I made a mistake with real consequences and how I handled it.
R3
The interviewer was a senior engineer whose accent was harder for me to understand. He looked fairly serious at first but was generally nice. The only drawback was that the interview had no fixed structure. He often threw out a question without warning and did not provide much context, so I had to confirm things myself.
We started with a short discussion of one of my recent projects. He asked about its technology stack and why I chose those technologies.
Then he moved into frontend topics. He gave me a short code snippet and asked for its output. The essence was the difference between let and var. Because I almost never use var now, I was not familiar enough with it and answered incorrectly.
He drew a layout with text characters and asked me how to center one element. Between his accent and the diagram itself, it was difficult to understand. I asked two clarifying questions, but for some reason he did not explain and simply switched to another question.
I then had to simulate an Amazon Shopping search bar that displayed the 10 products most relevant to a keyword. We initially assumed the backend data was hard-coded. As the discussion went deeper, he kept adding follow-ups: how to handle it without hard-coding, how to call a provided API, and how to optimize the requests with debouncing.
R4: Bar Raiser
This interviewer was also very chill. We chatted for a few minutes at the beginning about his own experience, and he explained that his only responsibility that day was to collect the necessary information.
The behavioral questions were:
A time I dug deeply into something, spent a lot of time on it, and eventually figured it out.
A time I realized my team was heading in the wrong direction and how I took action.
A time I wanted to learn a frontend technology and then applied it. The interviewer previously worked on backend systems and was curious about frontend technology, so he followed up by asking how that technology adapted to different devices and screen sizes.
Anything I wanted to share but had not had a chance to mention during the earlier interviews.
Interview Preparation
Frontend fundamentals: I recommend Heima JavaScript for a solid review of the basics.
Algorithms: Amazon did not ask that many LeetCode questions, but I recommend working carefully through Code Capriccio and becoming comfortable with the Hot 100. Even without seeing an exact question before, that foundation can help you reason out a solution or at least explain a direction.
Behavioral questions, especially important: Amazon cares a great deal about behavioral questions, so prepare seriously. I recommend creating stories around Amazon's 16 Leadership Principles. One story can sometimes cover two or three principles, and roughly eight to ten stories should be enough.
Read every Leadership Principle carefully and understand its core. Sometimes that lets you work backward to the behavioral directions an interviewer may ask about. If one story covers several principles, the interviewer will usually count all of them and then follow up on a different area that has not yet been covered.
I mainly used one detailed preparation document as a reference.
Discussion
Loading comments…