I started to work for Amazon on January 28, 2018 — that was about three weeks after I, my lovely wife and our cat landed at Vancouver International Airport. At the time of arrival our biggest concern was the cat — 18 hours flight from Tel Aviv to Vancouver was quite a challenge for all living creatures.
The cat was ok, in fact he recovered fast and started to explore the AirBnB apartment we rented. Vancouver was, as expected, rainy and foggy, but very picturesque and different from the sunny and vibrant Tel Aviv. We were quite excited — we spent last 6 months in preparations for the move and finally it happened.
How I was hired
It all started in June 2017, at this time I was working for Rollout.io — a small start-up company, and it was about the time I started to feel I need some change. I did have 6 years of experience working for Intel Corporation, I knew what is it like to work for enterprise, I didn’t like it. Nevertheless, I decided to apply for a job at Amazon Vancouver as part of a big hiring event that was organized by the company in Tel Aviv. It sounded like a great adventure and exactly the change I needed.
The hiring process was very standard:
- online coding challenge — algorithmic questions similar to what you find online on … coding challenge sites (easy, no preparation)
- phone screening with an HR person — closed questions about CS basics: BigO notations, algorithms names, terms (easy, no preparation)
- face-to-face interview — see details below
I was notified that I passed remote screening and scheduled a face-to-face interview, I started to take the application seriously — for about 3 weeks, every evening, I spent about 2 hours practicing CS trivia questions. I used “Cracking the Code Interview” — the book turned to be useful, but I hated it. It felt wrong and time consuming. I knew I would never need this knowledge.
I graduated CS-ish faculty from a considerable academic institution — while studying I did see very smart people not being good with walking trees and calculating big-O’s. While working at the other companies, I have seen people without an academic degree being brilliant, successful engineers. I did tons of interviews (as an interviewer) while working for Intel and Rollout and I vote strongly against whiteboard interviews, but I decided to play the game.
I read 3–4 articles of ex-amazonians about their hiring experience and the interview process. Based on my experience I felt like I was well prepared.
During the interview day I met 4 Amazon employees — it all went exactly as expected — algorithmic question, systems design, architectural design, data structures questions — no surprises, questions were not too difficult. The people were polite and official. One guy was tough. Every interviewer asked 1–2 behavioural questions.
Two weeks later I got an email with good news. During the first Skype conversation I was told that I am qualified for SDE1 role, I didn’t really know what that mean. Quick search showed me that it is “college graduate” level — pity. I have about 10 years of experience in industry, but ok, may be I could do better at the interview. I swallowed my ego and decided to disregard the title, if I am as good as I think, people should recognize it and would be promoted quickly, right?
The recruiter explained me about the relocation process, we didn’t talk about compensation. The recruiter didn’t show up for the next scheduled Skype call, I didn’t get any email or explanation. (that’s quite common for Amazon recruiters).
Two weeks later I was contacted by another recruiter and she picked up the process where we left. We started to negotiate — the initial proposal was too bad. I checked the average of compensations reported at Glassdoor and other sources and built my strategy for the upcoming negotiation.
The recruiter mentioned policies that do not allow to exceed certain thresholds for a given role, she said there’s another team that approves the offer and she only communicates it to me.
3 rounds later I agreed to sign for 35% more than the original offer. 🎉
It was hard to negotiate — I did some homework, but still felt uncomfortable talking about money, the recruiter was a strong negotiator — I believe she has dozens of such conversations a day. Learn how to negotiate — it is important!
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.
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.
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.
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.
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.
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.