Amazon Software Engineer Interview Experience — SDE I New Grad Loop in Canada, Offer the Monday After the Final Interview

Hey everyone!

I recently graduated with a CS degree from a school in Canada (I'm an international student) and ended up with an SDE I offer from Amazon. Here is how the process went, hopefully it's useful to somebody.

Timeline

• My application went in during the last days of January 2026. Nobody referred me.
• In early April the online coding assessment arrived in my inbox, and I sent it back after two or three days.
• There was no recruiter phone call for me, though I gather some candidates get one. The AUTA (Amazon University Talent Acquisition) recruiter emailed me what came next and asked which times worked.
• Roughly seven days after that email, I had four interviews booked over a pair of days.

Online Assessment

• The first part was a LeetCode Hard dynamic programming problem, one hour, hidden tests. The edge cases kept piling up so I went back and forth for quite a while, but eventually it passed every test.
• The second part was a live coding task, something I had never seen before. They put you inside an IDE that already has a small full stack app, and three bugs (spread over backend and frontend) need fixing so that the tests go green. I believe there were six hidden tests, which meant I had no idea which test was tied to which bug. I burned the entire hour on it.
• The third part wasn't technical at all. It was a work style questionnaire built around emails, where you choose the response that seems most appropriate. No clock on this one, and it took me around a quarter of an hour.

Interview Process

• My first conversation was with the manager I'd report to.

  • After brief introductions, the questions were mostly about AI: how I lean on it for studying, how I'd fit it into the way I code, and which of my earlier projects used it. Prepare for these well beforehand. You should also know how you'd scale an AI project you built, how you'd validate what it produces, and whether AI was actually the right tool for the problem at all.
  • Next came a LeetCode Medium, Merge K Sorted Linked Lists. My order was brute force first, then the better solution, then the side topics like pulling data from files and edge cases. When it seemed the interviewer was on board with the plan, I coded it and traced a sample input through by hand. Then I covered a few more edge cases plus time and space complexity. The follow-up questions touched on space usage and how things would differ with another heap implementation.
  • It was the round I did worst in. For the project, I picked something from a past internship that had no real need for AI and couldn't have scaled to Amazon's size. In the coding part I assumed the heap would be backed by a tree structure rather than a list, so my space analysis fell short of optimal. Luckily the interviewer was generous, explained the stronger solution, and went past the scheduled end to do so.

• Next up was the bar raiser, run by a manager on another team (same org, it seemed).

  • Their introduction went on much longer than the first one, and afterwards we went deep on my resume and earlier projects. All of the questions were phrased as leadership questions, yet I could usually steer my answers toward the projects I felt strongest about.
  • Of all four, this was my favorite. The interviewer really cared about the technical side of what I'd built, kept stopping me to ask for clarification or more depth, and I had plenty to say about every project. We also got into what I'd change in hindsight, what each experience taught me, and how I used those lessons later.
  • What I suggest: for each line in the experience, research, and projects parts of your resume, write up a STAR story. I used Excel, and finished with over 20 stories that were easy to link to Leadership Principles. Doing it also showed me which stories felt most natural, so I could tell those first rather than other ones that fit the same principles.

• On the following day I had my third interview, with an SDE II who works on the team I'd be joining.

  • After a short intro, I got a LeetCode Hard graph problem. I followed my usual routine, but I slipped on silly details (a bad starting value, unnecessary comparisons, that kind of thing). The most useful habit was narrating my reasoning and tracing the code by hand over and over, because the editor was plain text and nothing could be executed. Whenever I found a bug, I traced it again.
  • Around the thirty-minutes-left mark the interviewer switched to LP questions. I'm not sure that was smart, but when they asked about missing a customer deadline, I had no honest example, so I joked that my internships had trained me to hit deadlines.
  • That led into a discussion of my habits for avoiding it, such as leaving spare days, chopping work into very small pieces, and setting a time budget for each. The whole thing felt like a conversation instead of an interview, with each of us trading stories about different workplaces.
  • After that, they said it was time for me to question them. I asked how the team is organized, how on-call works, and some detailed things about their tech stack. They were friendly and kept going almost ten minutes past the hour to cover everything I asked.

• Straight after that came a fourth interview with another senior engineer on the same team.

  • The task was to build a parking lot system, which I had rehearsed beforehand with free online lessons and videos, so I applied the method from those. I used only free material for my prep.
  • If you're preparing, my suggestion is to go through the free LLD mock questions available online first, then look at sample problems in GitHub repos and compare the solutions people post.
  • Midway through writing my pseudocode, the interviewer brought up concurrency. I had used threads and locks, so we talked about why they mattered and how the design holds up at a bigger scale. There was a stream of clarifying and what-if questions too. I had assumed those would only come once the implementation was done, but I was answering them while still typing.
  • Exactly 35 minutes in, the interviewer closed out the coding, and LP questions followed. I deliberately picked stories I hadn't used yet, reasoning that the interviewers would compare notes afterward and a wider spread of experiences would look better. At the end I asked a few more things about the team.

The last interview fell on a Thursday and the offer email showed up the Monday after. As far as I can tell, AUTA is pretty prompt, typically replying within 5 working days after the final interview.

Final Thoughts

Plenty of good tips exist already, so I'll stick to a few I haven't run into elsewhere:

• Have Claude or ChatGPT put together the behavioral questions that come up most often, based on sources like Glassdoor and Reddit. Read through it, and for any question where you draw a blank, invent a plausible situation and add that story to your Excel file.
• Keep a spreadsheet covering the Neetcode 150: the best approach for each, its time and space complexity, and any gotchas you'd otherwise forget. Look over it right before the interview instead of re-solving everything. Being able to talk through the approach is enough.
• Treat LLD the same way. Find the commonly asked problems in a GitHub repo, and decide what you would ask the interviewer to pin down the scope. Then think about how their answers would alter your pseudocode. In the end I had a cheat sheet of typical LLD problems and I skimmed it ahead of each interview.

Good luck!