My career so far looks like this: startup(s) -> Amazon -> startup(s).
And if you are a new graduate or just starting to work, I recommend a similar path. Don’t try to jump to FAANG right away even if the money looks life-changing or if you think it will help your resume. In this post I’ll attempt to explain why. (I also want to apologize in advance if this post sounds like I hate Amazon. I don’t. It’s just… my experience could have been better).
The learning curve
I remember when I first started at Amazon in 2017, I got bombarded with new terms: Brazil, LPT, pipelines, CRUX, Apollo… The list was endless. FAANGs tend to build everything in house, so you will have a very painful time learning every tool, because usually their documentation is terrible. After all, why bother writing extensive documentation, if the population consuming it will 100% forget they exist after they quit?
But, once I figured out the “real world” equivalent to each tool, it became easier to onboard: Brazil was Maven, pipelines was TeamCity, LPT was Pulumi, CRUX was Github’s PR, Apollo was GitHub actions. If you know how each “real world” tool works, you will have an easier time mapping things to know to things you don’t.
Conversely, if you start at FAANG and then move elsewhere, you won’t be able to ask your coworkers “is this tool like Brazil?”, because, unless they have worked at Amazon, they will look confused and tell you that Brazil is a country.
The bad practices
The other downside to starting at FAANG is that you may learn practices that are frowned upon in smaller companies.
One of those practices is the well-known “promotion oriented architecture” that means that people will over-complicate and and over-provision their projects just so that they can earn a promotion to the next level. This will hinder you at startups, where trying to design a system that can handle 10,000,000 RPS when you don’t even have the customers to reach 10 RPS will only get you angry stares. Designing for “what-ifs” is okay at big companies, but less so in startups, where delivering something quickly is of much higher value (and cheaper) than delivering something that can scale.
Even after forgetting about money, designing a big project means that *someone* will have to feed the monster afterwards. And guess what, people at big cos leave quicker than you can sneeze. Soon, nobody will know the how’s or the why’s of that big project, and you, the new hire, will be the one tasked to pick up the pieces. At startups, if things go well, people tend to stick around for longer, which means there will always be someone that knows the why or how of things. (If nobody does, the project probably costs money for no reason and will be axed anyway).
The other practice that is not encouraged at big companies (or at least, I didn’t see it) is being proactive, or trying to take on more tasks that correspond to you. It’s very normal in big companies to ONLY work on the tasks that you are assigned, and not even think about what other teams are doing and how your work pieces with theirs (one time, I witnessed two teams working on the same project without knowledge of each other). When something breaks on some other team, instead of looking into it you are encouraged to offload it to them. I’ve seen this happen countless times and it has a name: “ping-pong tickets”. Also called “not my job”.
At FAANG, unless you transfer teams every now and then, it’s very easy to get “stuck” in the work within a team. You probably won’t get a broader vision of how the bigger puzzle works, because you aren’t encouraged to look beyond your team, and you aren’t encouraged to look for collaboration opportunities or ownership opportunities.
In startups, it’s encouraged to explore different ideas and to take ownership of things. If I see an issue in the front-end, I can go ahead and try to solve it. If I see a poorly written or incorrect piece of documentation, I can send a fix for it. If I see a CFP, I can submit a proposal for a talk! The possibilities are endless. Which means, the growth is unbounded. And because money and time are tight, you have more constraints, which fosters creativity.
The slowness
Other people’s experience at FAANG might have been better than mine, but in my case, my onboarding felt very uncomfortable. I started working on the amazon website and I had so many questions about everything but didn’t know how to ask without feeling like I was bombarding my peers. And I didn’t see everyone as puzzled as me, so my imposter syndrome ballooned. I didn’t feel fully productive until at least a year in.
In a startup, everyone is busy all the time, but because we’re a small group, we’re closer to each other so it’s easier to feel more at ease when asking questions (and if I don’t want to bother people, I read the plentiful open source docs). At FAANG, I got the sensation that everyone put themselves and their tasks first, and didn’t care that much if their peers were struggling. My code reviews never took less than a day. Everything (and I mean, everything, even getting a response in a ticket) takes at least a day. Work was very slow, and eventually, I got used to the slowness.
The slowness got so bad that I had a metric for myself called “how many times per day do I stare at the clock waiting for stuff to happen?”. At startups, that metric tends to zero. At Amazon, on some days it got so bad that i’m certain it paged an on-call somewhere.
Conclusion
Working at FAANGs has its upsides, of course. You get to see complex things built. There’s a wealth of knowledge to be found, if you know how to look for it. And the bar for operations is very, very high, and hopefully you will carry that bar to every job after it.
But in my experience they can hinder your career more than it can help it because you can fall into the “not my job” mentality. In my jobs after FAANG, nobody was very impressed that I worked there, and I can’t say that I was hired because I worked for FAANG.

