I've worked at Amazon for 10 years on 3 AWS teams and 1 Retail team.
The most I ever worked was on a project a couple of months before re:invent when I did 60 hour weeks.
The rest of the time, it was mostly about 45-50 hours/week.
681 karma · joined December 8, 2016
The most I ever worked was on a project a couple of months before re:invent when I did 60 hour weeks.
The rest of the time, it was mostly about 45-50 hours/week.
"Women would fail interviews and be passed to the next stages anyway." sounds like it but the next stage isn't an offer - it's the onsite interview. If Google's process is anything like Amazon's, there is a screen-OUT stage and a screen-IN stage.
The screen out stage is primarily there to make sure not to waste the time of the full onsite interview loop. It's highly subjective and you are SUPPOSED to err on the side of letting people go through. You're SUPPOSED to have the most senior engineers on the team do these screens. But people frequently don't. They introduce their own biases, and managers use phone screens as practice for their most junior interviews. The outcome is qualified candidates sometimes don't even get a chance to prove their worth in an onsite loop.
So is it fair that some semi-qualified man didn't get a chance to prove their worth onsite but some semi-qualified woman did? No, but there is no way to make this process truly fair at the scale that FAAMNG hires.
So long as the FINAL process is fair, that's all that you can really do and ensure you don't hire unqualified people.
> They organised hiring events from which men were forbidden from taking part. And so on.
That sounds so much more insidious than it actually is. This is no more discriminatory than Women's Only universities. Or HBCU's. Amazon also does "women's only" hiring events. They have lower hire ratios because there is a pipeline intake problem too in our whole industry. But that's okay.
> More problematically post-hiring there were no real controls, so women were unfireable. Women who caused so much trouble their team rejected them weren't fired like the men were, but rather were endlessly moved around between teams. Hiring isn't perfect so if you filter out the bad men and leave the bad women, it's the same as lowering the bar for women - the bar lowering just happens at a slightly different place.
I have serious doubts of the reality of this statement. PEOPLE are essentially unfireable. It's extremely hard to get fired from a FAAMNG company once you're in. What you describe happens to all employees (being moved between teams).
> Firms have been given carte blance to discriminate against men by western governments
Just what way are you being discriminated against or oppressed? Making it easier for women to apply does not make it HARDER for Men. All the initiatives we discussed are IN ADDITION not INSTEAD OF.
This is frequently misunderstood by people outside these companies (and frequently by people inside them too without integrity).
You're supposed to meet goals without compromising on integrity or quality. e.g. you can't ship buggy messes.
And you can't hire substandard employees. There are mechanisms ("bar raisers") in place to do this, at least at Amazon.
I suppose I can't speak for Google, Facebook, or Microsoft. But I'm pretty sure that it's exactly the same and what you're getting is a game of broken telephone where an ambitious goal in a high stakes environment gets re-interpreted as a quota.
BTW, you're supposed to fail ~20-30% of your goals at Amazon, or you didn't set ambitious-enough ones.
If that were true, people wouldn't pay for it...
Then, as the scale increases, and the number of features increase, so do the number of teams.
Lambda and CloudWatch are both a couple hundred people which wouldn't be surprising once you consider all the things that they do.
But I would venture a good half of all AWS services are built and run by one team of 10-12.
Amazon and AWS is a massive multinational corporation with development teams around the world. Including Romania, where we had a dev center for a very long time: http://romania.amazon.com/#/
There is no such thing as the AWS profit machine. All dev teams around the world operate with similar levels of autonomy and responsibility. It's just that some of them are working on super internal systems, some on super external, and some open source. Some make a ton of money, and some don't make any, but are beneficial to the overall developer experience/ecosystem, and so make sense.
I know this is a popular narrative, but as someone who works on AWS, I think you would be shocked by how small the individual dev teams are that build and maintain the services that everyone uses.
I'm not going to downplay the network effects involved. Of course AWS has a tremendous advantage in being able to standardize the customer billing, IAM, and EC2 Usage.
And there are economies of scale.
But individual AWS service teams are: * incredibly lean and focused * still have to make a profit on their own terms based on the infrastructure they build and the fees they charge customers * laser customer obsessed to solve people's (developer's) direct needs.
I understand the community's concern about AWS investment and approach to OSS. But I can assure you (though you have no reason to believe me) that the goal is never to embrace, extend, then extinguish. It's all in the service of going where the customers are, and solving problems that they tell us they have. The profits are a byproduct. The "working backwards" process is no joke. We spend a lot of time figuring out what is the right thing for customers to build, start building it, and THEN we think about how do we make money from it.
Amazon also has been running internally on containers for years before ECS. But workloads for massive FAANG companies designed by FAANG engineers turn out to be quite different than most AWS/GCP customers.
Just like EC2 wasn't Amazon selling its "spare capacity during off-peak" but always a purpose built service with completely isolated data centers and network fabric from day 1, the connection between Borg and Kubernetes is tenuous at best.
Honestly, I would encourage you to evaluate ECS and Fargate. Forget Kubernetes and direct instance management. Try a construct like https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws... and see how much simpler it is than all the K8S overhead.
Source: I'm at Amazon but I work on none of these services and opinions are my own. I played with K8S and am eternally confused how it's as popular as it is. I guess it gives you the illusion of not having lock in?
1) His internal tech talks are fun, peculiar, and make complex concepts easy to understand
2) His contributions go far beyond "Just S3" - though that would be enough. His low level frameworks and concepts underpin almost all complex AWS distributed systems - from databases to messages.
3) he STILL Codes, iterating on ideas, and pushing scalability of distributed systems to the next level
But no, you don't need to memorize the leadership principles themselves, and your individual stories can't highlight ALL the leadership principles. Some of them are deliberately in conflict with another.
Have Backbone; Disagree and Commit is specifically about NOT being a jerk who digs his heels in, and sabotages projects or decisions that they disagree with. Rather someone who is a team player and embraces the decisions of the group:
Are Right A Lot is about constantly questioning your own understanding and being CAPABLE of changing your mind. We literally interview for it by asking about a time your mind was changed on something important.
Ownership is about not saying "That's not my job". If there is some work to be done, and nobody's doing it, don't have a high and mighty attitude about it being beneath you. Just get it done. (e.g. Developers doing QA, Ops, Documentation, etc)
Bias For Action is about taking calculated risks.
Insist on the Highest Standards is the only one that I know jerks abuse.
I don't think of Glue as a generic workflow system the way the others are - it's definitely much more optimized for ETL use cases.
With time, I'm sure there'll be more detailed guidance on Step Functions vs Apache Airflow, but the simple guidance might be that Step Functions is a fully AWS-native (and serverless) orchestration engine. Whereas, of course Apache Airflow is an open source project with a diverse ecosystem of other plugins.
In what world is that "just ok"?
The only one that I know is not universal is "Healthy oncall".
It's not because they don't think people don't want all these things stuck at home..
Its because the entire warehouse process has been turned inside out and expanded with constant safety measures, wipe downs, disinfectants, etc. This slows down everything.
Amazon is doing a ton, and not out of altruism, but because it's the pragmatic thing to do.
The workers need to be safe so they don't quit and so they don't get sick.
We are just not bragging about it (internally or externally). And neither am I, I just feel the need to defend it from the narrative that the company is sitting on its billions while letting the mass of warehouse staff get sick and die, or whatever you are implying.
I don't know anyone that works 60 hours regularly. 50, maybe - you know including lunch.
Oncall for the vast majority of teams isn't extra hours, just strange hours. But if you get paged at night people cover for you the next day.
I didn't work on a Q4 peak team but your math is psychotic. 100 hours is 14 hours a day 7 days a week? If you went through that I'm sorry, I suspected our Ops org is psychotic, but that is too much. Still, i really have to wonder if you are exaggerating since the other 2 numbers were dramatically. Or you got an Outlier team.
My org crunches for reinvent, sure, but what company wouldn't with a massive yearly conference where/when most of the products are launched.
Yes, most legacy systems use Sable but most new development for the last 2 years uses DynamoDB.
More and more event-driven applications with highly variable throughout are on Lambda. Even on AWS Service teams.
The Sable outage had a particularly laughable interpretation by the armchair quarterbacks from CNBC. The kind of scale involved makes Oracle-based approaches completely infeasible. (the internal Correction of Error document leaked and was wildly mis understood)
And the scaling timelines involved are so compressed that no company in their right mind "dynamically scales up as a result" - it's always projected scheduled scaling. There were other cascading effects.
I know it's fun to dunk on Amazon but their commitment to operational excellence is unparalleled as public AWS post mortems after major events should reveal.
If you read the entire Correction of Error document on tbe Sable outage you'd agree, of course CNBC would never publish that, one gets more clicks by getting a professor out of touch with the realities of production software engineering to blurb some juicy quotes.
His profile says "Architect and cofounder of Simple Email Service. Creator of Cloud Desktop, a cloud-based development environment used by most Amazon engineers. Technical lead for Amazon's strategy for using AWS."
Can't get more "From the horse's mouth than that"
We are generally asked not to comment on stuff like this because of how easy it is to reveal confidential internal details.
For the record, the article is mostly wildly out of date, but others have already corrected the record.
You'd be surprised. Many many AWS services are launched by a single 2-pizza team (8-10 developers). It's in Amazon's DNA to act like a startup, ship something quickly, collect feedback, then iterate, and scale.
Rekognition will get much better in time.
* The hiring freeze is nothing unusual - ask any yellow (>5 years) or red (>10 years) badge - We grow fast and sometimes too fast and need to slow down. There are times for invention, and there are times for optimization.
* You still can and should provide feedback to managers, and ask for feedback on yourself.
* Vocally self critical got rolled up into Earn Trust. It's still a huge aspect of it, especially during hiring.
* The chromecasts are back on the site! The cold war with Google is thawing
* I won't comment about metrics - if your business team is fudging numbers, that's on you.
* It's CORRECTION-of-error not cause of error. The entire premise is to figure out how to avoid it in the future, not use it as punishment or to point fingers. What orgs do you know that are abusing this system? Name and shame them, if not here then on Blind.
The recent HackerNews Amazon hate-train has been a huge bummer and mostly does not reflect reality.
The point is to have a discussion. Why? What are the benefits of a string builder? When is it necessary? What performance characteristics should it have. What kind of questions do you ask, what kind of edge cases do you consider?
It's an interview - if you are not sure why the interviewer is asking you to re implement a standard library, ASK.
This is not unusual for Amazon - most tech companies these days ask these kinds of questions
Anyways the difference here is HR/recruitment was too "ambitious".
The SDEs have found out and we have put a stop to it.
This is sad but is not Amazons fault. The people of the western world need to demand Universal Basic Income. Maybe if the government provided such a safety net, Amazon would have to pay people more to get them to work.
There are many legitimate criticisms of Amazon work culture. It is aggressive. A lot is expected from you. The perks are nowhere near a Google's or many SV shops.
But corporate and micromanaged are the furthest thing from the truth. There are VERY few "top-down" directives. (we call them S-team goals for the SVP team). And each and every team is given a TON of autonomy, independence and ownership.
This of course has its own problems, and why sometimes some teams breed awful internal cultures that lead to NY times articles. It's why the AWS console is built with 23 different web technologies and each one is slightly inconsistent from the other. It's why most of the company's internal services are still not on native AWS (though we are essentially 100‰ on EC2).
But this ownership and independence is 90% Fabulous and genuinely freeing. You are given a tremendous amount of autonomy over your technical decisions. You get a chance to decide on the working culture and attitude towards software development that makes sense for the people on your team, depending on your strengths, preferences, projects, and customers.
Amazon is not for everybody. But it is far closer to a group of a few thousand startups than a corporate behemoth.
Also, the SDEs here put a stop to all that Proctor-driven interviewing, though sadly Amazon PR doesn't want to make a public declaration as such. Oh well.