Amazon SDE New Grad Interview Experience — Rejected After 4 Rounds

Hi Leetcoders,

Just wanted to share my recent Amazon SDE New Grad interview experience and how each interview went. Unfortunately, I received a rejection after completing all four rounds.

I still have mixed feelings about the whole experience because some of the coding questions weren't particularly difficult, but stress definitely got to me at certain points. Hopefully this is useful for anyone preparing for a similar loop.

Interview #1 — LP + DSA/OOP

Classic start - around 10–15 minutes discussing Leadership Principles. I can't remember the exact questions anymore, but I felt this part went reasonably well.

Then came the technical part.

Imagine you have a train route:

G → U → H → K → I

Each segment travelled costs 1. So travelling from G to I would cost 4.

The input was basically:

calculateFare(start, stop)

I initially thought this was just a simple DSA problem. I assumed I already had an array containing the stops and quickly implemented a function based on that assumption.

I made a couple of stupid mistakes while coding - for example, accidentally using j instead of i, and I also had an incorrect return value for one of the edge cases.

But those weren't really the main problem.

The interviewer then asked me something along the lines of:

"Where are you getting this array from?"

That's when I realized my assumption wasn't necessarily correct and that there was more of an OOP/LLD aspect to the question.

I started implementing a simple class and showed how stops could be added/pushed into the route. At that point, though, my solution had become pretty messy because I was trying to adjust what I'd already written while figuring out what exactly the interviewer wanted.

The interviewer eventually redirected me back to the fare-calculation function.

There was also a second requirement: on weekends, the total fare should be capped at a certain maximum amount.

I was able to implement this additional requirement successfully.

Looking back, the biggest mistake wasn't the typo or even the inefficient initial solution. It was that I didn't recognize early enough that the interviewer wanted me to think about the design/model rather than simply treating it as a small DSA question.

This was definitely my weakest round.

Interview #2 — DSA + GenAI

This round went much better.

I won't go too deeply into the exact question, but it was a string/substring-style coding problem.

I came up with the algorithm myself and implemented it without needing help with the actual approach. I also walked through the solution with a dry run, and the interviewer seemed satisfied with it.

Then the interviewer asked me to write some tests.

Initially I misunderstood what they meant by "write tests" and started overthinking it. They clarified with a simple example similar to:

function test() {
    input1 = "aaa";
    output1 = "a";
}

After that, I understood and created several test cases, including empty strings and other edge cases.

Apart from those small issues, I felt very good about the actual algorithm and implementation.

The second part of this interview involved GenAI-related questions, which I also felt went well.

Overall, this was probably my strongest round.

Interview #3 — Leadership Principles / Behavioral

This interview was entirely behavioral.

There were quite a few follow-up questions, and I probably overexplained some of my answers. Once I got into a story, I sometimes gave more context than was actually necessary.

Some answers felt strong, while others I wasn't as happy with.

One question was around dealing with a difficult teammate / making a difficult decision.

Overall, I felt this round was decent. Some stories landed better than others, but I didn't come out feeling like it had gone badly.

Interview #4 — LP + DSA

This round started with another behavioral question.

I was asked about a time when I had to overcome something in order to reach an important goal.

Then came the coding problem.

I was asked to implement something similar to:

SlidingWindow(k)
put(number)
getMax()

getMax() should return the maximum value among the last k elements.

For example, if k = 3, it should return the maximum of the three most recently inserted values.

My initial implementation stored everything in an array:

class SlidingWindow {
    constructor(k) {
        this.k = k;
        this.array = [];
    }
put(num) {
    this.array.push(num);
}

getMax() {
    // iterate over the last k elements and return the maximum
}

}

So my complexities were roughly:

• put() → amortized O(1)
• getMax() → O(k)
• Space → O(n) because I was storing every value ever inserted.

The interviewer then asked how I could reduce the space complexity.

I explained that there was no reason to keep elements that had already fallen outside the window, so I could maintain only the last k elements and remove the oldest one as new elements were inserted.

That would reduce the space to O(k).

We then had a longer discussion about different data structures and their trade‑offs. We talked about things like arrays, hash maps, linked lists/doubly linked lists and heaps, and discussed the corresponding time/space implications.

I didn't arrive at the optimal monotonic deque solution during the interview, which would allow the maximum to be maintained much more efficiently.

Still, I had a working baseline solution, knew its complexity, identified how to reduce the memory usage, and was able to discuss alternative approaches with the interviewer.

I came out of this round feeling reasonably good.

Result

Unfortunately, I received a rejection after completing the four interviews.