Unpacking my Internship Experience at Amazon

Introduction

“Customer Obsession” and “Bias for Action” are phrases you memorize for the interview, but seeing them applied in real-time is a different experience entirely. This summer, I had the opportunity to join Amazon Luxembourg as an SDE Intern, and it shifted my perspective on what it means to be a software engineer.

Looking back at those six months, the experience was a crash course in professional development. It challenged my technical skills, tested my soft skills, and forced me to get comfortable with ambiguity. Whether you are an aspiring intern or just curious about the engineering culture inside Amazon, here is an honest look at my highs, my lows, and everything I learned in between.

The Application and Interview Process

The application process for Amazon SDE internships matches quite closely the common format of applying to a big tech company: the first step is to go to their Careers Portal, find roles you are interested in, make sure your resumé is polished and apply. The next step is the Online Assessment (OA), which includes both a tech screening with two LeetCode-style questions and a Leadership Principles/behavioral assessment. The latter is a very important part of the OA since Amazon strongly believes in coachability when it comes to hard skills (especially for interns!), but Leadership Principles are viewed as intrinsic traits that determine cultural fit.

Once you clear the OA, it’s time for our favorite step of the application process: the interviews.

Unlike most other companies, Amazon’s onsite interview step for interns only includes a 1-hour interview slot which focuses both on behavioral and technical skills. The technical portion of the interview is one LeetCode problem you’ll solve with the interviewer, usually in the easy-medium difficulty range, while the behavioral questions are tailored to find out more about your previous experiences and strongly connect to the Leadership Principles that are deemed most important for your role.

Day One: Relocation & Onboarding

After quite a bit of anxious email refreshing, the interview results came out and they were bittersweet: while I had successfully cleared the interview round, there was no more headcount for intern positions which meant I was waitlisted. Thankfully, just a few days later, the offer finally landed. Next stop: Luxembourg.

Moving to a new country for an internship is daunting, but Amazon’s relocation package made it significantly smoother. For those unfamiliar, Amazon Luxembourg (LUX) is the European Headquarters, meaning the intern cohort is massive and incredibly diverse. By the time I picked up my badge and laptop on my actual “Day One”, I had already met some interns around the city who had already shared some guidance and tips with me.

However, the social ease didn’t quite match the technical ramp-up.

There is a saying at Amazon that onboarding is like “drinking from a firehose”, and it is 100% accurate. Since my first Day One, there were quite a few challenges and things that are peculiar to Amazon:

• The Internal Tooling: The first shock was realizing that Amazon has built an internal version of almost everything. From the build system to the deployment pipelines and even the code review tools, you have to learn an entirely new ecosystem before you can write a single line of feature code.

• The Writing Culture: I quickly learned that Amazon runs on documents, not PowerPoint decks. The famous “1-pagers” or “6-pagers” you hear about on LinkedIn or Reddit are real. In my first month, I spent more time reading design docs (and trying to understand the endless acronyms) than I did opening my IDE.

Fun fact: there are so many acronyms used in these docs that there is a wiki page that includes a comprehensive list of all of them, along with their translation in other languages like Chinese.

The Team

After picking up my badge and laptop it was time to meet my team! I was part of the Global Transportation Technology Services team (GTTS for short), responsible for one of the many gears that build up the huge machine that is Amazon’s logistics network. The team itself was incredibly diverse, with everyone bringing unique skills to the table. However, one common thread stood out: everyone was a well-rounded engineer. Whether it was backend logic or infrastructure challenges, no one was afraid to Dive Deep into territories they hadn’t explored before. Every single member of my team has taught me something either related to the job or personally, and I can’t thank them enough for making this experience as good as it was.

When you start your journey at Amazon your manager carefully crafts an onboarding plan which includes things to do, material to study to ramp-up your technical knowledge and adjust to the Amazon culture, and people you should talk to - stakeholders, product owners, team members, anyone you will be working with. My first week mostly included a lot of coffee chats to get to know all of the team members better, along with giving me the possibility to ask them some advice they might have for a new Amazonian.

As an intern you’re also assigned an onboarding buddy and a mentor. The onboarding buddy is a member of your team that is responsible of making sure your onboarding to the team, tech stack and project is as worry-free and seamless as possible, while the mentor is someone who’ll follow your journey more closely than your manager and work with you on your project.

The Project: Ownership and Architecture

Once the initial coffee chats were done and I had a grasp of the acronyms, it was time to dive into my project. Before tackling the core project directly, my onboarding plan included some small onboarding tasks that impacted our core product directly and gave me a hands-on introduction to Amazon’s build tools and infra, along with having an initial understanding of our codebase and product. This is exactly what in my opinion is the best thing about interning at Amazon: you aren’t given “dummy projects” or busy work. My initial tasks were small Quality of Life improvements for our customers, addressing a genuine business need and was in the team’s backlog.

Next came my project work: during the remaining 5 months of the internship I got to work on two projects: one impacting our developer experience and one impacting customers directly.

Design First, Code Later

Coming from university, I was used to jumping straight into the IDE to start coding. Amazon works differently. Before writing a single line of production code, I had to write a Design Document.

I had to define the architecture, calculate the estimated costs, identify potential bottlenecks, and plan for operational metrics. Presenting this doc to the engineers on my team was one of the most nerve-wracking but valuable experiences of the internship. Although you end up leaving some of these meetings with more questions and doubts than when you first walked into the room, these occasions forced me to think about why I was making specific technical choices, not just how to implement them.

Tech Stack

My project work mostly relied on Java (the bread and butter of Amazon backends) and, of course, AWS Native services like Lambda, RDS, CloudWatch, State Machines, DynamoDB and EventBridge.

In university we do not explore the main cloud providers enough, so this was my first time using AWS to its full potential and learning about the extensiveness of how many services there are and how pretty much every problem you encounter has already been solved by an AWS team and there is a publicly available service to solve it for you. I got exposed to some concepts like Infrastructure as Code (IaC), which meant that every single change to the project infrastructure had to be done through AWS Cloud Development Kit (CDK). This made sure that the environment is consistent across all deployment regions, environments and stages and that every change is accounted for and passed some form of validation.

While I feel like my progress was consistent, there were many roadblocks that had me stuck on a specific part of the projects for a few days and could only be solved by following what I believe to be the most important LP for an engineer: Dive Deep. Rather than just trying to solve a problem blindly, take the right time to go through the code paths, output logs and address the root cause rather than the symptom. For example, there were some instances where we had some performance hiccups that could be improved exponentially by doing something small like adding an index to your database table for faster queries. This type of change is something that can be picked up only after carefully diving deep into the root cause.

Finally, one of the most important things at Amazon is to design your code carefully and make sure it has enough logging, metrics alarms so that your team’s on-call engineer knows what to do when their phone rings at 3 AM because of an outage on your component.

Life in the Grand Duchy 🇱🇺

Luxembourg (or Lux, as everyone calls it) is a unique place for an internship. It doesn’t have the chaotic energy of London or the tech-bubble vibe of places like SF/NYC. It’s calm, incredibly international, and surprisingly central: the city is very well connected to France, Germany and Belgium and it’s so convenient to travel around that you don’t even feel like you’re leaving the country!

The Amazon offices in Kirchberg are a melting pot. Walking down the hall of your floor or grabbing lunch at a nearby restaurant you can hear a mix of German, Italian, Spanish, Portuguese and English.

The city’s compact size is a double-edged sword: it’s incredibly easy to build a network, but it also means the ‘Amazon Bubble’ is real. I used to roll my eyes at stories from friends in the Bay Area complaining about running into managers while out on dates, thinking they were exaggerating. Boy, was I extremely wrong! In Luxembourg, bumping into a coworker at the gym, the grocery store, sitting on a bus or a bar isn’t just a possibility - it’s guaranteed to happen.

A very big cultural shock as an Italian was the free public transportation across the entire country. When I first saw a sign welcoming me at the airport and telling me “There is no need to buy a ticket, public transportation is free all across Luxembourg” my jaw dropped. I was even more shocked to realize that the transportation was not only free, but also very efficient.

Advice for future Amazonians

While I’ve only scratched the surface compared to veterans who have been at the company for a decade, here is the advice I wish I had known before I started.

For Applicants:

• Live by the LPs: It cannot be overstated—revise the Leadership Principles carefully and practice the STAR method (Situation, Task, Action, Result) for every behavioral question. They aren’t just HR buzzwords; they are the grading rubric.

• Think Out Loud: In the technical interview, communicating your thought process is arguably more important than getting the perfect solution. The interview is a collaboration, not a test. Don’t code with your head down in silence; treat the interviewer like a coworker you are solving a problem with.

For Incoming Interns:

• The Calendar is Law: This is the golden rule of Amazon culture. If it isn’t on the calendar, it doesn’t exist. Rather than walking up to a desk and hoping someone is free, block time on their calendar. It respects their “Deep Work” time and ensures you get their full attention.

• Balance “Dive Deep” with “Bias for Action”: Your senior engineers are there to help, and there is no such thing as a stupid question. However, always try to solve the problem yourself first by looking at docs and logs. Approaching a senior with “I tried X and Y, but Z is still happening” is much better than “I’m stuck.”

• Read the Masterpieces: Take full advantage of the internal wikis, session recordings and emails. There are Principal Engineering design docs and “Correction of Error” (COE) reports that are absolute masterpieces. Reading them is the fastest way to level up your engineering mindset.

After the internship

The internship journey ends with a final 1:1 meeting with your manager, arguably the most anticipated meeting of the entire six months. In this session, your manager walks you through your final performance review and communicates the hiring decision.

There are generally two outcomes:

• Inclined to Hire: This means you have met (or exceeded) the hiring bar. Amazon will aim to extend a full-time Return Offer (RO), either converting you within your host team or finding a spot in another organization if headcount is tight.

• Not Inclined to Hire: This means the consensus is that, while you may have had strengths, you need more time to develop your technical or behavioral skills before operating independently as a full-time SDE.

Conclusion & Key Takeaways

As I pack my bags to leave Luxembourg, I’m leaving with more than just some cool swag. I’m leaving with a lot of memories, a network of incredible friends and the confidence that I can tackle complex engineering problems at scale.

Amazon is a demanding environment - it asks a lot of its engineers - but it gives a lot back in terms of autonomy and learning opportunities. Whether you end up staying for six months or six years, the “Amazonian” mindset of ownership and bias for action is something that sticks with you.

For now, it’s time to head back to university and apply these lessons to my thesis work. Just to give you a practical example of how Amazon’s culture has impacted me, I already had to write a 6-pager for my thesis project to make sure I was carefully thinking through all engineering decisions and their related impact!

Thanks for reading along on this journey!