How I Got Selected for Amazon as an SDE Intern: My Complete Interview Experience
Getting an interview opportunity at Amazon is exciting. Getting through the entire process and finally receiving an offer is a different feeling altogether.
In 2026, I went through Amazon’s Software Development Engineer Intern hiring process in India. It started with an online assessment, followed by two technical interview rounds, and eventually ended with an offer for a six-month internship starting in January 2027.
The process was interesting because it wasn’t limited to solving traditional Data Structures and Algorithms problems. The online assessment also included a repository-based coding task, and the interview rounds tested much more than just whether I could arrive at the correct answer.
In this article, I’m sharing my experience from beginning to end, the online assessment, the questions and tasks I encountered, how the interview rounds unfolded, and the lessons I took away from the process.
I’ll try to keep this as honest and detailed as possible. This isn’t a preparation checklist disguised as an interview experience. It’s an account of what actually happened in my case. Your experience may be different, but I hope this gives future applicants a clearer picture of what the journey can look like.
Let’s start from the beginning.
1. The Online Assessment: The First Step
On August 5, 2026, I got to know that Amazon, through its career portals, is hiring for the SDE Intern role. I went ahead to apply to it the same. The moment the application was filled, I got the online assessment details, which had to be completed within one week. At first glance, it looked like a fairly standard online coding assessment, but going through the instructions made it clear that there was more to it than just solving DSA questions. I gave the OA the same day.
The assessment consisted of three components:
- Coding Challenge: 100 minutes
- Work Simulation: typically 45 minutes
- Work Style Survey: approximately 6 minutes
The instructions recommended keeping around 2.5 hours available and completing the assessment in a quiet environment with a stable internet connection. What I found particularly interesting was the variety of skills these three sections were designed to evaluate.
The 100-minute Coding Challenge
This was the most technically intensive part of the assessment. It consisted of two distinct tasks:
- A traditional Data Structures and Algorithms problem: This required understanding the problem statement, identifying the underlying pattern, and developing an efficient solution.
- A repository-based coding task: Instead of solving another standalone programming problem, I was given an existing code repository and had to work within that codebase using an AI coding assistant.
The second task was quite different from the coding assessments I had previously encountered. It involved understanding an existing application, identifying the required changes, and working with an actual codebase rather than simply writing a function from scratch.
I’ll cover both tasks separately because they tested two quite different aspects of software engineering.
The Work Simulation: Thinking Beyond Code
The next component was the Work Simulation, which focused on how candidates approach situations they might encounter in a professional software engineering environment.
Rather than testing programming knowledge, this section presented workplace scenarios and asked candidates to evaluate different possible courses of action.
For instance, imagine a situation where a teammate wants to push a code change before a deadline but hasn’t completed the necessary testing. Would you prioritise meeting the deadline, ask someone else to review it, or actively help resolve the testing gap?
Questions like these are designed to evaluate how you approach collaboration, ownership, decision-making, prioritisation, and software quality.
This is where Amazon’s Leadership Principles become particularly relevant. Principles such as Ownership, Customer Obsession, Bias for Action, Dive Deep, and Insist on the Highest Standards provide useful context for understanding the kind of professional judgement being evaluated.
The important thing to understand is that this isn’t a technical coding round in disguise. It is about how you think, how you respond to situations involving other people, and how you balance competing priorities while making decisions.
The Work Style Survey: Understanding Your Working Preferences
The final component was the Work Style Survey.
Unlike the Work Simulation, this section focused more directly on your individual working preferences and behavioural tendencies.
The questions generally presented pairs of statements and asked candidates to indicate which statement described them better, using a five-point scale to indicate which statement felt more like them.
Some statements could be relatively straightforward, while others involved choosing between two seemingly positive qualities.
For example, one statement might emphasise checking your work carefully, while another might emphasise exploring new perspectives and generating ideas. Both are valuable qualities, but the exercise asks you to indicate your natural preference.
This makes the section a little different from a conventional multiple-choice questionnaire. It is less about finding a technically correct answer and more about understanding your approach to work.
Consistency and authenticity matter here. Trying to construct an artificial personality around what you think a company wants to hear may not be the best approach. It is more useful to understand the behavioural qualities being explored and respond thoughtfully.
Overall, the OA was broader than a conventional DSA-based screening round. It evaluated technical problem-solving, the ability to work with an existing codebase, workplace judgement, and individual working preferences.
With the overall structure out of the way, let’s get to the part most candidates are probably curious about: the actual coding challenge.
The DSA Problem:
The first task in the coding challenge was a traditional DSA problem.
We were given an array of integers representing values at different positions. The objective was to make all elements equal using a defined operation, while minimising the total cost.
The operation involved choosing an existing element and using its value to update positions on either side. The cost depended on the chosen value and the number of positions being updated.
At first, the problem statement might make you think about trying different operations and simulating how the array changes. However, I wanted to avoid exploring every possible sequence of operations and instead look for a pattern that could lead to an efficient solution.
Understanding the Key Observation
The important observation was that we could think about the final value first.
Suppose we decide that every element in the array should eventually become some value x.
If the array already contains a contiguous block of x, that block can serve as the portion we preserve. The remaining positions need to be updated to x. Now, consider what happens if there are multiple separate blocks containing x.
It makes sense to preserve the longest contiguous block because doing so minimises the number of positions that need to be changed.
Let:
nbe the size of the array.xbe a possible final value.L(x)be the length of the longest contiguous block containingx.
The number of positions that need to be updated is:
n − L(x)
Therefore, the cost for choosing x as the final value becomes:
Cost(x) = x · (n − L(x))
We can calculate this for every possible final value present in the array and take the minimum.
In other words:
Answer = minₓ (x · (n − L(x)))
This transforms the problem from exploring sequences of operations into finding the longest contiguous block for each value.
My Approach
I used a simple linear traversal of the array.
The idea was to identify contiguous groups of equal elements and maintain the maximum length encountered for each value.
For example, consider: arr = [2, 2, 3, 3, 3, 2, 1]
The contiguous groups are:
- Value
2: longest block of length2 - Value
3: longest block of length3 - Value
1: longest block of length1
For each value, we calculate the cost of making the entire array equal to that value while preserving its longest existing block.
Finally, we return the minimum cost.
C++ Implementation
Here is the approach I used:
long getMinCost(vector<int> arr) {
int n = (int)arr.size();
vector<int> best(n + 1, 0);
int i = 0;
while (i < n){
int j = i;
while (j < n && arr[j] == arr[i])
j++;
best[arr[i]] = max(best[arr[i]], j - i);
i = j;
}
long long ans = LLONG_MAX;
for (int val = 1; val <= n; val++) {
if (best[val] > 0) {
long long cost = 1LL * val * (n - best[val]);
ans = min(ans, cost);
}
}
return (long)ans;
}
Complexity Analysis
The solution requires two linear traversals:
The first traversal identifies contiguous groups and records the longest group for each value. The second traversal calculates the cost associated with each possible final value and finds the minimum.
Therefore:
- Time Complexity: O(n)
- Space Complexity: O(n), for the auxiliary
bestarray.
The key was to preserve the longest contiguous block and minimise the cost of changing the rest. That was the first coding task of the assessment.
The next one was quite different. Instead of solving a standalone algorithmic problem, I had to work with an existing software project, a Movie Database application with a faulty watchlist implementation.
Moving Beyond Traditional DSA
For the second task, instead of giving us another standalone programming problem, the assessment provided an existing Movie Database application with a backend implementation that needed debugging and improvement.
The task revolved around a user watchlist feature. The application already had the relevant functionality, but certain backend operations weren’t behaving as expected.
The objective wasn’t to build an application from scratch. It was to understand the existing codebase, identify the issues, and make the required changes while working within the repository. We were given the option to choose our preferred backend language. I chose Node.js, while other available options included Python, C# and C++.
Understanding the Requirements
The task primarily focused on getting the watchlist functionality to work correctly.
There were a few important requirements:
- Adding movies: A logged-in user should be able to add a movie to their watchlist, with the change persisted in the backend.
- Removing movies: Users should be able to remove movies directly from their watchlist.
- Toggle functionality: The movie details page should also allow users to add or remove a movie depending on whether it is already in their watchlist.
- Rate limiting: The application needed to enforce a limit of 10 add/remove operations per user within a rolling two-minute window.
The rate-limiting requirement was particularly interesting because it wasn’t simply about restricting the number of API requests globally. The limit had to be maintained separately for each user, and both additions and removals counted towards it.
Working with an Existing Codebase
I first needed to understand the existing codebase, its frontend-backend flow, and how the watchlist functionality was implemented before making changes. The task involved working across different backend responsibilities, including controllers, routes, and middleware.
Get Dhruv Goyal’s stories in your inbox
Join Medium for free to get updates from this writer.
This made it important to think beyond whether an individual function worked. The complete flow had to behave correctly, from the user’s action on the frontend to the corresponding backend operation and the persisted result.
The Role of the AI Coding Assistant
Another interesting aspect was the environment itself. We were working with an AI coding assistant inside an existing repository. Understanding the requirements, navigating the codebase, identifying the relevant files, and validating the changes were all important parts of the exercise.
The experience reinforced something I find increasingly relevant in software engineering: being able to work effectively with existing systems is just as important as being able to write code independently.
What This Task Tested
Looking back, this task brought together several practical engineering skills:
- Understanding an unfamiliar codebase.
- Debugging existing backend functionality.
- Working with API routes, controllers, and middleware.
- Handling user-specific operations and rate limiting.
- Thinking about persistence and consistency across frontend and backend interactions.
- Using an AI coding assistant as part of an actual development workflow.
With both coding tasks complete, the remaining parts of the online assessment were the Work Simulation and Work Style Survey, which tested an entirely different set of skills.
From the OA to the Interviews
After completing the online assessment, I cleared the screening stage and received an invitation to interview with Amazon. The interviews were initially expected to take place on August 27 and 28, but the schedule was subsequently changed. I received the updated Round 1 confirmation on September 4, with the interview scheduled for September 8, 2026, from 4:00 PM to 5:00 PM IST. It was a virtual interview, and this was my first opportunity to interact directly with Amazon’s engineering team as part of the hiring process.
Round 1: The Technical Interview
I joined the Zoom meeting at the scheduled time, but the interviewer requested to begin at 4:30 PM instead. I agreed, although the additional wait naturally made me a little more anxious.
The interview was eventually conducted by an Amazon SDE II. There was also another Amazonian silently shadowing the session for learning purposes; this person was not involved in the hiring decision.
After the introductions, we moved straight into the technical discussion.
The DSA Questions
The first problem was graph-based.
I was given a collection of file-format converters. Each converter represented a directed transformation from one format to another. Given two formats, the objective was to determine whether one could be converted into the other, either directly or through a sequence of intermediate conversions.
I initially discussed a brute-force approach and then moved towards graph traversal. We explored both BFS and DFS, and I was asked to implement the traversals, explain their time and space complexities, and dry-run the solution against different test cases. The interviewer also brought up edge cases, including the situation where the source and destination formats were already identical, and few more.
The second question was more conceptual. I was asked why Dijkstra’s algorithm produces an optimal shortest-path solution under its assumptions. We discussed why Dijkstra’s algorithm is greedy: at each step, the min-heap extracts the vertex with the smallest tentative distance from the source, allowing its shortest distance to be finalised under the algorithm’s non-negative edge-weight assumption.
The third problem involved a binary tree. The objective was to populate the next-right pointers for nodes at the same level, similar to LeetCode 116: Populating Next Right Pointers in Each Node.
Having encountered this problem before, I recognised that level-order traversal was a natural approach. I explained the algorithm, walked through the logic, and discussed its complexity.
Overall, the technical portion was heavily focused on data structures, particularly graphs and trees.
The Leadership Principles Discussion
After the technical questions, the interviewer moved to behavioural questions.
I had prepared several STAR-based stories beforehand, but the question I received was particularly interesting. I was asked to describe a situation during an internship or project where an issue affected customers, how were they getting affected, what I did to resolve it, and what the eventual outcome was.
I discussed an experience from my previous internship where inefficient and repetitive database requests were affecting server performance, particularly around a leaderboard feature.
I explained how I approached the problem using Redis and pagination to improve the system’s efficiency.
What followed was an extensive discussion. The interviewer went beyond the surface-level explanation and asked detailed follow-up questions about Redis, how it works in practice, and the underlying concepts behind the solution. We also discussed caching strategies, eviction policies such as LRU and LFU, and database-related considerations. We also discussed PostgreSQL’s locking and concurrency mechanisms, along with how Redis is not just a caching layer but can also function as a database.
This discussion alone took approximately ten minutes because of the continuous follow-up questions.
One thing I took away from this experience was that explaining a technology on your resume is very different from actually understanding it. Be prepared to defend the decisions you’ve made, explain the trade-offs, and discuss how your implementation works beyond the code itself.
Wrapping Up Round 1
Towards the end, the interviewer gave me an opportunity to ask questions. I asked about his professional experience, life at Amazon, and what he would recommend to someone joining the organisation as an intern. He was friendly and approachable throughout this discussion.
The interview eventually concluded, and I left the meeting feeling reasonably confident about how things had gone.
The result arrived on September 10, around 8:30 PM, telling me that I had cleared Round 1. The next round was scheduled for September 14 at 11:00 AM IST.
Round 2: Algorithms, Problem-Solving & GenAI
Unlike the first round, there was no shadow interviewer this time. The interview was conducted by a senior Amazon engineer, and the overall environment felt considerably more structured and strict.
One thing I particularly noticed was the emphasis on doing everything within the shared LiveCode environment. Even the dry runs and explanations had to be demonstrated there, rather than relying on pen and paper. As a BTech student, I was accustomed to practising on platforms where test cases are visible, code can be executed, errors can be identified, and solutions can be modified accordingly. LiveCode was a completely new experience for me. There were no visible test cases or execution feedback; the entire exercise revolved around writing the code, explaining the logic, and continuously interacting with the interviewer.
The DSA Questions
The first problem was based on arrays and the Majority Element problem, famously known as LeetCode 169.
The expected optimal approach involved the Boyer–Moore Voting Algorithm. I had encountered this algorithm before, so I was familiar with the underlying intuition.
However, the discussion wasn’t limited to writing the algorithm. I was asked to explain why it works, how it maintains a potential majority candidate, and how the approach would need to change if the existence of a majority element were not guaranteed.
The second problem involved zero-sum subarrays. I started with the brute-force approach and then discussed an optimised solution using prefix sums and an unordered set. The key observation was that if the same prefix sum occurs at two different indices, the elements between those indices sum to zero.
The interviewer tested the implementation against different arrays and edge cases, with particular emphasis on whether the solution would work beyond the obvious examples.
Both problems were familiar DSA patterns, but the depth of questioning made the round more challenging than simply recognising a known LeetCode problem.
The Generative AI Discussion
Once the DSA portion was complete, we moved to Generative AI Fluency, which was another area explicitly mentioned in the interview process.
The discussion covered concepts such as: Hallucinations, Guardrails, Human-in-the-loop systems (when an AI system should involve human intervention instead of making decisions autonomously), and Transformers (some fundamental concepts behind the architecture).
There was also a scenario-based discussion around deciding when human feedback or intervention becomes necessary in an AI-powered system.
Compared with the DSA portion, this discussion focused more on conceptual understanding and practical judgement than on implementation.
Wrapping Up Round 2
Towards the end, I was given the opportunity to ask questions, which I did. The conversation became more comfortable, and I also mentioned that the initial strictness had made me nervous.
Looking back, I consider this the more challenging of the two interviews, particularly because of the structured environment and continuous testing of my reasoning.
The interview eventually concluded, and I was left with a rather mixed feeling. Round 1 had gone quite well, so I was reasonably confident after it. Round 2, however, was harder to evaluate from my perspective.
The Longest 14 Days
After completing Round 2 on September 14, I entered what turned out to be one of the most difficult waiting periods I had experienced.
Initially, I expected to hear back within a few days. Amazon’s candidate communication mentioned that interview feedback could take some time, but as the days passed without an update, the uncertainty started getting to me.
I tried reaching out to the recruiters, but there was no concrete update. Every passing day made it harder to stay optimistic, especially when I had no idea whether the decision had been made or whether the process was still ongoing.
It also started affecting my ability to focus on other things. Campus placement assessments were taking place, but I found it difficult to concentrate on them while constantly wondering about the Amazon result.
I had genuinely given both interviews everything I could. All that was left was to wait.
September 28, 2026: The Email
I still remember that Monday morning.
On September 28, 2026, I woke up and casually checked my phone notifications. Among them was an email from Amazon.
I opened it and found the update I had been waiting for: I had cleared Round 2. I had been selected for the Software Development Engineer Intern role at Amazon for a six-month internship beginning in January 2027.
After fourteen days of uncertainty, the entire journey had finally reached the outcome I had hoped for.
It was difficult to put that feeling into words. An opportunity that had started with an online assessment in August had now turned into a confirmed selection. The formal offer details followed later.
And just like that, the waiting was over. ✨
A Few Things I’d Recommend to Anyone Preparing for Amazon
Looking back at the entire process, there are a few things I’d genuinely recommend to anyone preparing for an SDE interview at Amazon.
1. Don’t underestimate DSA.
Despite all the conversations around AI replacing traditional software engineering interviews, Data Structures and Algorithms remain extremely important. My own experience involved graphs, trees, arrays, greedy algorithms, and prefix sums.
Focus on understanding standard patterns rather than just memorising solutions. Practise graphs, linked lists, dynamic programming, binary trees, heaps, and commonly used algorithms. More importantly, develop the ability to explain your approach, optimise it, analyse complexity, and handle edge cases.
2. Know your projects beyond what’s written on your resume.
Anything you mention on your resume is fair ground for discussion. Be prepared to explain the technologies you used, why you chose them, what problems they solved, and the trade-offs involved. After all as they say, building something is one thing, but being able to defend your technical decisions is another.
3. Understand Amazon’s Leadership Principles.
Don’t treat behavioural questions as something you can prepare for at the last minute. Go through the Leadership Principles and prepare genuine experiences using the STAR approach.
Your answers should demonstrate ownership, problem-solving, customer focus, and the ability to learn from challenges. Authenticity and consistency matter.
4. Keep learning beyond DSA.
Build projects, explore technologies that genuinely interest you, and strengthen your computer science fundamentals. My interviews also involved discussions around databases, caching, Redis, and Generative AI.
You don’t need to know everything, but having curiosity and being able to reason about the technologies you work with makes a difference.
5. Be confident, especially when you don’t immediately know the answer.
An interview isn’t always about producing an instant solution. Take time to understand the problem, communicate your thinking, ask relevant questions, and be open to feedback.
You don’t need to be a perfect candidate. You need to demonstrate that you can think, learn, and improve.
A Final Note
This entire journey taught me that opportunities like these rarely come down to one particular question or one perfect interview.
There have been several rejections along the way, honestly, too many to count, and each of them made it harder to keep my morale up. But finding a way to keep going, even during the toughest times, is what truly matters. There were moments when I was confident, moments when I was nervous, and two weeks when I genuinely had no idea what the outcome would be.
But I’m glad I kept going.
To everyone preparing for an internship or full-time opportunity, especially those who are still in college: stay curious, keep working on your fundamentals, build things you enjoy, and don’t lose faith in yourself.
Have patience with the process. You might not see the results immediately, but the effort you put into learning and improving will stay with you regardless of the outcome.
Keep learning, keep building, and make the most of every opportunity that comes your way.
All the best! 🚀
