Hacker News Reader

> Complaining about promotions seems a bit unfair since he was only there for 5 months

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.

He should not have accepted the job if he wasn't happy with the SDE position in the first place. It would have saved Amazon and him money if he would have been upfront about what he wanted.

And I'm sure that he agrees with you now. Recall that the guy moved his wife with him halfway across the globe to Vancouver to get the job, and has to move all the way back again now that he has left it (because of work visa limitations). If you think he didn't spend sleepless nights thinking through the consequences, you're (probably) mistaken.

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.

So then you do it like we used to back in the day, where we do our time (at least one year) while you look for a different job. Then your visa does transfer over. Choosing to leave before the one year is up is his fault, too.

>I didn't see anything that actually painted Amazon in a very bad light.

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.

I thought the part where they offered him an SDE I position despite his 10 years of experience was pretty bad.

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.

It's probably because unless the candidate has some external references of superior qualification (i.e. known expert) and that the case can be made to the team, then it's better to level them in at a lower level so that you don't rock the boat for your current employees. It also sets a work hard tone.

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.

Why did you accept a lower level position?

How long did it take you to get promoted back to your level ?

>Why did you accept a lower level position?

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.

On a different note. SDE1s at some place Facebook get paid better than SDE3 at your other non-web companies.

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.

Agreed. This reads like a fish out of water experience for someone expecting a company with hundreds of thousands of employees to act not like any other huge corporation. Of course there’s going to be politics, culture as religion, infighting, boredom etc.

Perhaps off topic, but are there any podcasts out there for learning to cope with or adjust to the sorts of things this guy talks about in his blog post?

Michael O. Church has interesting meta posts on engineer careers dealing with politics at big orgs: https://web.archive.org/web/20160113210613/https://michaeloc...

That’s a great question. I’m not sure of any particular podcast or episode dealing with this but I, too, wish I had a podcast or something to listen to to help me know what to expect when I joined my first startup. I’ll pass this on to the Software Engineering daily podcast and Developer Tea podcast.

Update: I’ve tweeted at both podcasts your idea as it’s a great idea

https://softwareengineeringdaily.com/2016/08/07/you-are-not-...

This takes a bold stance but it’s something

Is it that bold or novel?

patio11 wrote about it back in 2011: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

https://twitter.com/developertea/status/1059517242407374848?...

Wow your comment really made me think. I too have been in the industry for over a decade.

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.

All the people that I wanted to be like, growing up as a developer, were people who seemed more focused on their programming hobby than their programming job. Here is the take away that I noticed about those people and have attempted to apply to myself:

    * 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

It is so easy to get bogged down with bloated, dependency heavy, framework bullshit at work that product quality is distantly lost. When writing important software as a hobby you don't have to conform to a lowest common denominator for acceptance by new hires.

That's a great list and echos what I have noticed about developers I want to emulate as well.

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.

Spend a lot of time on reported issues from users. If a user is willing to spend time to report a defect spend time to ensure you really understand what they are reporting and solve it as completely as you can.

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.

>Any tips on how to be "Maintenance focused more than feature focused"

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 consider myself lucky to never had a truly horrible manager.

  I just want to go my own way and have my own small business.

If only it were so easy.

You're telling me! Software engineer != Entrepreneur

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.

I had a crisis similar to what you describe about a year and a half ago. I still wrestle with whether or not I want to stay in this industry.

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!

Isn't it incredible how much one bad manager can make you think about leaving a domain you genuily like and are really good at?

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.

Thanks for your comment! To be fair, I didn't try to convince you - I was sharing my experiences and observations :) Most chances the article is not as good as others, I am not a writer (otherwise I wouldn't have a problem with writing a promotion document) :)

I didn't intend my lack of conviction entirely as a criticism.

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)

haha :) fun analogy, may be you are the one who'd be writing - seems like you have an expertise at leaving FAANG.

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.

You may have read it a bit different from what was intended. Perhaps substitute people with roles.

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".

I had a similar experience. I worked for a consulting company, noticed all my bosses worked 60+hrs/week and decided that it was best to jump ship because life's too short to spend your 30s and 40s working 60hrs a week juggling a bunch of death marches.