My SDE Internship Experience at Amazon Web Services (AWS)
Posted on
So… As I previously announced in my “Future Plans” Blog Post, I was planning to do an internship. Today, more than 1 year later, was the last day of my 5-month internship at AWS, where I was part of the Amazon Transcribe team as a Software Engineering (SDE) intern.
In this blog post, I want to reflect on my internship experience and share what I have learned during that time.
Internship structure
Onboarding
As with every new job, there's always a lot to learn to become productive. Fortunately, Amazon provides excellent support for the onboarding phase. Every intern is assigned a mentor and an onboarding buddy, who are there to answer questions and guide us throughout the internship.
Additionally, there was a self-service onboarding plan that contains some essential tasks and learning resources for the first few weeks. It educated me about Amazon's culture, guided me through technical courses, and connected me to important people at Amazon.
Project
After a few weeks of onboarding, I was introduced to my project. At Amazon, interns usually get their own project that they complete independently. Therefore, before I could start implementing, I also had to write a project plan, design docs and present the project to the team.
After this initial planning, I spent most of my internship implementing my project. This happened in collaboration with the other team members, designers, product managers, and security teams, which was a great lesson in cross-functional collaboration.
At the end of the internship, I had the opportunity to present my project to the bigger Transcribe team, which included employees from both the US and Germany.
Performance Reviews
During the internship, there were two performance reviews. One in the middle, just to give an opportunity to improve and one in the end, which reflected on the whole internship and influenced whether I'd get a return offer.
During these reviews, my manager and I would each fill out a reflection form, which we could then compare to check if my perception matched the perception of my manager.
Things that stood out to me
Amazon Culture
While I've already heard about the Amazon Leadership Principles during my interview preparations, I always thought that “company culture” was more of an external marketing thing. To my surprise, a lot of our processes are formed and guided by these principles, and they'd regularly be used during meetings to make decisions. They were even part of our performance reviews.
Openness and Community
Mostly knowing traditional German companies, I was surprised about the openness of Amazon as well. From what I've seen so far, Germans usually work and get along well with their colleagues, but would rarely spend time with them outside of work or consider their colleagues as friends.
Coming from that background, it took me by complete surprise how often we would spend time outside of work to play games, go to a bar or go on a weekend trip. My colleagues even attended my concerts!
Writing
In my university's computer science program, I rarely write documents anymore. Exercise submissions are typically short paragraphs of texts, math, or code. Therefore, I thought for Software Engineers it would be the same.
Consequently, I was very surprised to see how many documents are written at Amazon. I wrote a project plan for my project and multiple design docs for broader technical decisions. Internally, we regularly used those documents for asynchronous collaboration and to document decisions.
The main benefits I saw in writing are:
- It forces us to think things through: In verbal discussions, it is easy to skip over some details that might be important.
- It forces good arguments: It's easier to follow arguments. Therefore, bad arguments are recognized faster.
- It is reviewable: Other's can comment on the document in their own time, often leading to more detailed and nuanced feedback.
- It serves as documentation: Often, we forget why we have made certain design decisions. Having a design document that discusses the tradeoffs between different approaches helps us to remember.
My takeaways
Surprisingly, to me the most valuable lessons were the insights into operating highly scalable and highly available services and the soft-skills I've learned, not the technical ones.
While my technical skills have grown a lot during my internship, most of my learnings were ones that come with time spent with those technologies. In the end, I grew my technical skills by reading docs and code review feedback (which is valuable, but not unique to Amazon).
The insights into operations and the soft-skills are not as publicly available, though. While there are many great blog posts discussing how to collaborate and work effectively and how to run scalable software reliably, most of the tips in those posts are anecdotal. They definitely help to understand how these services are run, but they can only ever discuss tiny slices of these huge services, which retrospectively still left huge gaps in my understanding of operating such services. Therefore, I'd consider the actual experience of working on such a system and collaborating with a team my most valuable learning.