1 year @ Amazon as SDE II — How has it been so far

Around a year ago, I joined Amazon Development Centre India as an SDE 2- that was the beginning of a thrilling adventure that was unlike anything I imagined. Amazon’s culture is truly unique in what is called within a “peculiar culture” and is a thing that fosters trust, innovation and efficiency. The moment I became aware of the guiding principles on which Amazon operates, I realised that Amazon’s success is not a coincidence- rather is the result of relentless pursuit of customer obsession.

Amazon’s guiding force — The Leadership Principles

At Amazon, almost business decisions, hiring processes, talent assessments, promotions and even the design and development tenets are all firmly rooted in their renowned Leadership Principles. These are 16 principles that serves as a compass for every “Amazonians” in everyday decision making and guide day-to-day operations. These are sometimes conflicting but encourages the employees to strike a good balance between these aspects in their work, behaviour and anything that concerns Amazon.

The “Peculiar Culture” at Amazon

I noticed this word in various onboarding materials that I received before I joined Amazon. I initially thought it was a brand-selling gimmick, but realised that it was true to the letter. There are various things at Amazon that would seem peculiar:

1. Writing at Amazon– Amazon believes in written materials and follows a no-powerpoint culture. There are various templates available for various use-cases (and no, these are not like the document templates for design, requirements etc.). To name a few: “One-pager”, “Two-pager”, “Narrative” etc. These are reviewed thoroughly by peers and other “key-reviewers” before an action is taken. In fact, everyone is required to undergo a training on this writing spirit and is not only for “writers”, even the engineers, managers, QA and other roles.
2. Meetings begin with “reading time”– At Amazon, almost every review meetings start with a dedicated reading time. The host would message a link to the collaborative document in the meeting chat and propose a time check when the meeting can start after everyone has gone through the doc. People read the doc entirely (or the prescribed sections) and leave comments wherever they have questions or suggestions.
3. Emphasis on data– There is this tendency in Amazon to ask for data for anything and everything. Basically, making claims based on heuristics alone is really difficult to convince people here. It has to be almost always backed with data. Initially I was very much infuriated with this aspect, but later realised that this gives a new perspective and helps in being “right, a lot”.
4. Working backwards– This is the Amazon way of planning. Any program, feature development is worked all the way back from the experience of the customer. When it comes to planning, it is not unusual to plan backwards from a fixed date. Another aspect that I found interesting and inspiring is the PR/FAQ document, where the press released for the announcement is created along with imaginary customer anecdotes. It is usually one of the initial documents for a project, even before the project/feature is approved for development.
5. The Flywheel– Amazon tries to relate everything to a fly wheel. Similar to how lower prices promotes customer engagement which in turn promotes larger selection and sales enabling lower prices in retail, Amazon has a flywheel analogy to even unrelated functions like hiring. When Amazon hires, they try to hire a candidate better than the average person already in that position. And this seems to work.

These are just the ones I found as stark differences. There are several more to mention which I am skipping now.

A different developer’s universe

Similar to the culture, Amazon boasts a wide range of in-house development tools that makes software development process highly unconventional. From pipeline orchestration tools to an advanced dependency management system, it was fascinating to know that many of these tools existed much before similar tools came into being industry standards. And since most of those tools still powering the “builder” processes, the challenges faced by Amazon SDEs are unique. Since one cannot “Google” these issues, and lookup in StackOverfllow, a similar thing exists within Amazon, and so does for most other tools or services that aid software development.

Contrary to the popular belief, not all Amazon software/services run on native AWS. In fact, still a majority of the services are powered by the in-house tools and frameworks and hosted on team-managed infrastructure.

Total ownership

Amazon emphasises on ownership a lot. In fact, the stock component that is part of all SDE compensations is a representation of the ownership in the company. But in Amazon, this word is beyond the compensation element or the fantasy around corporate buzz words, In fact, this is the principle that binds me to Amazon and makes me feel that I am a good fit for Amazon. In here, one has unlimited scope and possibilities. There are no clear definitions on what a job role must perform, and that means there are no limitations. As an SDE, I found it difficult to comprehend yet rejuvenated that my role here does not limit me to building software. I have been part of defining what to do with the product, how customers should get to experience something that we build and sometimes deal with even the legal and policy aspects of it. That means a lot of work, but also better freedom.

Another aspect of ownership is the “on-call” or “OE” efforts that is infamous in Amazon. Amazon has a philosophy of ‘you build it, you run it’, which means most teams maintains and support the services and products that they own. This would result in the development team directly being exposed to customer and maintenance issues. To enable smooth continuity of work, Amazon has an on-call system- which is a rotation in which an on-call would be responsible for all the issues within the on-call period. Any high severity issues would be paged directly to the on-call and would need to be responded to within a couple of minutes, regardless of the time of the day or day of the week. In a way this routine helps improve the quality of the products/services since developers would be extra conscious about potential risks that might result in a page at an odd time of the day.

Benefits of working in Amazon

Working at Amazon is very rewarding. The salary, the amazing work environment, exceptional people, world class infrastructure and all are part of that experience. But contrary to popular belief, discounts on Amazon.com (or Amazon.in) or free Amazon devices is not one of them. Similarly there is no free-food that is usually reminiscence of Tier-1 companies. Amazon believes in “Frugality” and is really shy when it comes to offering any 1st party products or services to the employees at discounted (forget free) rates. Even developers working on Prime Video teams do not get a free Prime Video account, at least as far as I know. But we do get to be part of the change that directly affects millions of customers.

Conclusion

My one year at Amazon has been nothing short of extraordinary. I found myself resonating with most of the Amazon Leadership Principles and the sense of ownership that Amazon instills in its employees. As I look back on my journey, I can confidently say that Amazon has not only enriched me as a professional but also instilled in me an unwavering passion for innovation and customer-centricity. With each passing day, I am excited about the boundless possibilities that lie ahead in this dynamic and trailblazing company.

Disclaimer: While I do work at Amazon, whatever I have written here are my views and do not represent that of Amazon.