Hacker News Reader

I'm at Amazon now, my team is fairly shitty - let's say in the bottom third of engineering teams anyone at the company would want to work for - and the average tenure of people on the team is close to 5 years.

It's hard to get fired as a college hire. It happens, but only if you're pretty lazy or a fuckup or a mis-hire to begin with. I've seen vanishingly few cases where someone was managed out at a time that it denied them stock vests, and only once that it was even mentioned (then by an exceptionally petty manager).

To be perfectly clear: working at Amazon sucks for plenty of reasons, some of them covered in this thread. Compensation is not commensurate with the quality of engineer you have to be to work there, the company is disgustingly cheap in general, many teams are drowning in tech debt (the original post's cheerleading aside, half my org is still suffering from the slapdash way the Oracle migration was sped through to meet arbitrary internal deadlines), and the fraction of managers interested in building petty fiefdoms rather than interesting or good tech is increasing at an alarming rate. But anyone who thinks it's a huddled mass of sobbing husks with PTSD is overstating it.

Absolutely incorrect. I worked there for 3 years, saw one person fired, and everybody who joined with me ended up vesting their shares. Most got promoted too.

Shortly after I joined my team, everyone above SDE2 left and were replaced by college hires. There was literally no one around who knew anything about the original project.

Could be related to the stock development. My personal theory is that everyone who was hired around 2014 turned out to incredibly expensive, Amazon seemed to be surprised by the stock going about almost tenfold in the next 4 years. That alone made it really hard for that generation of hire to stick around, of the people I know who joined with me at that time I only know of two who were still there (out of a dozen) in early 2018. That ratio is a lot higher for those who joined before or after 2015. Not that I would complain so, including RSUs my last pay turned out to more almost three times what other companies in the same region pay.

When was that, roughly?

This comment doesn't hold up to scrutiny if you know how Amazon comp works. A standard SDE package is something like this:

year 1: $X cash + $Y cash bonus (vests daily) + $Z RSUs (vest at end of year), where approximately 95% of the comp is cash.

year 2: $x cash + $Y cash bonus (vests daily) + $Z RSUs (vest at end of year) where approximately 90% of the comp is cash. Likely a few percent more than year 1 in total comp.

years 3 and 4: $x cash + $Y RSUs (vests semi-annually for most) where the RSUs make up a meaningful part of the comp. Likely a few percent more than year 2 in total comp.

Given that comp structure, it is essentially impossible to do what AtlasBarfed has suggested, as people get paid quite quickly.

The console sucks because it's done by the individual back-end service teams who have no idea about UX or front-end coding, and don't coordinate with each other or any cross-service owners of the console.

AWS makes... how much?

And won't invest in basic stuff like that?

Their CLI is irritating too.

You might hate the console or CLI tools, but people at Amazon have real data telling them the CX is good enough and their capital would be better spent investing in other features. Source: I work there. :P

Yeah, we know you've got us locked in. The steaming piles served up in the console still taste like shit.

if you are using the console to manage your infrastructure you're doing it wrong

It's fine for experimenting, but I agree in general.

You answered the questions on exactly what is wrong with the console...

How so? Op is correct - you shouldn’t be using the console to actively manage your infrastructure. The consoles primary purpose is to let you quickly spin up resources while you explore. If you have a real business use case, all your infrastructure should be defined in configuration and deployed out to AWS. That way, you always know what you need to spin up and it’s exact, specific configuration, all stored in source control.

Because when you do that nothing ever needs tweaked on the fly? Because issues of load and scale aren't often times emergent?

I am not making an argument against what you are saying. I am saying that a common interface between the two would be the sane and rational decision. It should be trivial to use the console and turn that back into your new behavior for committing back to your repository.

"The consoles primary purpose is to let you quickly spin up resources while you explore."

And it's pretty bad at this.

I'm not saying the interfaces are the worst ever invented, just that they are a step above internal enterprise software, and despite the fact that AWS makes almost 8 BILLION DOLLARS there appears to be less that 1/1000th of that revenue invested in improving it.

What’s your problem domain? You shouldn’t be locked into AWS. No offense, but sounds like bad design or more generally, you or your engineers don’t know what they’re doing.

As a percentage of offerings, how much of the AWS portfolio is portable between clouds? 5%? 1%?

Of course we could re-write on a different cloud, just like Amazon can move off Oracle, but it would take time and we would put up with a lot of abuse before it happened, just like Amazon no doubt did with Oracle.

Which is what you were just bragging about: your numbers show that your customers are locked in enough that you can abuse them plenty before they can effectively retaliate.

Congrats.

You didn’t answer my question and deflected, only responding with personal attacks. Nice.

I still think that your notion of intentional vendor lock in is misinformed at best and poor design and architecting from your side (at worst). I do happen to work at Amazon but my post history will show you how critical I am of the company.

But nothing you’re saying is valid, and I don’t see any parallel here with the migration from Oracle. If you’ve used Oracle DB or have familiarity with its one off special “features”, there’s no parallel between that and using something like RDS or Dynamo. RDS is replaceable. Dynamo is a key value store first and foremost.

There are also enough third party abstractions that let provide you their own configuration and syntax for spinning up resources on AWS, Azure, GCP, etc or mix and match.

That was a personal attack? Um, no.

DynamoDB is not directly portable, Cassandra is closest, and it's a bear to roll your own. Are you an Amazon employee outright telling people to not use the fundamental datastore of AWS?

S3 also is fairly proprietary, are you, an Amazon employee, outright telling people to not use the fundamental file storage of AWS?

I could go on, obviously.

You just wrote that I’m abusing customers and then say it’s not an attack.

S3 is blob storage. Dynamo is a key value store with support for additional indexes. Neither technologies are particularly novel today or provide specific features that would lock you in. You could use comparable technologies on Azure or Google Cloud. Like I said before, you can’t blame Amazon or any cloud provider for poor design/architecting on your end.

Your questions are written as sarcastic personal attacks, which you write instead of posting something of more substance. It seems like you’re just trying to incite a response from me aka trolling. I won’t engage with you anymore. Good luck.

Just wanted to say this is completely inconsistent with almost all people I know who work/have worked at Amazon as developers

100% not true in my experience, but can't speak for any org other than the one I work in (which has been by far the best job, team, and management I've ever worked with).