The following are my words only — they do not represent Amazon.com’s opinion in any way nor are they affiliated with Amazon.com or any of its subsidiaries, including Amazon Web Services (AWS). Please keep in mind that this is my experience following a 3 month internship. The experience could have yielded some different insights if I had worked there for over a year.
Additional Note: My experience was limited to spending the summer on one AWS team and hearing about other AWS teams through numerous friends and fellow Amazon SDE interns.
Ezzy is currently a senior in UC Berkeley’s Computer Science program. If you’d like to learn more about his story and experiences, you can find his LinkedIn here.
Last week culminated my 3 month Software Development Engineering Internship at Amazon Web Service’s (AWS) Seattle HQ. As I approached my junior year at UC Berkeley, I had experience launching a product, working on a team of 10 engineers at a start up, and providing tech consulting services to top campus organizations. In my mind, there was a clear barrier between the type of engineering that happens when working as a freelance consultant or at a start up company versus at a big technology company, but my summer at AWS erased this distinction.
Before I joined
Before I joined AWS for summer 2017, my impression of AWS was that it was an elite technology bootcamp brimming with smart engineers who simply loved problem solving. I knew that AWS was a cornerstone innovation for start up companies in the last decade. It was no secret that AWS services unleashed the power of the Cloud for new companies, Fortune 500 companies running legacy software, and tech heavyweights alike. To me, AWS represented a technology company where software engineering tirelessly reached across all of computer science’s disciplines (database, networking, security, etc.). When applying to Amazon, my mission was to land an internship spot on an AWS team. My goal, by the end of the summer, was to dive into computer science from unprecedented heights and learn what makes the average AWS engineer tick. The big question in my head was:
“If working at Amazon Web Services isn’t computer science, then what is?”
Here’s what I found
3 Months Later…
A Culture & Structure that Fosters Engineering Innovation
AWS’s personality can best be described as one built to relentlessly satisfy hungry engineers eager to solve the next problem. Since its early beginnings, Amazon’s DNA has been that of technology company’s. As it grew from its humble origins to snag the title of “World’s Largest Online Retailer,” its logistical, automation, and product problems screamed for innovative technology solutions. However, as Amazon ballooned into the company it is today, a significant technology problem was software engineering at scale. As Amazon realized that its technology problems were also universal technology problems, the launch of AWS as a business unit followed naturally, but the furnace fueling AWS’s startling growth is a culture & structure for engineering more than anything else.
Customer Obsession
On my very first day at Amazon, I heard an engineer say that he has frequently seen debates settled between engineers when one asks, “What would the customer want?” Although engineering has the tendency to wander into deeper technical problems that mask the underlying customer problem, Amazon has ruthlessly fought for the customer voice to always be closely accessible. There’s not much more I have to say here, but I will share a neat story: The CEO of Amazon, Jeff Bezos, has been seen bringing an empty chair into important meetings to represent the customer.
Generalist Software Engineers
Although a software engineer’s responsibilities can fluctuate across various roles in industry, at Amazon, software engineering as a role entails gathering requirements, designing, coding, testing, monitoring, quality assurance, deploying. This breadth of ownership on the part of individual engineers’ reduces missing links on the path to building top-notch software. This level of ownership incubates a more seamless development process where software engineers are generalists first and foremost. Software engineers at Amazon acquire skillsets that cut through engineering roadblocks regardless of problem domain: engineering problems, people problems, resource problems, you name it.
Team-Level Freedom
It was not uncommon to see engineers gathered in circles for stand-up (daily meeting to reflect on the previous day’s progress) around the building between the hours of 10–12pm. Although certain Agile and Scrum principles (software development process methodologies) seemed to permeate across AWS teams, each AWS team functioned as an independent group of engineers. Each team had the goal of being 2-pizza, meaning teams aimed to keep their size to a maximum of the number of slices contained in 2 pizzas (around 10 people). As independent groups, teams had the autonomy to operate on their own terms- this extended through code review guidelines, programming languages (where flexibility was permitted), technologies, software development process methodologies, office schedules, remote work guidelines, etc. Team-level freedom cemented the ability for engineers to establish ownership over their work at the most fundamental level. With this vote of confidence, engineers had a direct hand in shaping change and raising engineering curiosity from the bottom up.
Hiring Bar
On rhythm with one of Amazon’s 13 leadership principles: Hire & Develop the Best, AWS took pride in setting an effective hiring and promotion bar. I saw engineers taking baby steps to try out manager roles before jumping into them formally. I also saw how recruiting for Amazon-outsiders was done on a team by team basis. If you are assessing a job candidate who would be joining your own team, you are more likely to form an in-depth opinion regarding their fit for your team. I also admired the bar-raising process Amazon employs to encourage an unbiased, argumentative voice into hiring meetings.
Curiosity as the Ultimate Motivation
I’m sure you’ve gathered quite a bit on how AWS operates as a playground for engineers, but curiosity is not always easy to sustain. In such a fast-paced work environment, at times, prioritization can require engineers to focus on tasks that have become routine for them. AWS tackles this head on by allowing engineers to transfer from one team to another in a simple manner. Although there was an interview process to move from team to team, most engineers characterized them more as informal coffees and white boarding with managers / engineers on the other team. From what I gleamed, AWS has a world of experiences to offer; but in particular, having the ability to switch teams at AWS could endlessly extend an engineer’s curiosity.
Frugality in its Veins
Frugality (in respect to resources given to each team) was a general theme among software engineers on AWS teams. It seemed that engineering headcount on AWS teams remained at a level where engineers were forced to prioritize one feature over another. There was constantly a sense of urgency in the air which resulted in engineers making quality decisions. Since there were always more tasks on engineers’ plates than they could complete, the shortest path to achieve the end goal bubbled up into view.
The perfect story
The perfect story to illustrate AWS as a powerhouse is the story of when its storage service, S3, went down. According the TechCrunch, the S3 outage affected much of the internet including Quora, BusinessInsider, and Slack. The outage was confirmed by Amazon to have been caused my the human error of an S3 team member who inadvertently typed in a command wrong. Although the outage lasted several hours and costs Amazon a great deal of revenue, the engineer was not fired nor blamed for the mistake. Why not?
AWS treats engineering mistakes as systemic mistakes. When an outage occurs, they investigate the problem based on processes. Rather than asking an engineer, “what is wrong with you?,” they ask “what made the engineer make the issue?” and “how it can be prevented in the future?.” Although a big company by most measures, AWS maintains human-centered processes instead of bureaucratic red tape. It is no easy feat, but my impression was that AWS has positioned itself to remain flexible and resilient despite obstacles. AWS’s flat hierarchy (my AWS team operated under a General Manager who was only 2 degrees of separation from me in the management chain) is no doubt a contributing factor as well. As long as the atmosphere for happy engineers continues to be maintained, AWS will continue to innovate at scale.
Thank you to my AWS team for their hospitality and mentorship this summer.
Want to see more like this? Click here to subscribe to see my blog posts in your inbox as they release.
Ezzy
A note to readers: I always welcome feedback, contrarian opinions, and questions. Please feel free to email me at ezzy@berkeley.edu. If I need to update my posts with clarifications or new information, I am happy to do so.
Recent Comments