He has a decade of industry experience, took a new-grad level because he figured he needed to get his foot in the door, and discovered that the promotions process doesn't take his prior experience into account; he might as well not have worked anywhere else at all.
The real issue he has with Amazon isn't that it's bureaucratic - that there's a form to fill out for promotion, or that a variety of senior people he needs approval from seem to be fuckwits. His issue is that he wasn't treated as a person. Meetings weren't about getting the benefit of his knowledge and experience, they were about getting people to figure out how to parrot the figures produced by internal monitoring and circumstances in ways which best fit the Amazon Leadership Principles. That ultimately makes people feel like robots, like cogs in the machine. It's deeply alienating and unsatisfying - nobody really wants to work in an environment like that.
Hindsight is 20/20. The opportunity to make a FAANG salary, even if it requires putting in some time at the lower ranks, is not one to be turned down lightly.
The average computer engineering salary in Tel Aviv is somewhere around $85-95k, before (high) taxes, in a city which is the 9th most expensive city on the planet in cost of living, supposedly more expensive than New York. Level aside, $110k guaranteed, before lucrative RSUs, (I presume) lower taxes, lower cost of living... should speak for itself.
The bit that did paint them in an appalling light for me, wasn't the bureaucratic complaints, that just sounds like average corporate bullshit, you either put up with it, or you work somewhere less corporatey. The thing that I thought was really bad was this -
>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!
Fuck any company that puts their employees in that position.
It does seem like standard policy among tech companies though. I came to the US to work for Microsoft (I'm no longer there) as a level 59 (lowest SDE level), despite having almost 6 years of experience at that point. My wife (an SDET) had even more experience than me (she was a Senior SDET before we moved here) and when she got a job her company did the same thing.
One thing the author gets right is that it's not necessarily about being brilliant but being able to work in the context of the team. And this defines the promotion ladder. This is the build trust thing. It's not specifically innovative and it leaves a lot on the table (which is why people leave.. to have a bigger impact).. but after you reach the "bar" so to speak then you will have more higher level work then you can handle.
How long did it take you to get promoted back to your level ?
Isn't that clear by now? People want to get into the most famous companies. They think that by osmosis they'll be better engineers themselves, it looks good on the resume, they may be exposed to some brilliance, and, surely, once they're there, these companies will recognize their mistake and promote them into their rightful position. Not to mention that it's notoriously hard for people to self-assess their level, also because the coding gods of one company can be the low performers for another company. And personally, I have no reason to believe that Amazon, Facebook, Google or Microsoft are necessarily on either one far end of that spectrum.
Also its a tad little foolish to throw away money for designation, in your 20s when you can save up and use that money for retirement later. Especially given the fact that SDE1 and SDE3 have to both write the same code.
Update: I’ve tweeted at both podcasts your idea as it’s a great idea
patio11 wrote about it back in 2011: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Thinking back, I can not think of a single manager or lead that I wanted to be like, as well.
In fact, because of my last horrible manager, the worst I've ever had, I want to exit the industry all together.
I just want to go my own way and have my own small business.
* Extremely focused on product quality and defensive code
* Maintenance focused more than feature focused
* Excellent with documentation
* Indirectly focused on self-promotion by writing good books or producing beneficial tools
* Never directly focused on self-promotion
Any tips on how to be "Maintenance focused more than feature focused" if the culture is focused on pumping out features on tight deadlines? I have, of late, found myself engineering more on nights and weekends—trying to clean up and refactor the code that we have to pump out to meet the deadlines. However, I'd love to find a way to make that kind of work part of the day to day.
Don't wait for users to report defects. You have to constantly use the software you write. Stress the hell out of it and really try to make it fail. Write tests to ensure the edge condition is covered against future regression.
Attempt to automate everything. Adding new options and features in the previous version of my application was a pain in the ass. Now they are all listed in a single JSON file. The build adds the options into the supported interfaces as well as the documentation. Now all I have to do to add a new option is update the JSON file, add the desired result into the application logic, and write tests.
Ensure your documentation is well structured. You want to ensure all the features are mentioned, but its helpful when reading the docs if there is a uniform organization that explains the purpose, data type, compatibility, and options of each feature.
The challenge with supporting many features is that collisions of various features can result in unexpected outcomes. You have to really look for these things before your users do.
Honestly this is more "how do I keep from having to perform maintenance" but just spitballing...
Do you have defined Service Level Objectives (SLOs) for your APIs? Do you have unit tests so you can both prove changes do what's needed and that nothing else broke (regression testing). Do you have good error handling and readable error messages or is that all #todo? Are your processes idempotent? Is there a documented and automated recovery procedure if not? Add all the features you want, but if you build them to have a high uptime and resilient up front you're really combining a view into maintenance (or more importantly - not needing it) while still delivering features. And if those things aren't true then I guess making them true first before adding features is sort of what the original poster meant?
In fact, because of my last horrible manager, the worst I've ever had, I want to exit the industry all together.
I just want to go my own way and have my own small business.
It's been a brutal run so far. I'm failing at it and it's hard not to tie your self-esteem and self worth to it all.
Client acquisition has been its own brutal process, although working remotely no doubt adds to the difficulty. I’m lucky enough to travel with my wife, who has a good job in a different industry, which has helped buffer the difficulty in landing consistent remote work.
I definitely don’t regret my decision because I’m happy to busy myself with hobby or non-tech work, but just make sure you’re aware of the risks. I wish you and anyone considering the same the best of luck!
Best thing to do, from my experience, is to take some time off (if you can afford to) and get your head clear. Distance really helps.
At this point, I've read enough blog posts about leaving FAANG companies and they all paint a picture that makes me sure that I wouldn't want to work there.
This blog post didn't change anything in my mind about employment at Amazon, which was surprising in it's own way. It was an experience to read because it was different than what I expected.
It's like if you're reading stories from people who were tortured and you're cringing at every twist of the knife. Then one story is about being given paper cuts and you don't cringe at all. (not that it is a fair metaphor for something that may affect your career/livelihood like Amazon)
To be serious, I wanted to be fair with my writing and not to bring toooo much drama. And I didn't expect such exposure.
I've been in his shoes. After a few years into a job, I looked at all the senior folks (not too senior - say 2 promotions above me), and did not envy any one of them. I did not want to work hard to get to the level they were at, because either the job sucked, the work was too much, or the politics were high (i.e. you have to become a crappy person to do well there).
This is not universal. I've worked in places where there were role models, and where I felt like "Yes, I'd like to put in the extra effort to get those promotions".
The senior engineers, tech leads, and managers I've worked with are usually people with more seniority, less energy, and not much more wisdom.
It wouldn't make me so anxious, but that I'm getting to the point where I feel like I'm their position and my less experienced coworkers are thinking the same of me. I try to be better but I've gotten tired of it and I get the feeling that everyone else is tired too.