Well, it was actually just 11 months, but it makes more sense to round it up.

This happened a bit over two years ago, which in software developer time feels very far away in the past, so I think it makes sense to talk about it.

On 2022 I got an offer to work on Amazon in a sort of unexpected way. They actually contacted me two years before, but at that time I just started a job and didn’t want to move so early. But they came back asking, and I did the interview process without thinking that it would lead to an offer. But here we go in the peak of the software hiring craze, this was just in the aftermath of COVID, and I got an offer.

The process was a bit funny, as the initial offer was to move to Spain. For context, I’m originally from Spain, but I’ve been living in Dublin, Ireland, for the last 15 years now. I’m settled here and I like it. The interest from Amazon was for a team that’s based in Madrid (which is also my home town). In the initial talks with recruiter A I explained that, but I think that was lost in the weeds when recruiter B came along 2 years later.

So the initial offer conversation was a bit like: “We are interested and we are going to help you with the move, etc.”, “Hey, wait a sec, I’m not looking for a move”… So there were some later discussions about that with the hiring manager on different options. The salary offer in Spain was also much lower than the salary I was on at the time, so that was also not really making it interesting.

So, finally, they came with a more interesting offer, hired in Dublin, but working remotely with the team in Madrid. There were some things that weren’t great, like:

• It was using Java, which is a language that I don’t know that well, and that I didn’t like. The “way of doing things properly” in Java is weird for my taste and sort of antithetical to my thinking. I consider myself a Pythonista. But hey, tools are tools.
• I perceived the title to be a step back in my career. I was working as an Architect at the time, and this was to be Senior Engineer (more on that later). I know that titles are a bit silly, but it took me a great deal of time and effort to break that barrier, so it was a bit let down by that.
• I would like to work on smaller environments. Navigating in big companies is not natural to me, and I feel a bit like a number. And I think that I develop good skills to work in small environments, where I can be less specialised and better able to help. Amazon is one of the biggest companies in the world.

On the other hand:

• I’ve never worked before in a FAANG company. I could learn stuff, and worst-case scenario, I’d got it on my CV. There are also good opportunities to move internally to different teams, which could alleviate some of the tech stuff.
• Even if the title is a bit back, I may be able to get a promotion.
• It was a good opportunity in terms of salary and projection.
• I’m interested in performant and scalable systems. Obviously Amazon systems are very big, which was appealing to me.

So I decided to accept the offer. I don’t know, they have been insisting for a couple of years, and I really like that. Also, the worst thing that could happen is that I didn’t like it.

The work

Something that I realised quite quickly was the fact that the title that I was hired to do was, well, lower than I thought. I thought that I’d be hired as a Senior Software Engineer, and I actually was hired as SDE II. Again, titles are a bit silly, but there was a bit of confusion over the process. Anyway, it was all good.

While a lot of people assume that I worked in AWS (Amazon Web Services) I worked on the Books organisation, the shop part of Amazon. This is the oldest part of the company, and it probably is different from other areas, so my experience may be specific for it.

Even if the shop (and Books is already a subset of it) is a smaller part of the whole org it is HUGE. You can feel from day one the sheer size of it, by the amount of things that are automated or done in a way that only makes sense for a massive organisation.

Peculiar culture

Amazonians (the name people working in Amazon gives themselves) are quite proud of their “peculiar”¹ ways they work. There are many things that are done in different ways

Leadership principles

The one that’s pretty obvious are the leadership principles. A collection of guidelines that are expected to be followed by everyone. These are a bit different than “values” in other companies as they are a relatively long collection. They are present everywhere² and there are a lot of idioms within the company reflecting on them. For example, people don’t “research” or “spike”, but “deep dive” instead. It’s quite easy to notice that someone has been in Amazon because they’ll use those idioms casually.

You can be very cynical of some of those principles (really, is Amazon embodying “Strive to be Earth’s Best Employer“?), and the fact that following all at the same time requires imagination (you can easily think on scenarios where “think big” and “frugality” are at odds), but the fact is that they are used as a tool to set expectations and to shape the culture of every Amazonian.

Independent teams

Amazon works with small teams working in a very independent way. The coordination is mostly team-to-team, with not that much hierarchical communication going on.

The result from that is that you are expected to communicate directly with a team with almost no connection with you. And receive requests from teams you’ve never heard of. Without much of interaction from a manager to shape it up or give context.

There’s a lot of semi-automated work for coordination, like requesting access. This was, in fact, a significant part of my work, and worked like this: You update some code that requires access to a particular endpoint of an API which was not access before. You need to request access to that API, to a team that’s very detached from you, through a tool. Then there’s some back and forth with the tool filling the proper information, clarifying why you need access, etc, and finally it gets approved. Then you realised that there’s some other permission that’s blocking your change to be deployed and you start the process with the other team, rinse and repeat.

When the situation escalated from tools to more involved communication³, it could be challenging, as it won’t fit the “standard communication”. As the company is so big, many of the processes need to be adjusted for scale. In my case, the worst case was the communication with another team where there was a disagreement of ownership. Ownership is obviously enforced strictly with tools, but in this case there was a bit of a blind spot, so my team argued that team A owned X (as the tool said) and team A said that we owned it (as it mainly affected us and not their objectives).

I spent a big amount of time with this back and forth, without reaching any particular agreement, and I was requesting my manager to escalate the situation to have a solution. But there was a big reticency to do so, instead expecting the teams to solve it themselves.

Expectations of growth

The whole culture is very very oriented to growth and, more specifically, being promoted. There were a lot of talks, documents, messages in internal chats, where the main objective was, essentially “how to get promoted”. Not everyone played that game, but you could see that a lot of people did, and focused intensively in “promotable stuff” and show up as promotion-worthy stuff.

The company is also incredibly young. Most of developers were much younger than me, in their 20s. To the point that one person on my team, who was around the same age as me, told me that he felt isolated many times, because he never had much relationship with people on the company. They were at different life moments.

Internal tools

All the internal tools, with some exceptions like Outlook, are Amazon-developed ones. They all are very tailor for their use case, and have sometimes strange and unintuitive usages.

The worst case to adapt for me was the specific names and concepts. There was enough people around that had been in Amazon for a while, so when I was trying to ask for something, they wouldn’t recognise the name that I used. For example, it took me literally months to find out where could I check logs from production. I was talking about some tool similar to Kibana, or Loggly, or similar tools that allow full text search. But everyone I talked to showed a baffled expression, saying that there was nothing like the thing that I was describing.

I finally discover that there was an internal tool that does that (I forgot the exact name, but it was an acronym), but it works in a different way, as you couldn’t do full text search, more like adjusting filters. The goal was the same, though, being able to check the production logs. Everyone was using it, but they didn’t understand what I was looking for.

My work was, in many cases, more related to learn how to use all those tools effectively (and navigate finding out how to ask for things so I could be understood) than my ability coding⁴. There was even some feedback about “please use the right nomenclature for things, because we cannot understand you” in my review.

On-call

As each individual team has a clear field of ownership, and teams are localised in a single place, that means that you need people on-call to support problems. If you think about it, it’s quite insane that a company the size of Amazon, with workers across the globe, requires people to be on-call and wake up in the middle of the night instead of hand over problems to a different time zone, but that was the case.

Our team’s on-call was particularly gruesome. You’ll be on-call for a whole week, and the expectation is that you’ll spend all your time working in on-call tasks. There was a big queue of stuff already when you start your shift. From automated alerts to a lot of other tickets that come from different teams. It was difficult to catch up.

Remember what I said before about team-to-team communication? Well, teams have a way to push for their demands, by creating an on-call ticket for their requests. So that was a very common occurrence. A lot of the tickets that were assigned, sometimes with enough priority to wake you up in the middle of the night were things like migrating code to a new version, or deprecate something. IMO, that’s not on-call stuff, but something to communicate to a manager to get prioritised.

The other aspect that made it difficult was the expectation to take care of everything on your own. Typically, the on-call person is just the first responder and will perform triage. They analyse the situation, but in many cases, the tickets are then distributed across the team. Or prioritised.

That was not the case, the expectation was that you worked on them for the whole week, have a really rough week, and then leave the garbage pile ready to the next one in line⁵. Every time was a horrible, isolating experience.

I was actually praised because I finished some in-progress tasks after my shift. I had the context and they were mainly to send some emails and get some approvals. They were easier to carry over by a single person than have the context switch.

Let’s get together to read

Amazon culture is very text-oriented. No Powerpoint presentations, more written documents. A pretty weird idea is the fact that there’s no expectation that you’ll need to read something before a meeting about it. Instead, the start of meetings is spend in everyone just reading over the document and adding comments. Until everyone says “I’m done” and then the discussion starts.

In other companies, you’re expected to read a document before the meeting “to not lose time”, but instead, in Amazon, that time is included in the meeting itself, so it’s self contained. You can get your calendar full in meetings that you’ll always have time to read the documents for them.

It’s a very strange situation the first few times, but, if you’re able to get over the weird feeling of “we are loosing time, why are we having a meeting when people are not ready?”, it can be pretty productive. You just allocate the time to read differently, and try to make a shorter meeting because of that.

The change

I was in a strange time in Amazon, because it was at the end of the “COVID hiring craze” and the start of the downturn that followed. Very abruptly it changed from intense hiring to layoffs.

As I said before, the internal culture is very driven to growth and having a career in the company. And, unfortunately also to arrogance or even hubris. This is common in tech in general, but in big companies is easy to end believing that you’re one of the chosen ones. Or at least, that “you’ve made it”. I guess that adding very young people to the mix doesn’t help.

The announcement of the layoffs felt like a disturbance in the Force. The internal channels went on fire about it, and you could hear a lot of broken dreams there. Both for people that were laid off⁶ as well as people that were scared to be laid off, or that suddenly got a really different idea on when they were.

Morale was greatly impacted.

The next blow was the RTO policy. There was a lot of uncertainty on what that mean, and there was a lot of push back from a lot of people, that went to create pretty thorough reports on why it was the wrong idea. Hey, Amazon is a data-driven company, right? We can present data. It didn’t work.

To me it was also a weird situation. I was working remotely from Dublin, were the whole team was based in Madrid. My manager told me that it didn’t make sense for me to do to the office. But the policy explicitly said that I would have to go three days a week to the Dublin office “to better get the collaboration culture”. Even if that will mean to basically have to Chime⁷ to the office in Madrid.

Not really for me

All this didn’t help a lot on how happy I was. I didn’t really fit during all my time there, but the prospect didn’t really look that bright moving forward. The first 6 months had been already tough, and I was waiting until the Christmas break to think about whether it was working for me.

Just right before the break, actually it improved, and I felt a bit better, but just coming back it was horrible, starting with a pretty bad on-call week. So I decided to move on.

I think that my personal view on different things didn’t match the strong Amazon culture. Also, my strong points in terms of technologies, knowledge, etc weren’t really useful in the environment. My feeling was that I was on rails, following a very narrow path. I had the impression that the kind of things that I can contribute weren’t useful or welcome, and I like to feel useful.

Probably the team I landed didn’t help, as it’s a difficult team to work in, there’s a lot of legacy code to take care of, challenging from the point of view of the on-call, etc.

There was also managerial stuff that I wasn’t very happy with. I think that a lot of that is, simply, the “Amazon way of doing things”. Also I had an initial manager that was new to the company, and then I changed to another. All of that in less than a year.

So after 11 months I moved to the next role. Where I am way happier that I was in Amazon.

Final thoughts

Ultimately, it was just not a good fit. I got that feeling probably from the start, but I guess that I wanted to give it a try. Too big of a company, and I think it didn’t play out to my strengths as an engineer.

The culture was also not a good fit. Too aggressive, to the point of being cutthroat sometimes. People were more focused on their personal objectives than in teamwork. Plus a lot of arrogance, something that I’m quite sensitive to. I don’t like it.

In terms of what I learn there, it’s interesting, because probably I consolidated more ideas that I had been exposed before. I worked in Demonware, an online services company that runs services for Activision (the biggest game was Call of Duty). There I was exposed to how to work on very big systems. It’s probably not as big as Amazon shop (nothing is), but the gap is not massive. A lot of ideas are very similar, so they were good to validate with a second, totally unrelated application. The architecture of the system was also designed to allow many developers to work without being able to bring the whole thing down, but at the same time it felt very constraining.

So finally at least I was able to confirm that very big companies are not for me.

1. Yes, that’s the way to refer to it internally. ↩︎
2. They are prominently displayed in different walls in all offices, for example. But also referenced in documents, surveys, reviews, etc ↩︎
3. There are also “office hours”, available slots for a team to give support to other teams. They are great to ask information, but not so much to get certain team to do something. Every team is very protective of their time. ↩︎
4. I actually didn’t write that much code in my time there. ↩︎
5. Hopefully, a slightly smaller garbage pile ↩︎
6. Fortunately, my team was not affected ↩︎
7. Chime is the internal tool equivalent to Zoom. Didn’t I say that most of tools are Amazon-developed? ↩︎