Amazon Software Engineer (L4) Interview Experience
Amazon · Mid level · Software Engineer
I said I deep dived on an AI project, and they immediately started asking what parameters I used to train the model and why I switched from one LLM to another. Even the behavioral round got super technical.
Interview process
I interviewed for an L4 entry-level SWE role, and the process was one 30 minute phone screen followed by a three-interview super day. The phone screen was quick and a bit rushed, with no real introduction, just one medium array problem and then Q&A. In the loop, the behavioral was only about 10 minutes, but it was done by a technical person who kept going deeper and deeper into whatever project I brought up, so it felt more technical than I expected. The coding round was classic DSA with a graph problem and then a heap problem because we had extra time, and the last round was a low-level OOP design around coupons and vouchers. Overall, I did not think the interview was that difficult, but I realized you really have to be ready to defend the details of your behavioral examples.
Interview rounds · 4
- 1
Phone screen
CodingData Structures & AlgorithmsI had a 30 minute phone screen that felt rushed. There was basically no introduction and it went straight into one LeetCode-style array problem, then a little Q&A at the end.
Q1. Solve an array problem where you are given two arrays and need to construct a new array by multiplying values across positions.
How they answeredI got an array problem that was around medium level. The way I saw it, it could be done with prefix sum or just a vanilla traversal with a for loop. The setup was that I had two arrays, and for each index I had to multiply values across the arrays and build a new array to return. Since it was only 30 minutes and there was no intro, I just had to get into solving fast.
- 2
Final / onsite round
BehavioralTechnicalProject DiscussionThe first loop round was a short behavioral, around 10 minutes, but it was not a soft round at all. The interviewer was technical and kept drilling into the details of whatever example I gave.
Q1. Tell me about a time you had to deep dive.
How they answeredI answered with a project where we hit a problem and had to really understand the concept more deeply. I talked about working with AI models, where I first chose one LLM model, then felt it was not good enough and shifted to another one after more research. He went very technical on me and asked why I chose that model, what training parameters I used, and what tweaks I made to make it efficient. It felt like he was checking whether I actually understood the work, not just the story.
Follow-up questions- Why did you choose that approach or tool?
- What parameters did you use for training the model?
- What tweaks made the model efficient?
- Q2. Tell me about a time you were out of your comfort zone.
- 3
Final / onsite round
CodingData Structures & AlgorithmsConceptTechnicalThe coding round was a pretty standard DSA interview, but the interviewer mixed problem solving with concept checks. I got through one graph problem and, because there was time left, we moved to a second heap problem.
Q1. Solve a graph problem related to connected components.
How they answeredThe first problem was graph related and mainly about connected components. I solved it using the usual graph traversal idea, and while I was working, the interviewer kept asking concept questions like what BFS is, what DFS is, the difference between them, and when I would use each one. So it was not only coding. They also wanted to see that I actually knew the definitions and how to choose the traversal.
Follow-up questions- What is BFS?
- What is DFS?
- What is the difference between BFS and DFS?
- When would you use BFS versus DFS?
Q2. Solve a heap-related problem and discuss how a heap is implemented.
How they answeredAfter the graph problem, we still had time, so we moved to a heap problem. The discussion was about how a heap is implemented and how the same problem could be solved from different angles. It felt like they wanted both the coding ability and the underlying data structure understanding, not just a memorized solution.
Follow-up questions- How is a heap implemented?
- Can you solve this in different ways?
- 4
Final / onsite round
System DesignTechnicalConceptThe last round was low-level system design in an object-oriented style. It was very class-focused, with inheritance and abstraction, and most of the follow-ups were about handling coupon edge cases rather than big trade-off discussions.
Q1. Design a coupon and voucher system for purchases, including different discount types and the ability to add new coupon types.
How they answeredI had to design a low-level system for vouchers and coupons used when buying products. The discounts could be percentage based or fixed value, like 10% off or $10 off, and I needed to model the classes so the system could also support adding new coupon types later. I explained it in an OOP way using classes, inheritance, and abstraction, plus how to calculate the final amount. The follow-ups were mostly edge cases, like applying two kinds of coupons to one product or different coupons across multiple products.
Follow-up questions- How would you handle two different coupons on a single product?
- How would you handle multiple coupons used across different products?
Tips from the candidate
Prepare behavioral much more seriously than you think, because the behavioral is done by technical people and they will go deep on your answer. Do LeetCode on graphs, arrays, and strings, and make sure you can explain concepts like BFS vs DFS while coding. Also have some basic low-level system design and object-oriented programming ready, especially classes, inheritance, and abstraction. Mock interviews help a lot because you get used to the environment, and it even helps if you play interviewer once so you understand what they are looking for.
Company culture
What I noticed is that they keep the process pretty structured and efficient: one short phone screen, then a single-day loop. Even the behavioral is not really a relaxed HR-style conversation. The interviewers are technical and they use your own examples to test whether you actually understand the tools, models, stacks, and decisions you mentioned. The coding rounds felt very LeetCode-style, and the low-level design was practical and object-oriented instead of broad architecture trade-offs. My overall feeling was that they care about fundamentals and communication more than trick questions.