amzn-throw

For the record, being on the other side, and working hard to CREATE these experiences that customers love is absolutely addictive and intoxicating.

You have to actually give a shit about it though. Which most of us do. It requires effort and grit to have this level of "customer obsession", and to be fair, I would say we are mostly well compensated for it.

But it's not for everyone. Plenty of SDEs, including in this market just want to punch in and punch out, and not meaningfully move the bar forward. That's probably OK.

It's not good enough for me. My work is 1/3 of my life, 1/2 of my waking life. That better be fucking meaningful and significant.

You'd be surprised, you might enjoy working here too.

I've been an engineer at Amazon for almost 10 years. Been promoted twice. Ask me anything.

Yes, we're having a lot of trouble recruiting engineers, because of discussion threads like this where a lot of misinformation is shared about what it's like to work here.

Is it tough? Yes. Is it competitive? Yes. Is there stack ranking? Yes.

Is it the most fulfilling and challenging and interesting job I've had in 22 years of Software Development? (The latter half of my career has been here). Yes, yes, and yes.

This is the best job I've ever had and I think it can be for a lot of others who want to have disproportionately large impact day-to-day and on-the-world.

> You can't snap your fingers and decide that you're going to hire up a bunch of minorities to senior positions tomorrow when they don't even exist in college today without sacrificing merit.

You can, if OP's premise is sound - that you can get more diveristy hires simply by expanding the pool of candidates being considered.

I am deeply involved in hiring at Amazon, (and am a bar raiser) and we work super hard to make sure diversity candidates want to apply, are being considered fairly, don't fall through the cracks, but when it comes to the final on-site, it might as well be a blind audition. We teach interviewers to refer to candidates impartially and focus purely on the questions, and answers. The analysis and conclusions is reviewed in a group. There is no way to make a hire decision without supportive data from their performance on the coding test, or in their behavioural experience.

I can't speak for the entire tech industry, but I know at Amazon the bar has absolutely not lowered.

To be clear, that wasn't the memo text. That was Steve Yegge's pithy summary of it in his infamous Google Plus post that was meant to be privately shared inside Google to call out how/why Google is worse than Amazon at web services.

It wasn't one specific memo, but rather a series of guidances from leadership down and through the Principal Engineering community to both incentivize and require this kind of interop.

Also, a lot of folks (not you, but inb4) focus on the last 2 lines because it fits with their narrative of an idea of what Amazon is like. For the record, nobody sent out (or sends out) a memo with a "do this, or you will be fired" conditionals. (I'm sure there are extreme cases where HR is already involved and people are on their final notice. I'm also sure there might have been some anti-union-busting b.s. or how the climate change activists got fired in a way that i personally don't agree with. But it's not a standard practice)

Over 700 comments, and noone questions maybe there is a little more to this story.

For example: * Yes, he "submitted" >50k lines of code. Most of it is auto-generated from infrastructure generation templates.

* His teammates are submitting less lines of code because they're working on business logic

* Amazon doesn't let you put people on performance improvement plans because they are trying to switch teams. What is happening in these situations is that someone is ALREADY on a performance improvement plan because of a problem (and it could be technical, or it could be personal or professional), is receiving feedback for improving, decides they are not interested in working on fixing these issues, and tries to switch teams. This is when they find out that Amazon (like most companies) doesn't want you to just run away from problems by moving internally, and that you are not allowed to transfer. Then they go run to Blind or Linkedin to talk about how their manager is trying to sabotage them or hit PIP quotas.

Just saying. There's always more to stories like this.

I work at Amazon and love it and don't want to work at Google because I want to work on meaningful big projects that deliver real value to customers rather than re-writing a Chat app for the 6th time, or spending time on mandatory-top-down monorepo merges.

I think I would be deathly bored at Google from everything I hear.

Based on what I know, that's not the case.

DDB is a steady ship. The explanation on https://news.ycombinator.com/item?id=30009611 is likely the best explanation. L7 TPMs make the same money as L6 SDEs.

Getting promoted to L8 - director - is a monumental effort and likely seemed much harder than pursuing a comprable position at MongoDB.

Good for him for doing it, and for making Amazon take a long hard look at every way they failed in not keeping him.

What do you think Solutions Architects and Developer Advocates (between the two groups who do most Re:invent sessions) are?

Hell, what do you think re:Invent is? It's a sales conference.

In any company you have two groups of people: Those that build the product, and those that sell it. Ultimately, solutions architects and developer advocates are there to help sell the product.

Of course Amazon is customer obsessed. And genuinely interested in ensuring customers have a good experience, and their technical needs are met - through education, support, and architectural guidance. But ultimately, that's what it is.

The key benefit with DDB is predictability: https://brooker.co.za/blog/2022/01/19/predictability.html

Yes, you have to learn about all these things upfront. But once you figure it out, test it, and configure it - it will work as you expect. No surprises.

Whereas Relational Databases work until they don't. A developer makes a tiny (even a no-op) change to a query or stored procedure, a different SQL plan gets chosen, and suddenly your performance/latency dramatically reduces, and you have no easy way to roll it back through source control/deployment pipelines. You have to page a DBA who has to go pull up the hood.

With services like DDB, you maintain control.

Do you expect the engineers on your team to know the top sales person at your company?

This person might be responsible for the majority of evangelism and revenue for the company. Do you expect the SDEs to know about him?

Again, no shot against against Rick - he is amazing, smart, technical, competent, and a deep owner.

But the average SDE on the team won't know about these or watch these talks. There are too many deep internal engineering challenges to solve.

That could also be based on a difference of expectations in skills for a job family at Google vs. Amazon.

An Amazon Sr. SDE (L6) is expected to have strong leadership skills, which means interpersonal tech lead abilities - including mentorship of others, communication with stakeholders, etc.

This person may not have had the abilities or interest in having this so they went to Google which seems to focus exclusively on leetcode-esque abilities. (My data is ~5 years stale, but I interviewed with Google a few years back and didn't get a SINGLE "behavioural" interview question, or anything about my prior experience. It was 100% "solve this problem on a whiteboard").

AWS's mindset is software is useless without customers. Google doesn't seem to have the same care - it's a charity for academic software engineers to spend AdSense revenue on abstract high level computer science problems not caring about practical applications.

It's why most Google X ideas flame out. It's why there's a new chat app every year.

But - it's a net positive for humanity. Google publishes a lot of papers, and I think genuinely has moved humanity forward in the last few decades.

I don't have a PhD and I don't do L33tcode, so I don't think I'm smart enough to be at Google, but honestly I don't know if I would want to be.

I prefer shipping.

> Having worked at AWS previously, I can tell you that when you force your software engineers to do everything and promote them based on _what_ they deliver without caring about the operational load, you end up with crazy oncalls and poorly-designed software.

I work at AWS. While it's true that promotions can create all sorts of incorrect incentives, the reason why AWS oncall can be brutal on some teams isn't because of promotion-orientated architectures that disregard operational load.

The reason is that the company prioritizes moving fast and shipping stuff to customers. We have a deep backlog of customer asks and we want to ship them quickly. The systems need to be secure, durable, available, and fast - those are non-negotiable. But do they need to be operated automatically? Well, no, that's the easiest thing to compromise - ship quickly, have initially shitty oncall, improve operations behind the scenes.

This is usually why customers are always confused/concerned why AWS ships something new then releases no updates for a year. We don't compromise on security or durability, but we do compromise on engineer happiness during oncall for the first release. So after shipping, the immediate next step is to start improving automation and operations.

This is done with open eyes, and most engineers are happy with it to ship things big things quicker, rather than releasing a new version of chat software every year.

None of this is promotion-orientated. It's working backwards from customers.

> a VP must sign off on changing status pages, which is... backwards to say the least.

I think most people's experience with "VP's" makes them not realize what AWS VP's do.

VP's here are not sitting in an executive lounge wining and dining customers, chomping on cigars and telling minions to "Call me when the data center is back up and running again!"

They are on the tech call, working with the engineers, evaluating the problem, gathering the customer impact, and attempting to balance communicating too early with being precise.

Is there room for improvement? Yes. I wish we would just throw up a generic "Shit's Fucked Up. We Don't Know Why Yet, But We're Working On It" message.

But the reason why we don't, doesn't have anything to do with having to get VP approval to put that message up. The VP's are there in the trenches most of the time.

It's popular to upvote this during outages, because it fits a narrative.

The truth (as always) is more complex:

* No, this isn't the broad culture. It's not even a blip. These are EXCEPTIONAL circumstances by extremely bad teams that - if and when found out - would be intervened dramatically.

* The broad culture is blameless post-mortems. Not whose fault is it. But what was the problem and how to fix it. And one of the internal "Ten commandments of AWS availability" is you own your dependencies. You don't blame others.

* Depending on the service one customer's experience is not the broad experience. Someone might be having a really bad day but 99.9% of the region is operating successfully, so there is no reason to update the overall status dashboard.

* Every AWS customer has a PERSONAL health dashboard in the console that should indicate their experience.

* Yes, VP approval is needed to make any updates on the status dashboard. But that's not as hard as it may seem. AWS executives are extremely operation-obsessed, and when there is an outage of any size are engaged with their service teams immediately.

Amazon/AWS teams are so distributed and independent that it the quality of the output of one team very rarely reflects in any way on the quality of the output of another.

This is almost always a good thing.

There are of course centralizations and standardizations - the AWS SDK, Console UX, API guarantees, etc.

But Honeycode has almost no relationship to the rest of AWS, technically, or organizationally.

In 2014 most of the AWS console was written in GWT, and I worked on one of the services. Honestly? I kind of loved it. As a backend Java dev, it made a lot of sense to me, and I almost never had to touch any Javascript.

Every service team at that time chose their own tech stack, and so sometimes I would hunt for ideas of how to implement something in other team's codebases, so I got to see the different tech stacks.

For a brief moment Angular was really popular, and then fizzled out just as fast. For me, it was the worst of all the options by far.

> Of course they are if so many people are being fired.

You don't seem to understand. Amazon grows by 15-30% every single year.

We're constantly hiring, even if there is no attrition. We also have a high bar. The ~ ratio is 20 phone screens to 4 onsites to 1 hire. That's a lot of work to get a butt in a seat.

> Unless you want to get rid of someone it is better to keep your existing staff.

Only if you presume that every single team has to identify that X% of people for the URA target. They don't. Period. Full Stop. It's a lie.

> Team members can't help the new person because them doing well would mean putting yourself at risk

The #1 thing that gets asked about individuals during yearly operational reviews is "what did they deliver"? We try to identify individual contributions but individuals can't ship. Teams ship.

Even in my charitable view of my company, Amazon is INTENSE.

We set extremely ambitious goals, and orgs are only expected to meet 70-80% of them.

It's an environment that indexes extremely high on autonomy and flexibility for each person and each team.

It is without a doubt a sink-or-swim environment. But, by and large, the ability to swim is based on individual merit.

> If they had caused Sev1s or broken something critical, then perhaps justified.

That's not the metric for success or failure. It's delivering results.

No, you don't: https://news.ycombinator.com/item?id=27378836

Piggy-backing on the top-most-voted comment for those that will only read this one and not go to page 2 or onward.

Drama gets heavily upvoted.

If you keep scrolling you will find many individuals whose experience did NOT match this person (or OP's), who have a good work life balance, solve challenging tasks, and think this is the best job they've ever had.

I'm one of those people.

I've been at Amazon for almost 10 years, worked on a half dozen teams. Sure, there were outliers and a couple bad managers I've worked with, and some folks who left the company on bad terms.

But by and large, the experiences I had in 2 different countries on 2 different continents were mostly positive.

Yes, my job is tough. Yes, the oncall can be challenging sometimes too.

But I've also never stopped growing in the last decade, and have achieved bigger things than I ever thought possible.

Every single product and feature I've shipped have been immensely successful because of Amazon's deeply ingrained "Working backwards from the customer culture". And since that's what drives me - shipping cool stuff and having users on Twitter go crazy for it, I have never been more fulfilled.

Amazon is huge. There are now >60,000 Software Development Engineers worldwide. I'm not in Seattle but I'm in one of the largest offices outside of it.

So I'm sure every single horror story is true. But even so, they are a minute exception, and not most people's rule.

> Most BRs aren’t you. Most BRs are wet noodles and will just go along with whatever the HM wants to do.

Citation needed.

> 2) hire someone mediocre that’s just good enough to pass the loop, don’t spend any time onboarding them, fire them, and keep your tenured team members

You are clearly not a manager at Amazon and have no clue.

We throw people in the deep end. That, if anything, is our flaw.

Once again, if you are hiring its because you have head count. If you have head count it's for a goal. If you don't meet your goals, it's you who winds up as URA.

The best thing you can do for your team is ship your shit and get your top people promoted.

The way to do that is not waste a viable engineer on your team with a revolving door of mercy kills while you waste literally hours every week recruiting and interviewing folks you don't intend to keep.

The whole premise is so ridiculous, I can only shake my head.

Amazon has plenty of problems.

This isn't one of them.

> "Holy shit I need to hire people" means that the bar is less consistent

Not even. It's not the manager's job to determine the bar. It's the bar raiser's. And they are not under the same pressures.

We can and do veto hires below the bar.

Jesus Christ the amount of unprofessional projection in this thread is insane.

No. That could not happen. Bar raisers are hiring to raise the bar for Amazon. Period.

> It is very easy to “game the system” and get candidates past the hiring loop, BR or not.

False.

Source: Am bar raiser. 9 year Amazonian, >500 interviews. Am a manager. I do performance reviews. Yes, there are unregretted attrition rates. But "hire to fire" is absolutely not a thing.

> HMs will take even qualified candidates, which pass the BR with no problem, and set them up for failure and firing.

That is so ridiculous people are laughing at this concept internally.

Hiring good people is HARD. Interviewing takes a lot of time.

Amazon sets very ambitious goals internally, and managers are behind on them from the day they got their head count, even it takes months to fill out.

If you have a viable quality candidate available, you TAKE THEM. Holy shit do you take them.

Hiring managers are DESPERATE For people. And they will beg barter and steal for hires, and try to convince bar raisers to lower the bar to get people in.

The idea that some teams have such low-pressure goals and their managers are so loyal to their team members that they would hire a candidate just to fire them is absolutely insanely false.

If managers don't meet their goals THEY eventually become "Unregretted attrition". So if a manager has head count to fill it's for a goal, and they are way more loyal to meeting those goals as a team than to protect a good team from unregretted attrition targts.

Which by the way is also not mandatory for every team. It needs to average out across Amazon, and directors/VPs will aggegate numbers and roll them up, but ultimately if you have a team full of rockstars, none of them will be marked for URA.

I don't care what is written on Blind. Those people are fucking liars. I don't believe a single one about hire to fire.

This article and the one yesterday is just pure libel.

Not quite.

Source: Am bar raiser.

While bar raisers can't make hiring managers take a candidate they don't want, they can absolutely "veto to hire" for Amazon.

It just means that Recruiting needs to find another team, which the candidate is not guaranteed to be interested in. And that team's manager will also want to interview the candidate, so an offer is not guaranteed again.

294 comment thread from earlier today: https://news.ycombinator.com/item?id=27369910

> It's the choice of who gets out that matters.

You contradict your own point above

> has higher-ups (L7 and up) involved in deciding who performed according to the manager's expectations.

These higher ups tend to have extremely well-tuned bullshit detectors and it would be extremely hard for a manager to sabotage an employee and get them categorized as underperforming.

It would reflect worse on the manager not the employee.

That's why bar raisers have to be from a different organization than the team hiring.

As an Amazon Bar Raiser, our community takes our unbiased position and ability to veto hires EXTREMELY seriously.

We hire for Amazon, not for the team.