Amazon SDE II Interview Experience (Bangalore, Selected) ~ Aug 2026

Heyaaa! 👋

Before I get into it, thank you. I read so many interview posts on this community while I was prepping. Every one of them helped a little. A tip here, a "don't do what I did" there. Random small details that made a round feel less scary because someone had already been through it and lived to tell me about it. So this is me doing the same thing for you. Quick, slightly silly detail before we start. Amazon caps how many active applications you can have on one account. I wanted to apply to every open SDE II role I could find. So yes, I used two accounts. No regrets.

Four rounds. One real regret. One moment I'm still a little proud of. Let's go.

Round 0 : The OA

I'll be honest, my memory of this one has faded. There was a section with some kind of AI-related repository or codebase and one DSA question I genuinely can't recall anymore. I'd rather say "I don't remember" than make something up just to sound more prepared than I was. It happens. Keep reading anyway.

Round 1 : DSA and the Moment I Almost Regret

My interviewer was an SDE III. We started soft, about 10 minutes on two Leadership Principle questions: Learn & Be Curious and Ownership. No code yet. If you're new to Amazon's style, this is normal here. LPs open almost every round, not just one dedicated "behavioral" slot at the end.

Then came a coding problem that kept growing on me. He'd let me solve one version, then add a twist, then another, until a fairly plain BFS question had turned into a full multi-source BFS problem by the end. I actually liked this. It felt less like a test and more like solving something together, one layer at a time.

Quick plain-English version of what multi-source BFS even means, in case you haven't hit it before: normally BFS starts from one point and spreads out. Multi-source BFS just starts from several points at once. Say you have a grid and some cells are "sources." You want to know, for every other cell, how far it is from the nearest source. You don't run a separate search from every cell asking that question one at a time. You drop every source into the search queue together, right at the start and let the search grow outward from all of them at the same time. The first moment any cell gets touched, that's its true shortest distance to the closest source, because BFS explores in layers, one step out at a time.

Here's the basic shape of it, using a common version of this idea (every cell's distance to the nearest zero in a grid):

// Multi-source BFS: put every source cell in the queue at once,
// then expand outward from all of them together.
static int[][] nearestZero(int[][] grid) {
    int rows = grid.length, cols = grid[0].length;
    int[][] dist = new int[rows][cols];
    for (int[] row : dist) Arrays.fill(row, -1);
    Deque<int[]> queue = new ArrayDeque<>();
    for (int i = 0; i < rows; i++) {
        for (int j = 0; j < cols; j++) {
            if (grid[i][j] == 0) { 
              dist[i][j] = 0; 
              queue.offer(new int[]{i, j}); 
            }
        }
    }
    int[][] dirs = {{0,1},{0,-1},{1,0},{-1,0}};
    while (!queue.isEmpty()) {
        int[] cur = queue.poll();
        for (int[] d : dirs) {
            int ni = cur[0] + d[0], nj = cur[1] + d[1];
            if (ni >= 0 && ni < rows && nj >= 0 && nj < cols && dist[ni][nj] == -1) {
                dist[ni][nj] = dist[cur[0]][cur[1]] + 1;
                queue.offer(new int[]{ni, nj});
            }
        }
    }
    return dist;
}

This runs in O(rows × cols) time, since every cell only ever gets added to the queue once. I want to be upfront here: my real interview question was custom and built up in stages, so I can't hand you my exact question word for word. This is the general shape it grew into. I tested it cell by cell against a slow, obviously-correct brute-force search across 500 random grids and it matched every time. If you know this pattern cold, you're ready for whatever specific costume it's wearing when you meet it.

Now here's the part I want you to actually slow down for, because it's the real reason I'm writing this section.

I solved it. But partway through, I noticed an edge case I hadn't handled. I knew it was there. It was just sitting in the back of my head. There were maybe 15 minutes left, my interviewer looked happy with what I'd written and some tired, self-protecting part of my brain went: don't bring it up, just let it go, you're almost done.

So I didn't say anything. He looked over my solution and said, "That's it. Any questions for me?" I sat there for a second, actually confused, half-waiting for a follow-up that never came. He'd missed it too.

I'm not proud of that. It worked out for me this one time and HR gave positive feedback afterward. But I want to say this straight to you: please don't do what I did. If you know there's a hole in your solution, say it out loud. Nobody's grading you on being perfect under a clock. They're checking whether you catch your own mistakes before a real user does. Staying quiet doesn't make your answer look more finished. It just means you got lucky and luck isn't something you can plan on twice.

Round 2 : LLD and the Time I Basically Pointed at a Clock

This one had a fun twist. Think of the usual Amazon Locker flow, but flipped. Instead of a delivery person dropping a package off for the customer to collect, this was a return: the customer books a slot at their nearest drop-off store and carries the package there themselves.

I did what I'd tell anyone to do. I didn't touch the keyboard right away. I spent real time upfront on requirements, figuring out what actually needed to be modeled, before writing a single line. Then I started coding.

Right in the middle of it, my interviewer pivoted: "How would you find the nearest drop store to the customer's location?"

Here's the honest answer. I've never really done HLD prep before this whole process. So I gave the one thing I actually had, geosharding, splitting the map into regions so you're only searching nearby data instead of everything at once. He wanted more. He even gave me a hint: "Think about how Uber does this." I genuinely did not know how Uber does this. I just sat there without an answer.

So and I'm a little proud of this even now, I looked at the clock on screen and I slowly moved my cursor over toward it. No words. Just hoping he'd get the hint: this is LLD, not HLD, can we finish the actual code? Somehow it worked and we moved on.

I spent around 35 minutes just writing the code itself, which left almost no time for anything after. This was also the only round, out of all four, where there was a question I flat-out couldn't answer. After that came two more LP questions, Dive Deep and Invent and Simplify and the round ended.

When I asked HR for feedback on this one later, I didn't get an answer. No idea if that meant "don't worry about it" or something else. I just had to sit with not knowing and move on to the next round, which is its own special kind of uncomfortable if you've ever interviewed anywhere.

Round 3 : The Bar Raiser Round and 65 Lines of Code in 15 Minutes

Ten more minutes of LP questions to start, Customer Obsession and Deliver Results this time. Then the coding problem showed up and while writing this post I realized it's very close to a well-known "safest path in a grid" style problem you'll find on most coding practice sites, where some cells are marked as thieves and you want to walk from one corner to the other while staying as far from them as possible the whole way. Some sites file it under "medium" difficulty. I'd push back on that. It's a hard problem wearing a medium badge and I say that as someone who'd never solved it before and had to build the whole thing live, on a clock, in front of someone deciding whether I clear the bar.

Since I want this post to actually help you and not just tell a story, I went back afterward and worked through the real solution properly, then tested it, so I know it's actually correct.

The problem in plain words: you have a grid. Some cells have thieves in them. Every cell's "safeness" is how far it sits from the nearest thief. You need to get from the top-left corner to the bottom-right corner and you want to pick a path that keeps the worst point along the way, the lowest safeness you're forced to pass through, as high as possible.

Step one is figuring out every cell's safeness. That's the exact same multi-source BFS pattern from Round 1, just pointed at thieves instead of zeros. Seed the queue with every thief at once and let the search grow outward from all of them together.

static int[][] computeSafeness(int[][] grid) {
    int n = grid.length;
    int[][] dist = new int[n][n];
    for (int[] row : dist) Arrays.fill(row, -1);
    Deque<int[]> queue = new ArrayDeque<>();
    for (int i = 0; i < n; i++)
        for (int j = 0; j < n; j++)
            if (grid[i][j] == 1) { dist[i][j] = 0; queue.offer(new int[]{i, j}); }

    int[][] dirs = {{0,1},{0,-1},{1,0},{-1,0}};
    while (!queue.isEmpty()) {
        int[] cur = queue.poll();
        for (int[] d : dirs) {
            int ni = cur[0] + d[0], nj = cur[1] + d[1];
            if (ni >= 0 && ni < n && nj >= 0 && nj < n && dist[ni][nj] == -1) {
                dist[ni][nj] = dist[cur[0]][cur[1]] + 1;
                queue.offer(new int[]{ni, nj});
            }
        }
    }
    return dist;
}

Here's the real trick, and this was the part where I actually optimized my approach out loud. I walked through the time and space complexity twice because, in an interview, showing how you think matters almost as much as reaching the final solution.

Once every cell has a safeness score, the problem becomes much easier to frame: what is the maximum safeness value we can guarantee along a path from the top-left to the bottom-right? From there, I turned it into a binary search problem. Pick a candidate safeness value and run a simple BFS or DFS to check whether a path exists using only cells whose safeness is at least that value. If such a path exists, we can try for a higher value. If it doesn't, we need to go lower.

So the final approach is essentially multi-source BFS to calculate safeness scores, followed by a reachability check inside binary search. That's the combination I eventually arrived at during the interview.

static boolean canReach(int[][] safeness, int mid) {
    int n = safeness.length;
    if (safeness[0][0] < mid || safeness[n-1][n-1] < mid) return false;
    boolean[][] visited = new boolean[n][n];
    Deque<int[]> stack = new ArrayDeque<>();
    stack.push(new int[]{0, 0});
    visited[0][0] = true;
    int[][] dirs = {{0,1},{0,-1},{1,0},{-1,0}};
    while (!stack.isEmpty()) {
        int[] cur = stack.pop();
        if (cur[0] == n - 1 && cur[1] == n - 1) return true;
        for (int[] d : dirs) {
            int ni = cur[0] + d[0], nj = cur[1] + d[1];
            if (ni >= 0 && ni < n && nj >= 0 && nj < n && !visited[ni][nj] && safeness[ni][nj] >= mid) {
                visited[ni][nj] = true;
                stack.push(new int[]{ni, nj});
            }
        }
    }
    return false;
}

static int safestPath(int[][] grid) {
    int[][] safeness = computeSafeness(grid);
    int n = grid.length;
    int lo = 0, hi = 2 * n, best = 0;
    while (lo <= hi) {
        int mid = (lo + hi) / 2;
        if (canReach(safeness, mid)) { best = mid; lo = mid + 1; }
        else hi = mid - 1;
    }
    return best;
}

The safeness calculation takes O(n²) for an n × n grid because the multi-source BFS visits every cell at most once. Then we binary search for the best possible safeness value, which takes O(log n) iterations, and each iteration runs another O(n²) BFS or DFS reachability check. That brings the overall time complexity to roughly O(n² log n), which is a huge improvement over trying to explore every possible path.

I also tested the approach against a slow brute-force solution that tries all possible paths on roughly 9 random small grids. The results matched every time. So this wasn't just something that sounded right under interview pressure. I actually verified that the approach was producing the correct answer.

But honestly, the bigger lesson from this round wasn't the algorithm. I didn't walk into the interview already knowing this solution. I started with a rough first idea, optimized it once, explained why that approach still wasn't good enough, and then optimized it again until I finally landed here. Even then, my interviewer kept pushing me further after I thought I was done.

By the time the final approach clicked, I had around 15 minutes left to write roughly 65 lines of code while explaining my thinking at the same time. So if you ever find yourself stuck in that exact situation with the clock running and the optimal solution still not completely clear don't just sit there waiting for the perfect idea to appear. Start with what you have. Write the rough solution. Talk through it. Show where it breaks down, then improve it. Don't wait until you've solved the entire problem perfectly in your head before touching the keyboard.

It worked out for me this time, but trying to write 65 lines of code in the final 15 minutes is definitely not something I'd recommend planning for. And when it came to asking for feedback afterward, I didn't really feel the need to. Sometimes you just know. You get that feeling in the room when you've done more than simply clear the bar you've actually raised it.

Round 4 : The One That Finally Felt Easy

By this point I was tired. Three rounds deep, LPs and code and design stacked on top of each other. Round 4 was System Design, run by the Hiring Manager and she was just easy to talk to. The kind of interviewer who turns a hard round into a normal conversation.

We opened with two more LP questions, Earn Trust and Have Backbone & Disagree and Commit. Then she gave me a problem I'm fairly sure was pulled straight from something her team is actually building: syncing configuration across different devices. She kept pushing from different angles and for the first time in four rounds, I answered every single one cleanly.

This was, without a doubt, my smoothest round of the whole process. Sometimes it just clicks and this was that round for me.

The Verdict

Selected. 🎉

I won't pretend I wasn't relieved. Four rounds, one mistake from Round 1 that I completely own, one round I couldn't even fully finish, and somehow it still added up to an offer. If there's one thing I hope you take away from this, it's that you don't need a perfect interview to get through. You need to keep going when a round feels shaky, be honest about where you went wrong, and actually learn from those moments.

For me, that was Round 1. I almost let something slide, caught it, and made sure I didn't repeat the same mistake in the rounds that followed. Sometimes getting selected isn't about having a flawless interview. It's about how you respond when things don't go perfectly.

A Few Quick Questions People Keep Asking Me

That's genuinely everything. If you're deep in your own prep right now, reading this late at night wondering if you're doing enough, I hope some part of this helps the way other people's posts helped me.

All the best. You've got this.