Last year I wrote a couple articles about my "Amazon journey". You can read them here https://dev.to/bytebodger/how-i-got-hired-at-amazon-3ajl and...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I worked for amazon 4 years ( I left 1 year ago) as frontend mainly. First it is really wired they laid off only 1 member of a team, usually they go full org. Might have been the case for making up a number they choosed you as the newest hire.
You described some half reality about the tooling system, yes most of them are old, but the good part of amazon is that no one can stop you from changing things, indeed that is a plus part, you can do all the changes that improve the developer pain as long as you do not delay projects.
I am not sure how can an amazon pipeline be bind to ES5 as you describe, most probably what you wanted to say is that the node build version of the pipeline was old, again nothing you could not upgrade.
One thing that you miss, is that these are big companies very big, build over years, so you will find legacy code and tools, which are hard to change and migrate without the proper business justification. You have to deal with it, happens in all big Enterprises. I can tell you IBM servers run still on Cobol...
Engineering wise, in my opinion, amazon is one of the strongest company I have ever worked.
The EC2 cloud desktop was not that bad as you describe it, and you have the option to chose Mac or Windows laptops. I have developed in linux,windows,mac, and honestly the best experience is on a Mac, for many reason I will not outline here.
Documentation is not that bad, there is an exhaustive internal wiki, maybe organization of it is not great.
Pipeline, tools, monitors, automatic rollbacks, are really really at an outstanding level. I repeat engineering wise amazon, imho, is on top of many other tech companies ( I thought sometime I could not find worst places that this but I was wrong).
Said that, the real issue I saw in that company, was toxicity, pressure, deadlines, politics, promotions, cross team collaboration, adding more scope to projects, changing last minute, keep same deadlines ect.... this is I think the biggest issue. The promotion process does not depend on how hard you work or what cool stuff you did, it is purely a show off, pissing context, and how good you play with management...
Feedback are used as weapons, leadership principles are used to make a wrong point (even it is not the right way)...
And I changed, moved to another big, which I cannot say the name , and guess what I found the same problems, at a worse level, ( I was thinking cannot be worse than where I was before but ... it can actually, even much more).
but that is a story for another time
First, THANK YOU for this thorough and thoughtful reply. I'll go through it point-by-point, not as a rebuttal, but more to clarify and/or agree with your points:
Yes, it is weird. That's why I openly admitted, near the top of the article, that I was singled out. Given that my new manager loved me and I was receiving glowing feedback from inside and outside my group, I don't think that I would've been released if there were no company-wide layoffs taking place. What really happened was a combination of factors:
Even if everyone on my current team was pleased with my work (and I have every reason to believe they were), there were several people from my previous team (including my previous manager) who weren't happy with me.
Although they had no intention to strategically axe my whole team, I'm certain that, at the director level, there was pressure to identify X number of people who could be released. So when he (the director) is trying to meet his quota by identifying X number of people, he looks into my team and he sees a guy who's A. still very new, B. under a Performance Improvement Plan (PIP), and C. has garnered an HR complaint (for the non-infraction of smoking a hookah). BTW, the PIP and the HR complaint are covered in Part 2.
I agree with this... to a point. I absolutely saw that the devs are tremendously "empowered" at Amazon. And yes, they can make a lot of the changes you mention. But on my team I found that, if I even spent an extra half day working on something to improve the developer experience, and even if that still allowed me to complete all my work according to the original timeline, my manager was still... annoyed.
That being said, I did do numerous things to improve the developer experience. Specifically, I ensured that none of the new devs who came on after me (there were several) would ever have to go through the same headaches.
First, you are correct about Node versions. On my "main" project, me and another senior dev worked to upgrade the Node version so that modern standards could be used.
Second, the ESLint configuration files were set to block ES6+ standards. Yes, you can change the ESLint files. But on the project I was farmed out on, the other team specifically resisted any suggestion that we would update those configurations. To be more blunt about it, they liked the fact that the code was all restricted to ES5.
Oh, sure. I totally understand that. Big/old companies, by definition, will have a bunch of big/old legacy apps. That's just part of the job. But one thing I didn't cover in the article is that, when I was hired, I was specifically given a mandate to update/upgrade the legacy app. Of course, you can't just jump in and do all those updates at once. You have to pick-and-choose what you can update and when. But I was supposed to be actively looking for ways to update the system - and that's exactly what I was doing, while still keeping current deadlines in-mind.
There's nothing inherently wrong with developing on an EC2 machine. That wasn't the problem. The problem was that, when I got there, they had no way to deploy the frontend app independent of the backend Java it was tied to. So every time I wanted to deploy/verify my frontend changes, I had to compile-and-deploy the entire frontend and backend app. That compile/deploy process took 13 minutes. Every time. I timed it.
To be clear, I eventually figured out how to reconfigure the tooling so that I could deploy only my frontend changes. That's when I was able to drop the compile/deploy process down from 13 minutes, to about 13 seconds. And I documented everything about how that was done so no one else after me would have to figure it out on their own.
You're absolutely correct that I had the option. The "issue" was that, before I was ever officially onboard, and before I ever saw our environment or had a chance to talk to any of the other devs on the team, I received an email simply asking me if I wanted to Mac or Windows laptop. Because I've been most accustomed to working on Windows, I requested a Windows machine.
Ideally, someone on my team (presumably, my manager) should've reached out to me first and said, "Look. You can work on either kinda machine. But everyone else is using a Mac, our toolset is largely tilted towards Macs, and you'll probably have a much easier time if you request a Mac." If that had happened, I wouldn't have stubbornly stuck with my request for a Windows machine. I would've simply requested a Mac. And many of my initial headaches would've been avoided.
I would never argue that Amazon's documentation across the board is lacking. Quite the opposite. They have sooooo much documentation that, at times, it's kinda mind-blowing. But with regard to the app that I was working on, there was no such documentation.
BINGO! Yes. Sooo much YES. To all of this. I couldn't agree with this paragraph more.
Yes. And I wanna be clear here. I've been in this career now for a quarter century. I know that no place is ever gonna be perfect. Every job/company/team/codebase is gonna have unique challenges when you come onboard. I totally get that.
My "problem" wasn't with the fact that everything wasn't easy for me. My problem was the blatant backstabbing and the complete disconnect from my original manager. All he cared about was covering his backside - even if he had to throw his own team members under the bus to do it.
You have been chosen surely to match numbers, PIP and HR do not come into play for new hires at all in the first 2 years. 1 year at amazon is still considered onboarding.
ohh backstabbing was a common thing there, that's how some people use to get credit, pointing fingers and playing bad..
it's quite a complex situation, after these experiences, now I just keep in mind, that we are only a number, a product, disposable (as the recent lay off showed) despite you can try to be honorable, loyal to the company and team, trying to invent stuff, put passion in the work, do best code, ect...
Most of these companies had huge profits, they still ran the lay offs... think about.
So now I am focus on leverage, I am not focus anymore on doing the best thing, but the one that gives me the most output... Edmond Lau has written a good book "The effective engineer".
That idea of "leverage" is a very good (and interesting) one. I may indeed check out that book. At the very least, it will give me some important food-for-thought as I think about how to grow in my next role.
Thank you!
It sounds like you had a lot of challenges, but you also learned a lot. I'm glad you were able to find a mentor who was able to help you. I think the advice you gave about being honest with your manager about your struggles is really helpful. I'm also interested in what you said about the lack of documentation. I've heard that this is a common problem at Amazon. It's frustrating to have to learn things by trial and error, but it's also a great opportunity to learn and grow.
On my team, there was actually a massive focus on documentation. But it wasn't the documentation that most devs think of - meaning, documentation on how our own software worked. Instead, their idea of "documentation" was to write up a sizeable document to accompany almost any of our daily tasks. Like, documenting... what you did. Or documenting... what you were planning to do. But that documentation had nothing to do with traditional software documentation. Our main, legacy app was almost completely undocumented in any way.
I can relate to your experience with documentation on your team. I've been on teams where there was a lot of emphasis on process documentation, but not necessarily on traditional software documentation. Thanks for sharing your perspective on this.
This is a great honest look at being a backend Java dev in an increasingly front end world, and I can honestly say I've had a lot of the same pain points. Keep writing and I hope parts 2-7 see you off to a better job.
Haha, I wrapped it up at 3 parts. Of course, I'll continue to blog about many more topics around software development. But there's only so much navel gazing I can do about my time at Amazon.
Looks like you're, in fact, hard to work with! :) Comparing your git commits with the ones from your colleagues is a big nono iny my opinion. Also you don't have to build the most universal feature flag implementation. It's about getting shit done and if you take weeks to even setup the project and aren't proactive regarding improving the dx, I would have kicked you out as well
Oh, cool! Someone else who can't read!
You conveniently omit the fact that I compared git commits, and PRs, and completed tickets. And you also omit the fact that I only did this because my manager was repeatedly inferring that I was somehow doing less work than my colleagues. But I guess your answer is that I should just sit there and nod along when he says these things - even though the data showed the exact opposite.
I was pretty clear in the article that I reached out, repeatedly, to others. No one else on the team was able to help in any way. I was also clear in the article that I documented the whole process so that no one after me would have to go through the same headaches.
But I'm sure you know all about it. You were there. And you obviously have all the details.
I have no details. I'm just giving you my opinion. I also wouldn't expect you to agree with me obviously :)
Are you Hardik with a different username? 🤔🤔🤔
First things first,
I like the format of your experience report. For sure ist is about complaints. Everyone complains in the SD area. That's normal. It is about constant improvement and the will to go forward. Not everyone likes it and management does not understand, mostly.
I found myself in your post in few areas. I also had troubles in the past and got kicked out of a fancy startup because I was sick of the bullshit from the management and was criticizing alot. My learning path was to watch my mouth and keep out emotions from work. Also I needed to be more patient in general. I can not expect that others have the same view as I do have. So the key was communication. Since two years I am team lead with ten colleagues in a huge project. The management is also really nice. Slow but nice and agile transformation ist just a word tbh. But I find my way in it and I care for my team's concerns a lot.
Hope you find satisfaction with your next project.
Don't mind the negative comments. There are a lot of jerks in this world.
This reminds me of an old job. Rank incompetence, self-serving managers, backstabbing culture, newbies thrown to the wolves. Only way to stay on board is to have an incredible tolerance for pain and a large helping of luck.
Sorry you had this experience. Hope your next roles are happier.
Ohh, I know that you felt with run project. In perfect world I wanna run only one command and expect that project runs
Amazon is on my top list of companies I would never consider working for - this was your first mistake, entering this toxic vortex. It clearly escalated from there. I am sorry to hear about your experience - looking forward to part 3. Godspeed brother.
I hear ya. And I can't say at all that I disagree with you. But I'll also be dead honest and admit that, when they came calling, the $$$ was nearly impossible to turn down. It was a clear deal with the devil. And I I'm not gonna act like I was dragged along against my will.
Somehow this blog entry was suggested to me by Google dashboard.
And I gotta say, I've been through a very similar experience and if you wanna talk about it hit me up
For the experienced eye ... Something is not adding up ... You couldn't do the backend .. and they threw in some devs and were successful in implementing the feature in the last min? Can you see it from different angle?
The data contract wasn't given to me until late on Friday, September 30th. By the next Monday, October 3rd, my manager was pinging me for hourly updates, wondering why my piece of it wasn't done yet. Even though I only received the data contract on the previous business day.
From that point forward, I was racing to complete the features, since I could now code against a known data contract. And I would've had them completed in several days. But I didn't even get the chance to do that. Instead, the manager threw four other devs into the soup so we could all basically code over the top of one another.
Is that clearer?