Amazon SDE 1 Interview Experience

Finally, it’s time to write down my Amazon interview experience! Better late than never, right? 😅

It was quite a journey, from submitting an application just before joining another company to solving DSA problems with nothing but paper and pen, discussing GenAI, answering Leadership Principle questions, and eventually receiving the offer.

Here’s how it went.

1. The Application & Online Assessment

I submitted my application just before joining another company. It took around a month to receive the OA link.

This was my first OA for any MAANGMULA company, so naturally, there was a little excitement mixed with the usual “let’s see how badly this goes”

The process began with a coding assessment and a behavioral/work-simulation assessment. The experience reinforced the importance of strong DSA fundamentals, careful problem-solving, and sound workplace judgment.

My tips:

• Don't underestimate the behavioral and work-simulation assessment. It matters just as much as the DSA round.

• Since there is no strict time limit, take your time to understand each scenario and select the response that best reflects good judgment, ownership, and customer focus.

• Don't blindly choose the option that sounds the most impressive. Think about what you would actually do in a workplace.

Useful resource: Amazon OA & Leadership Principles preparation playlist

2. The Waiting Game

After completing the OA, I received the hiring interest form, and my interview was initially scheduled as an offline interview.

Then… silence.

No confirmation from the Amazon team regarding the scheduled interview.

After waiting for a week, I emailed them to check the status of my application. They replied that the interview had been rescheduled for a later date.

Moral of the story: following up politely is perfectly fine. Don't assume that silence automatically means rejection, and don't hesitate to ask for clarification.

There was a pre-interview meeting where the team explained the interview process, schedule, role details, and what to expect.

One interesting development: I learned that a GenAI Fluency round had been added just a day before the interview.

Surprise round unlocked. 🎮

3. The Interview Day — Four Rounds

The original interview day ran from around 9 AM to 4 PM. Each round was scheduled for approximately one hour, with 15-minute breaks between rounds.

We were told that a laptop, screen, or paper would be available for coding. In my case, it was just paper and pen.

So, if you're preparing for interviews, don't assume that you'll always have an IDE, autocomplete, or the luxury of running your code.

Round 1: DSA + Leadership Principles

Problems:

1. Stack-based problem — Easy

2. Dynamic programming — Medium–Hard

I completed both problems in under 45 minutes.

After the coding section, we moved on to Leadership Principle questions. I'll cover how I prepared for these later in the post.

My tips:

• Write the code before jumping into a long explanation of your entire approach. First establish a clear solution, then walk the interviewer through it.

• Dry-run your code with a small example.

• Use meaningful variable names. Your interviewer shouldn't have to solve a naming puzzle while evaluating your algorithm.

• Explain time and space complexity, including the complexity of important operations.

• State assumptions and edge cases explicitly.

• If you get stuck, communicate your reasoning rather than sitting silently.

Remember, the interviewer is evaluating how you solve problems, not just whether you can produce code.

Round 2: Maintainable Coding

This round included one DSA problem involving grid traversal, which I found Medium–Hard.

I completed the coding question in around 30 minutes.

The remaining time was spent on Leadership Principle questions and resume discussion.

The resume discussion went deep into my projects. I was asked:

• What exactly did I build?

• Why did I choose that particular approach?

• What alternatives did I consider?

• What trade-offs did my implementation introduce?

• What was my individual contribution?

My biggest takeaway: Don't put anything on your resume that you cannot defend technically.

If you mention a project, be ready to explain its architecture, design decisions, implementation details, challenges, and alternatives. Saying “I used X because it is better” isn't enough. Explain why it was better for that particular problem.

Also, maintainable code is more than code that works. Think about readability, modularity, edge cases, naming, and how another engineer would extend your solution.

Round 3: GenAI Fluency

This round lasted approximately 45 minutes.

The discussion focused on recent developments in GenAI, how to leverage it effectively, and my own GenAI projects.

Since I had worked on GenAI projects, we went deeper into those as well. There were also puzzles and coding-related questions.

The important thing here was understanding the concepts rather than simply knowing the names of popular models and tools.

Prepare to discuss topics such as:

• LLM fundamentals and limitations

• Prompt engineering and structured outputs

• RAG and vector search

• Embeddings and semantic similarity

• Tool calling and agentic workflows

• Model evaluation, hallucinations, latency, and cost

• Privacy, security, and responsible use of AI

• Why you chose a particular model or architecture for your project

You don't need to pretend to know every new development in AI. Be clear about what you've actually built, what you've experimented with, and what you understand conceptually.

A useful preparation strategy: For every GenAI project on your resume, be ready to explain the problem, architecture, data flow, design alternatives, evaluation strategy, limitations, and what you would improve next.

The Unexpected Ending

By around 4:30 PM, the fourth round was postponed to a later date.

And just like that, the interview day was over without completing all four rounds.

The fourth round was subsequently scheduled for a later date and conducted online.

Round 4: Leadership Principles

This round was almost entirely focused on Amazon's Leadership Principles.

It lasted around 45 minutes, with approximately four to five main questions and follow-ups.

The interviewer wanted to understand my experiences, decisions, actions, and reasoning.

The follow-up questions matter a lot. A good initial answer is only the beginning; you need to be able to explain the details behind it.

Three days later…

I received the offer! 🎉

All the waiting, preparation, rescheduling, coding, and storytelling finally paid off.

4. Technical Preparation:

Won’t be sharing the exact questions due to confidentiality but let’s go thru an example question. LeetCode 1671 — Minimum Number of Removals to Make Mountain Array

Problem in simple terms

Given an array, remove the minimum number of elements so that the remaining elements form a mountain array.

A mountain array must have:

• A strictly increasing sequence before the peak.

• A strictly decreasing sequence after the peak.

• At least one element on each side of the peak.

For example:

[2, 1, 1, 5, 6, 2, 3, 1]

One valid mountain subsequence is:

[1, 5, 6, 3, 1]

Its length is 5, so the number of removals is 8 - 5 = 3.

The core idea

We want to find the longest mountain subsequence.

For each index i, calculate:

• lis[i]: the length of the longest strictly increasing subsequence ending at index i.

• lds[i]: the length of the longest strictly decreasing subsequence starting at index i.

An index can be the peak only if both values are greater than 1.

The longest mountain with peak i has length:

lis[i] + lds[i] - 1

We subtract 1 because the peak is counted in both subsequences.

Therefore:

answer = n - max(mountainLength[i])

The straightforward LIS solution uses O(n²) time. We can optimize each directional calculation to O(n log n) using binary search.

How to calculate LIS in O(n log n)

Maintain an array called tails, where tails[k] is the smallest possible ending value of an increasing subsequence of length k + 1.

For each number:

1. Binary-search for the first element in tails that is greater than or equal to the current number.

2. Replace that element, or append if no such element exists.

3. The position plus one gives the LIS length ending at that index.

For a strictly increasing subsequence, use lower bound — the first value greater than or equal to the current value.

To calculate decreasing subsequences starting at each index, process the original array from right to left using the same approach.

Dry run

Consider this array:

[2, 1, 1, 5, 6, 2, 3, 1]

The best peak is the value 6 at index 4.

• Longest increasing subsequence ending at 6: [1, 5, 6]

• Longest decreasing subsequence starting at 6: [6, 3, 1]

Combining them without duplicating the peak:

[1, 5, 6, 3, 1]

Original length = 8.

Longest mountain subsequence length = 5.

Minimum removals = 8 - 5 = 3.

Follow-up: Can you print the actual mountain subsequence?

Computing just the lengths isn't enough. To reconstruct the sequence, store the predecessor and successor indices.

For the increasing side:

• Maintain tailsIndex, storing the index of the element ending each subsequence length.

• Store parent[i], the previous element's index in the increasing subsequence ending at i.

• When replacing a tailsIndex entry, update the parent pointer accordingly.

For the decreasing side:

• Process the array from right to left.

• Store next[i], the index of the next element in the decreasing subsequence starting at i.

Once the best peak is identified:

1. Follow parent pointers from the peak backwards to reconstruct the increasing side.

2. Reverse that list.

3. Follow next pointers from the peak's successor to reconstruct the decreasing side.

4. Concatenate both sides, including the peak only once.

The resulting list gives you the actual mountain subsequence, not just its length.

Important distinction: tails alone does not necessarily contain the final LIS. It stores optimal tail candidates. To reconstruct an actual sequence, you need predecessor pointers or another reconstruction strategy.

Interview tip: Explain the length-only solution first, establish the O(n log n) complexity, and then introduce parent pointers for reconstruction. This demonstrates that you understand both the optimization and how to recover the result.

5. Amazon Leadership Principles (LPs): How I Prepared

Amazon's Leadership Principles are not something I'd recommend preparing for at the last minute.

Official reference: Amazon Leadership Principles

Another useful resource:

Leadership Principles interview preparation — YouTube

My approach

I created around 5–6 stories from my actual projects and experience, making sure each story could demonstrate multiple Leadership Principles where appropriate.

This helped me avoid memorizing a separate story for every principle.

For example, a genuine project challenge might demonstrate Ownership, Dive Deep, and Deliver Results at the same time. Another experience involving a disagreement could demonstrate Have Backbone; Disagree and Commit, alongside Earn Trust.

The key is that the story must genuinely support the principles you're claiming.

Don't manufacture stories to fit the principles. Interviewers ask follow-up questions, and invented experiences are difficult to defend consistently.

The STAR method

STAR stands for:

• S — Situation: What was happening? Give enough context to understand the problem.

• T — Task: What were you responsible for achieving?

• A — Action: What did you do? Explain your decisions, reasoning, and alternatives.

• R — Result: What happened? Quantify the impact if you have real numbers, and explain what you learned.

Example STAR structure

The following is an illustrative template, not a claim about my own experience. Replace the details with something that genuinely happened to you.

Question: Tell me about a time you took ownership of a difficult problem.

Situation: A project I was working on had a recurring reliability issue that affected its users.

Task: I was responsible for identifying the root cause and helping deliver a stable solution.

Action: I reproduced the issue, examined logs and failure patterns, narrowed down the root cause, evaluated possible fixes, and implemented the solution. I also added tests to reduce the likelihood of regression and communicated progress to the relevant teammates.

Result: The fix resolved the identified issue, and the additional tests improved confidence in subsequent changes. If I had measured the impact, I would include the actual reduction in failures or support requests here.

Notice that the Action section contains most of the technical and behavioral detail. That's usually where the follow-up questions will focus.

Prepare for follow-ups

After every story, ask yourself:

• Why did you choose that approach?

• What alternatives did you consider?

• What was the hardest part?

• What did you personally contribute?

• How did you handle disagreement?

• What would you do differently today?

• How did you measure success?

• What did you learn from the experience?

Be precise about your own contribution versus what the team accomplished. Use actual metrics where available, and never invent numbers just to make a story sound impressive.

My biggest LP tip: Prepare stories, not scripts. Know the details well enough to answer naturally, even when the interviewer takes the conversation in an unexpected.

1. DSA Preparation — What I'd Focus On

6. DSA Preparation — What I'd Focus On

If I had to prepare for these interviews again, I'd mostly focus on the following topics. You don't need to solve every problem on LeetCode. Get your fundamentals right, solve enough problems to recognize patterns, and spend extra time on the topics where you struggle.

Topics to focus on

• Hashing — Frequency maps, HashMap/HashSet, prefix sums, and using hashing to optimize brute-force solutions.

• Sorting — Custom comparators, sorting-based optimizations, intervals, and problems where sorting simplifies the logic.

• Graphs — Use Striver's sheet as a starting point, then move on to Medium–Hard problems. Focus on BFS, DFS, topological sorting, shortest paths, DSU, and recognizing which algorithm fits the problem.

• Greedy — Start with the Top 300 questions linked below. Once you identify the patterns, solve similar problems, especially in the areas where you struggle.

• Dynamic Programming — Follow Vivek Gupta's DP framework or Striver's DP series. Don't stop at memorizing the recurrence; try to understand the state transition and space-optimize your solutions wherever possible.

• Binary Search — Focus on minimum/maximum answer problems, lower bound, upper bound, and binary search on the answer.

• Monotonic Stacks — Next greater/smaller elements, stock span, histogram problems, and similar patterns.

These are the topics I'd prioritize based on my interview experience. This isn't an exhaustive list, but it's a good starting point.

Resources

1. Striver's A2Z DSA Sheet — A good starting point for building fundamentals and covering the major DSA topics.

2. Top 300 Most Asked DSA Questions — Useful for targeted interview practice, especially greedy and commonly recurring patterns.

3. TLE Eliminators CP Sheet — Another resource for structured problem-solving practice.

4. USACO Guide — Useful if you want to explore competitive programming concepts in more depth.

5. CP-Algorithms — Good for deeper explanations of algorithms and techniques. Not necessary for everyone, but worth exploring if you want to understand the theory behind them.

How I'd use these resources

Don't try to complete every sheet simultaneously. Pick one primary resource, solve problems consistently, and use the others when you need more practice or a different explanation.

For every problem you solve, make sure you can explain:

• The brute-force approach and its complexity.

• Why it can be optimized.

• The optimal approach and its time and space complexity.

• Edge cases and a proper dry run.

• Whether the solution can be further optimized.

And when you get a problem wrong, revisit it after some time instead of immediately moving on. Recognizing patterns is what makes the difference.

7. Additional Preparation Resources

A few useful links to keep handy:

1. Amazon Leadership Principles — Read the official principles and prepare real examples from your experience.

2. Amazon Interview Preparation — Official interview guidance.

3. Amazon OA Preparation Playlist — Useful for OA preparation.

4. Leadership Principles & STAR Preparation — Helpful for structuring behavioral answers.

For GenAI-related rounds, focus on understanding the projects you've built and the trade-offs behind your design decisions rather than just memorizing terminology.

8. Final Takeaways

Looking back, these are the things I'd emphasize to anyone preparing for a similar interview:

• Take the OA seriously. Both coding and work simulation matter.

• Practise coding without an IDE. Paper-and-pen coding is a real possibility.

• Focus on DSA patterns. Hashing, sorting, graphs, greedy, DP, binary search, and monotonic stacks would be my priorities.

• Explain your solutions clearly. Include dry runs, edge cases, and complexity analysis.

• Know your resume inside out. Every project is an invitation to go deeper.

• Prepare genuine STAR stories. Five or six strong stories can cover multiple Leadership Principles.

• Don't neglect GenAI fundamentals if the role includes AI fluency or related responsibilities.

• Follow up professionally when interview scheduling or communication is unclear.

• Stay adaptable. Interview schedules can change, and additional rounds may appear.

• Don't give up just because the process takes longer than expected.

And finally, a reminder to myself: the next time I write an interview experience, hopefully I'll do it before I forget half the details. 😅

All the best to everyone preparing. Keep learning, keep practising, and be honest about what you know and what you've built.

P.S. Used AI to help write this in a better way. Because why not? 😄