Interview processes evolve over time, so treat this as one candidate’s experience rather than a definitive guide.
There are already hundreds of Amazon interview experiences online that list the questions they were asked, in order, with no context.
This isn’t one of those.
What I wanted to write about instead is something I wish I’d understood going in. Amazon wasn’t really testing whether I could remember an algorithm. It was testing whether I could explain the engineering decision behind it.
My background going in: CSE at DTU, where I’ve interned as an AI Engineer and as a Deep Learning Research Intern, alongside some competitive programming and CTF work on the side. If your background is a similar mix of DSA and applied research, some of this might be relevant. Take it as one intern’s experience, not a template.
There were two rounds, both technical, both roughly an hour. Quick result up front: I got the offer. Here’s the round-by-round breakdown.
Round 1
Self-intro
I opened with a short self-intro instead of walking through my resume line by line. Structured it loosely as BEAT: background, education, achievements, target role. Kept it under two minutes and let him pull threads from there rather than front-loading everything myself.
DSA: Daily Temperatures
The problem: given an array of temperatures, find how many days you’d have to wait for a warmer temperature, for each day.
I started with the brute-force O(n²) approach (for each day, scan forward until you hit something warmer), then moved to the optimized version using a monotonic decreasing stack. Wrote it out by hand on paper, dry-ran it against the interviewer’s test case, and it held up.
One area where I realized I could have explained my reasoning better: when he asked me to justify why a stack specifically is the right structure here, not just that it works, but why nothing simpler would, I couldn’t articulate it as cleanly as I’d coded it. In hindsight, the explanation is straightforward. The stack stores unresolved indices in decreasing order of temperature. Whenever a warmer temperature appears, it resolves all smaller temperatures that have been waiting for their next warmer day. Since each index is pushed and popped at most once, the overall complexity is O(n).
Something I took away from this: being able to code a solution and being able to justify the data structure choice out loud turned out to be two different skills for me. I clearly hadn’t practiced the second one as much as the first.
He followed up with a variant close to Next Greater Element II (circular array version), worth practicing the circular-array trick (iterating 2n times with modulo) alongside the base pattern.
Behavioral
One question, asked with real follow-through: What’s the toughest feedback you’ve received, what did you learn from it, and how have you made sure you don’t repeat it?
This wasn’t a “tell me a story” box-check. He wanted the actual mechanism: what changed in how I work afterward, not just that I “took it well.” Worth having a genuine answer ready here rather than a sanitized one.
He also asked why Amazon specifically. My answer: I wanted exposure to large-scale data and to see how things actually work in production, the kind of scale you don’t get to observe in a research setting.
Something that only became obvious in hindsight: both interviewers were clearly mapping my behavioral answers to Amazon’s Leadership Principles, not just judging whether the story was a good one. Knowing the 16 principles cold, and being able to name which one a given answer demonstrates, mattered more than I expected going in.
What I asked
What role does an intern actually play on a team here, and how much is exploratory versus shipping to production?
Given how fast the AI landscape is moving, what direction is Amazon taking internally?
Both led to real answers, not recruiting-brochure ones.
Round 2
This round was almost entirely a conversation about my research work, followed by GenAI-specific questions and one more problem-solving discussion. Unlike round 1, none of it involved writing code. The problem-solving portion stayed at the discussion level the whole way, with the interviewer working through several different test cases with me to see how I’d adjust my approach, more than to check whether I could produce a working implementation.
Project deep-dive
He asked for the hardest technical challenges I’d run into. I kept the specifics of the research itself light, since it’s still unpublished work, but walked through the shape of four problems:
Data-hungry architecture, limited data. The model I was using needed more training data than I had access to, so I synthesized additional data to close the gap rather than settling for an undertrained model.
Task-specific vs. general. Most prior approaches in this area optimize for one narrow downstream task. I was expected to produce something more general: a representation that transfers across tasks instead of being tightly coupled to one.
A pipeline bottleneck. A data-generation step that was originally happening inline, mid-training-loop, turned out to be the bottleneck. I decoupled it, precomputing and caching that data ahead of time instead of generating it on the fly.
Invariance to a nuisance variable. I wanted the model to represent the same underlying content the same way regardless of a specific condition that shouldn’t matter to the task, so I trained it to map both versions to the same point in feature space, rather than trying to normalize the input away first.
One thing that stood out: this round spent far more time on “why did you make this choice” than on the results themselves. I got the sense that knowing the numbers wasn’t quite enough on its own; it helped to also be ready to talk through alternatives and trade-offs.
He also asked how you’d generate a segmentation map when comparing a normal-light and a low-light version of the same scene. I walked through it at a high level: run segmentation on the clean, normal-light image to get ground-truth masks, then reuse those same masks on the synthetically darkened version, since the objects and their positions haven’t changed, only the lighting has.
GenAI / LLM questions
“Have you seen LLMs give you answers that weren’t what you expected? How would you fix that?”
I used a legal-reasoning example: a model trained predominantly on US legal text may confidently answer a question about Indian law incorrectly, because it doesn’t actually have grounding in that jurisdiction. Two fixes I discussed:
RAG: retrieve the relevant jurisdiction-specific documents and ground the answer in them, rather than relying on parametric memory.
Prompt engineering: few-shot examples to steer the model toward the right context and format.
“What legal and ethical considerations come up when working with LLMs?”
Two threads:
Safety and guardrails. Models, especially smaller ones, can still produce unsafe outputs (instructions for building weapons is the canonical example) if guardrails aren’t implemented properly at the model or system level.
Bias. Models can encode skewed preferences across demographic or ethnic groups if the training data itself is imbalanced, and that’s a harder problem than a single guardrail can fix.
“What is hallucination in LLMs, and how would you mitigate it?”
I said it’s a model stating something false as if it were fact, confidently enough that nothing about the delivery gives it away, usually when it’s pattern-matching past what it actually knows: thin context, multi-step reasoning, stale training data. For fixes, I pointed back to what I’d already said: ground it in retrieved documents instead of the model’s memory, and prompt it to reason step by step instead of guessing.
“What are guardrails, and why do they matter?”
I framed this as the flip side of the safety point: the limits that keep a model’s output safe and predictable enough to actually put in front of users. Less a compliance checkbox, more a trust problem. Nobody deploys a model into healthcare or finance if they can’t guess roughly what it’ll say.
Problem-solving: Rearrange String
The closest match on LeetCode is Reorganize String (LeetCode 767), same rule, same (n+1)/2 feasibility check, just a different name than the one he used in the room.
Rearrange a string so no two adjacent characters are equal, no coding required, just a live discussion.
I worked through it out loud. First, the feasibility check: no arrangement exists if any character’s frequency exceeds (n+1)/2. Then the approach: build a frequency map, load it into a max-heap, and greedily place the most frequent remaining character each step, holding back the just-placed character for one round so it isn’t placed twice in a row. We discussed time complexity (O(n log k) for k distinct characters) and space. We kept the discussion at the algorithm and trade-off level rather than writing code.
What I asked
Since this interviewer had about 18 years of experience, I used the last few minutes to learn something instead:
What scalability advice would you give an aspiring engineer, based on what you’ve seen over 18 years?
I also asked how interns can contribute beyond simply completing their assigned project.
A few things that stood out, looking back
Explaining the “why” out loud was harder than writing the code. Saying “I’ll use a stack” wasn’t really an answer on its own; the follow-up was always why it has to be that structure. That’s the part I’d rehearse more if I did this again.
The project discussion went deeper than I expected, and not just into the results. It was about the decisions behind them: why this architecture, what didn’t work, what the actual bottleneck was. Worth being ready to go a few layers past a resume summary.
For the GenAI questions, a concrete example landed better than a definition. Walking through one specific case (mine was a legal-reasoning example) felt more useful than reciting what RAG or few-shot prompting are.
The behavioral question wanted the mechanism, not just the story. “Toughest feedback plus what changed” only lands if the change is specific, not a general “I took it well.”
The questions I asked back mattered too. Both interviewers gave real answers when I asked real things: what an intern’s day-to-day actually looks like, and, for the 18-year veteran, what he’d tell a younger engineer about building at scale.
What I’d prepare differently if I interviewed again
If I had to do this again, I’d spend more time on:
Explaining why a data structure is the right choice, not just implementing it.
Going deeper into the engineering trade-offs behind every project on my resume, not just the results.
Practicing GenAI discussions through real-world examples rather than memorizing definitions.
Preparing STAR-style behavioral stories around a specific, concrete change I made, not a generic lesson.
Mapping each behavioral story to a specific Leadership Principle ahead of time, instead of figuring that out on the spot.
Hope this helps someone who’s preparing for an Amazon SDE internship. If you found it useful, feel free to like, share, or leave a comment - and if you have questions about anything I discussed, I’ll be happy to answer them.
Good luck with the prep!