I asked what will I do as part of my job: who is the manager, how many people are in the team, what is the tech stack, what are the engineering practices.

The recruiter connected me to the hiring manager. I was finally able to get some information about the actual job — and that was the very first time I got some impression about what is the job about. It was Java-centric Amazon eCommerce Payments team. They had real-business projects, the tech stack was Java-based, CI, tests, code-reviews, team events… looks ok.

I signed the (virtual) papers.

5 months at Amazon

Besides overall excitement caused by moving to a new place, I was intrigued to join Amazon and to explore the company as an insider — it is one of the great tech giants, and I was wondering how does it look like.

I met very smart and talented people, I met good people at Amazon. They were brought by the company from all over the world — China, Argentina, Pakistan, Ukraine, Turkey, Russia, Israel, Vietnam, Hungary, Germany. Later I discovered that it is quite common for Vancouver (and seems like Canada’s metro-areas) to have such multi-cultural concentration of professionals.

I joined a team within Amazon Consumer Division — that is part of the company that’s responsible for its online shopping business (more or less). I’d love to share more details about the team itself, but I am not sure what are NDA limitations. I can say it was kind of classic old-school team with Java-centric “invented here” Amazon stack (internal set of tools for source code control, managing dependencies, CI and CD). There wasn’t any scary operational load or ugly legacy systems to support — i.e. it was quite a “sane” team.

I was overwhelmed by online “cultural” trainings about the company’s leadership principles and other corporate bullshit, I felt like I am joining a religious organization and being brainwashed.

Supposedly, every employee should be guided by the leadership principles during their day-to-day routine. The principles actually make a lot of sense, when used appropriately. As time went, I discovered that the most common application of the principles was to creatively find a leadership principle that best supports the situation.

Wasn’t your ideas accepted by someone? You have to earn trust.

Want to justify particular solution? Show it supports customer-obsession principle.

Want to convince someone to do tedious work? Insist on highest standards.

Want to round a corner? Invent and simplify.

It took me some 1–1.5 months to start feeling comfortable with the environment. Teammates were helpful and friendly, management was demanding but friendly.

The team’s product was highly dependant on other services and was subjective to what is called in Amazon’s “away team” experience — that is when you need to change the source code of a service run by another team.

That was a terrible experience — the other teams neither had context nor motivation to support you, the proposed changes were pushed back, discussed in endless meetings with “bar raisers” and took extreeeeeeemly long.

I had some minor issues with the engineering practices (see my previous post). I was impressed and disappointed by the internal tools (CI, CD, build tools) because they were actually good, but not good enough comparing to current developers experience provided by modern SaaS companies.

I did see quite a lot of managerial effort aimed to create a good environment for developers — both mental and technical. I actually was surprised by the amount of time invested into “probing” team’s wellness. I didn’t stay in the company long enough to see the results of this process, both I didn’t like the methodological nature of it. I had a feeling that many of the processes were done because they need to be done, but not to achieve any result.

2 months later I could say that I became an active team player, I got some responsibilities, I worked pretty hard, the deadlines were challenging. I didn’t do a lot of coding. I would say time was distributed as follows:

20% coding

50% collaborating — writing / reading documentation or emails + messenger conversations

30% meetings

I think I could re-distribute my time, but given the fact that I wasn’t too efficient with Java (it was not the primary tool in my past experience) and had no Amazon-specific experience as other team members I found myself in this position.

My manager used to mention the term “amazonian way” while discussing the engineering practices and business decisions. I felt like the term is used to shut down an unwanted change or suppress an opinion when no real reason could be exposed.

It was challenging for me to deal with “tribalism” and “de-facto”-ism that I faced at Amazon, especially when communicating with the leading engineers. — senior software engineers and “bar raisers”— those are the guys that are trusted by the “tribe” to approve important design and architecture decisions, enforce company policies and be a role mode / authority with deep knowledge in specific domain.

My manager told me it is trust that I yet to earn — people don’t trust my judgement and I need to build good relationships with decision makers. I agreed. But that what is called “politics”. I felt a toxic culture creeping into my day-to-day routine — trying to cover your ass, trying to keep control, trying to only work on projects that contribute to your promotion, resisting to ideas, following processes blindly without being able to distinguish between important and non-important.

As time goes you start to to use the “art of fetching a principle” and see other people doing it in conflicting situations, trying to find one that supports your argument.

I did succeed to promote a couple of architectural and design solutions. It was important for me to feel impact of my job (I think it is important for every software development professional). However, it wasn’t enjoyable experience , it was painful— mostly mentally.

It was 4 months since the first day of my employment. I’ve got an impression that I have enough data to reflect on my experience at Amazon.

I talked to my peers and friends, I wanted to validate my observations. I was afraid to make a mistake — all-in-all the job was very convenient, there were quite a lot of RS units pending. In addition, I couldn’t legally have any other job because I was issued a work permit that was only valid for employment at Amazon,

5 months after my first day at office, I left the company.

Leaving Amazon

Here’s the summary of my observations that convinced me that Amazon (or at least the team I work at) is not a good place for me to stay

The (lack of) tech challenges

The major algorithmic / coding / intellectual challenges that I faced were of 3 types:

dealing with technical debt of other systems

strictly following a policy or a standard

fighting with the in-house dev environment

There were very few interesting problems that actually required to find an effective solution / optimize / enforce security. It would take me 3–4 years in order to reach the level of “trust” that would expose me to challenges of different scale and impact.

Leadership

I mentioned that I met a lot of talented and smart people at Amazon. However, people that were distinguishably “successful” and “important” for the organization — i.e. SDE3, “bar-raisers” and managers, weren’t as much “role-model” as I wanted.

Moreover, I saw quite a few senior engineers and discovered that I do not want to be alike… Either professionally incompetent, either political or arrogant — those people successfully managed to navigate their careers and be recognized by the company (and company’s culture) as leaders.

What does it say about the company?

Stress and nonsense

The 5 months at Amazon was the most stressful job I ever had. It came in many forms, some highlights from my personal experience:

Pressure the management put on the team (which is applied on the management by their management). I mean not healthy pressure — e.g. reminders that it is your responsibility to finish a task, although you’re dependant on a 3rd party to do their job aka “away team” experience.

Semi-legal business trips to Seattle to close gaps and to speed up processes. The management expects you to be ready and spend your 6 hours of personal time driving to / from Seattle. Although legally you are only allowed to go US for trainings or meetings, however, you can find yourself driving (or taking a bus) to Seattle at 6pm Wed, working in a conference room during the next 2 days in order to meet a deadline. I have seen people doing that… The other day I was interrogated for 20 minutes by a border officer and was almost deported at US/Canada Border because I mistakenly stated that I go to work for Amazon at Seattle. I could be denied an entry to US for the next 5 years!

Endless policies that make no sense. The management has no problem sending employees to Vegas for AWS 4 days conference that would cost 5000 US$ / employee, but you’ll need to work hard to get an approval to spend extra 80$ for a good room for a business trip to Seattle.

Promotion

When initially I decided to accept the job, I mentioned that I hoped to prove that I am good and to be promoted quickly. Sadly, that is not how it works.

You won’t be promoted for doing your job, you will be promoted by focusing on your promotion.

To get promoted from “junior engineer” (SDE1) to “an engineer” (SDE2), you get a “form” that lists what is needed to be promoted, e.g.:

code enough

code well

do some support-related stuff

write some documentation etc.

Unless you are mindful to have this form filled, groomed with good leadership principles, you won’t get a promotion.

It is not enough to get your job done and help the company grow.

Edit: I would like to clarify the statement above — by writing “get your job done” I mean: do your job in excellent manner, outperform, and what one of commenters phrased as “exceed expectations”. It wasn’t the right use of the term, so I feel the need to clarify. I don’t expect to be promoted “just” by doing your job. I want to be promoted by being extraordinarily good and helpful at doing my job. Not at writing promotional documents.

The promotion process from SDE2 to “senior engineer” is similar — you get a bigger form and you need to be lucky to:

have a good manager

be a part of good projects

be promotion-oriented and to constantly improve the form

be political and have a good recommendations from peers (but not all peers — only those who matter)

It is not different from other big companies, of course, and it is kind of industry standard, but I like the idea of being promoted because you are good and valuable to the company — the company compensate you in return with responsibility and benefits.

Compensation

This is a common issue for companies that provide RSU as part of their compensation, but what is more problematic and manipulative is how companies use RSUs to mislead employees about of their compensation package.

To be fair, all-in-all Amazon pays quite well, at least comparing to Vancouver metro area alternatives. Not as well as other big tech companies.

For example, let’s say you are offered 150k total compensation. The composition is:

110k base salary (that is what counts as your income for most financial topics — e.g. mortgage, banking privileges etc.). Note, that when you get an employment verification letter — that’s what appears as your income level. That is the promised income you get from the company.

25k signup bonus — that’s how a company will lure you into the contract. It is important to realize that bonuses are taxed differently, in my case I could see only about 50% of the bonus in my bank account. Sadly I discovered that too late. Update March 2019: as one of blog readers pointed out: “…bonuses are taxed as income — they are taxed the same. It’s just that it’s based on what they estimate you’ll make at the end of the year. That is, you’ll get your bonus money when tax return comes.”

15k RSU paid at the end of the first employment year. The idea is share company’s success (which is supposedly expressed by stock price) with an employee, making him work harder to make the company successful. In reality in such a huge companies no employee has any effect on company’s success, and the stock is highly affected by global trends or politics. At the time of writing this post AMZN was selling for as low as 1598 USD. At the time I was proposed the contract, the valuation was around 1650 USD. So, effectively, a company would not meet the promised 150k / year. In most cases stock price would go up, but then at the next performance review you will be told “Hey, your total compensation is 190k — looks at the stock price, so we’ll increase the “base salary” only by 3% to match the inflation growth”. How would your boss or recruiter respond if you’d say “I would work approximately full time job, may be”. Moreover, the more you stay at the company, the more your income composition is based on RSU. It works pretty well for the majority of the industry, as well as for Amazon. That’s industry standard, and I think it is manipulative and misleading.

Summary

There are a lot of happy and satisfied Amazon employees, there are a lot of smart, talented and good people I respect and love that I met while working at Amazon.

The company is so huge that it’s hard to manage it without having strict policies and well-defined processes. I don’t know whether my experience is applicable to the rest of the company to other teams within the company.

Probably I am just not kind of a person (well, at least for now) that fits the company’s culture. But I do want to write down my observation in hope, possibly, to help others build the right expectations before joining Amazon as a software engineer.

May be later in my life I will change, and reconsider this article, may be another team within Amazon would be a good fit for me, but for now I consider Amazon as a great and unique business, but just an average place to work at.