This layoff is horribly mismanaged, the whole company has been living in fear for the past 3 days since the first new articles have popped up.
Basically there has been no official communication about teams affected, amount of people affected, or time where it would be shared, and instead each team is randomly informed by their director.
This means you can never know if you are safe or not, if the layoff wave has passed or not, etc.
The past 3 days have probably been the least productive for all of Amazon's existence, everyone is thinking only about those layoffs (and I'm in an org that is supposed to be safe...).
So far there are reports of about 30 teams being shut down, but new ones are coming every hour or so.
Everyone would have preferred a clear "you're in / you're out" email at a fixed time like it's been done at Facebook, Twitter, etc. but no, we're going to be living in fear for the next weeks or months.
Unfortunately this is how it works at a lot of companies. Just a mess.
I was working at Best Buy when the stock price was $8/share... we had "Tornado Thursdays" where every Thursday for months you'd hear of a small amount of people getting notice they were laid off. I suspect they did this to avoid labor rules of notification/SEC?
Prior to that, we went through a LARGE layoff where they gathered everyone in a room, said "go back to your desks you'll see a 15 minute meeting on your calendar if you're impacted" and at the end of the day they gathered the remainder in a room and said "if you're here you're safe".
Nothing more demoralizing than living in fear and rumorville. I was at a big bank post 2008 and it was months of messages about did you hear so and so got the tap on the shoulder. You never knew when or why, you just didn't know everyday if it was going to be your last. Not exactly how you want to live your life.
No better point re: living in fear and rumorville. Same experience for me in 2008. I also saw the same effect post dot-com bubble.
Layoffs in our industry are simply part of the long term game, part of a playbook that folks coming into it in the last decade or so probably haven't experienced. My eyes were opened in the dot-com crash - I saw too many extremely smart, hard-working, and accomplished developers get dropped and spend a year or more getting back into programming gigs.
Hah yeah I worked in payments at once of the card processors, this happened every year like clockwork. 1-2 months just down the drain because everyone running around gossiping or sitting at their desk in terror.
It was such a joke, but I used to be of the belief that the card processors were so incredibly profitable, that they had to actually waste money to not be targeted by regulators too much (which monitored their profit levels to determine if they wanted to impose lower card fee rates). So these kinds of things were actually healthy for the business, along with insane travel and entertainment budgets - I used to routinely spend >$10,000 on plane flights back to HQ from Asia.
> Everyone would have preferred a clear "you're in / you're out" email at a fixed time like it's been done at Facebook
Ha, at Facebook people have been complaining that they only learned at the last-minute and only thanks to leaks, saying they would have preferred a longer-term heads-up so that they could start preparing and avoid making long-term commitments (eg that guy who was laid off one day after moving his whole life from India to the USA)
I suspect that there’s actually no great win/win way of doing mass layoffs ¯\_(ツ)_/¯
The thing is that it's the same here. I saw a LinkedIn post from a guy at Amazon that got layed off 2 days after joining as well.
The difference is that not only you get no notice, you actually don't know when the wave of layoffs is done and when you can take a break from worrying.
It's not a dichotomy between "no layoffs, no layoffs, please leave the building and never come back" and "There maybe will be layoffs but we can't tell you if you're in them or not" - in both cases the problem is the lack of knowledge.
The company could also just give workers notice. Works fine here in Europe.
It's not, it's like that everywhere. Every layoff follows the same pattern that you describe.
I don't know the exact reason for it, but if every single company does the same thing, there has to be a reason I don't know, since I've never managed a mass layoff.
Gross profit generally means profit on sales/services after COGS (costs directly related to producing/providing those revenues) but not including other costs like admin, etc.
I found this comment from an anonymous tech industry insider interesting:
"Amazon is very, very bloated. So there's lots of people there but they're not providing a lot of value so they're first on the chopping block."
This is counter to what I have heard about Amazon, which is that it is a ruthless environment where low performers are stack ranked out of the company. Does anyone have any insight?
I imagine you can get an "anonymous tech industry insider" to say absolutely anything including the exact opposite statement. Another issue with the statement is the fact it is an opinion using an undefined metric.
It's also pretty standard for an engineer to say "Yeah, I could build that in a weekend" when talking about some super scaled website like twitter or facebook or whatnot.
"Bloated" isn't for engineers to decide really, we're terrible at judging efforts involved.
Both of these things can be true. There is a lag time behind hiring someone, PIPing them, and terminating them. Amazon was on a hiring spree. They are almost certainly still be bloated even after these layoffs.
Disclaimer: I work at Amazon as an SDE II on the logistics side of retail.
> This is counter to what I have heard about Amazon, which is that it is a ruthless environment where low performers are stack ranked out of the company. Does anyone have any insight?
If you have to fire the bottom x% of your team every year due to low performance, doesn't it mean that you have a constant low performing cadre? Otherwise, why would you get rid of them?
So I don't think it being "cut throat" and there are "many low performers/bloat" are at odds.
Amazon is notorious for practicing _forced_ attrition e.g. forcing the relative low performers out of the org (who still might be performing at expectations, onboarding, etc.).
Which, unfortunately, is only so much related performance. Feedback circles and cabals are a thing. Pkus some people are better at operating those cycles than others.
> Managers at Amazon are expected to put 5 to 10% on a PIP or manage them out every review cycle.
A slight correction: An organizational unit larger than a 2 pizza team -- think 50 engineers, is expected to cut 5-10%. A team within that unit may lose 0 engineers, which is how high performing teams that meet all their goals stay intact.
Fair. But every manager must be prepared to put one of their people forward, even if they ultimately don't have to in the session. The pressure is still there.
It takes a while to stack rank people out of the company. It's not an efficient pipeline. Moreover, smart engineers know how to game the system.
So Amazon, like every other FAANG, is very bloated. I've yet to experience any sort of major layoff in the industry at large. They seem mostly isolated to these mega-corps that got PPP money, hired way too much, and are now trimming back the fat. It is sort of icing the fungibility of jobs for now but not in a way that I am at all worried about.
> They seem mostly isolated to these mega-corps that got PPP money, hired way too much, and are now trimming back the fat.
I think your general point is correct: FAANG over hired during the pandemic, but I'm not sure you understand how PPP worked or how the money was distributed. Google, Amazon, and Meta weren't the primary recipients of PPP money (they directly received 0 of it).
Their stock price increased due to both performance during the pandemic, and the general loose environment created by the Federal Reserve which probably played more of a role than PPP targeting mid-size businesses.
I also think I'm being interpreted as supporting stack ranking for some reason by some inept commenters passing by. I'm not sure how they're getting that.
There's no surefire way to game the system, and I would even say there is no way to game the system at all, but you just need to understand two things:
1. Your manager is the one putting you in PIP (firing plan). If you're friends with your manager, he won't put your name, even if your performance is below the bar.
2. This is applicable in every single avenue of life, but your reputation is everything. Work hard for the first few months after joining a team and impress your leadership and your colleagues on your first few tickets, then you can dial it down and still be 100% safe and be regarded as a top tier engineer. You will be "the guy that ramped us fast and executed well" for the rest of your time in that team. If you have setbacks, you won't even need to justify yourself, they will just know that "hey if this top guy is struggling it just means it's very hard".
On the contrary, I have witnessed people being fired or looked down upon just for having a bad reputation, even when they were doing just fine or had legitimate roadblocks on some tasks. One of my good friends got fired because he was the party guy of our team, so nobody was ever taking him really seriously.
I've done the stack ranking many years in multiple companies.
I rarely have seen (1) come into play. I'm sure it happens, but there is a lot of scrutiny of the stack rank, enough where I think it would be hard to pull off. I think most friend managers would tell their friend months ahead of time -- you really need to do XYZ or things are going to be tight at review time.
(2) is very true though. Reputation and perception is super important. Although I think companies now do take a harder look at delivered impact either via KPIs or OKRs.
In my experience, most engineers are pretty good. And I've struggled to find people to put in the bottom of the stack rank, because I didn't feel that their compensation would reflect the impact they had. IMO, after having to do layoffs, it is the hardest part of the job. And it sucks because there is very little way out of it for the manager. Helping person X do better, just means that now person Y is at the bottom of the stack.
> I rarely have seen (1) come into play. I'm sure it happens, but there is a lot of scrutiny of the stack rank, enough where I think it would be hard to pull off.
In Amazon you will be PIPed (or rather put in focus, which is a first step that may lead to PIP) if you are marked as "Least effective" which is the bottom 15%.
Your manager has to demonstrate why you are "Least Effective", and they have to demonstrate why you are "Top tier". However, they don't really have to justify themselves to put you in the middle of the pack, where you will be safe from PIP.
So, for sure, you may not be ranked in the top of the team if you're buddy with your boss, which means you won't get a salary increase for example, but at least you won't be PIPed, which in the end is what I assume most people care the most about.
Worked in a company that does stack ranking. Here's how you do 1 (in the opposite sense): Give the person tough tasks, with very tight deadlines. Amplify their failings and belittle their achievements. Repeat till the employee screws up, and start building evidence for a PIP. Get others involved (customers the employee is interacting with, your own manager, etc). In most cases I've seen, if a manager is unhappy with you, the others (customers, your manager) will follow the manager's lead to get rid of the person.
If/when the employee contests this, most HRs will pick someone from the same department to be the investigator. Since it's the same department, it means it's the same culture your manager is exhibiting. They will much more likely believe them than they will you.
Source: I got semi-fired this way. To give you an example: The investigator wanted proof for everything I was claiming in my defense. Not only that, they held it against me if I had not sent emails to my manager saying I disagreed with his behavior. Eventually, I asked the investigator: "So, did my manager show you proof for all his claims?" The investigator responded with "Good point, and once this process is over I will send him and his manager feedback on the mistakes they made." Umm - sure, but why should I be punished and not them? No answer.
I somehow stayed at the company (they made an exception for me and let me change teams) - and over years saw this process repeat over and over. When an employee is in trouble, I immediately start advising them on the steps their manager will take - it usually plays out as described above.
You can be asked to dig holes and close them up again - a completely useless work and you can be given an ever increasing quota to do it with the threat that one of the holes you dig might have your body in it (extremely stressful and ruthless).
The challenge most of the people outside of Amazon do not realize is that micro-service architecture imposes a heavy penalty on team co-ordination, esp. as the software matures. A large part of core services have been built over several years (and decades) and they have been architected to optimize for some operations at the cost of other operations. You can think of this as how you would design a DB schema. It is a trade-off between write speed, query speed and availability. Now, think about it happening at massive scale. As an engineer, you would spend a lot of time working/waiting on partner teams to prioritize your changes while under pressure to deliver. A lot of teams ended up building the pieces on their own into their own services leading to a larger maintenance and operational load.
From the outside, you are very likely to think that the team is bloated and slow-moving because you are assuming green field development. Internally, Amazon is a 25-year old legacy platform with almost no single vision across teams, tons of semi-duplicate functionality and heavy operational load. Keeping the lights on (KTLO) was a big ticket item on every annual plan I created when I was there.
I think it's actually normal for teams to have duplicate functionality. The requirements are usually never actually identical and when you try to merge them it results in services with complicated configuration that have N^2 edge cases which leads to more bugs or more complicated code. I suspect what you're describing is somewhat unavoidable, and not even a bad thing.
That being said, Google for comparison does have good code re-use for certain core resources, like spanner, cloud, tensorflow, borg, etc. If you're talking about bedrock infrastructure like that, it's quite a different picture.
I did not say it is bad. I just wanted to point out that N^2 communications are a big hit (of course we know them for long time) and people under-estimate the co-ordination effort and the fact that already running systems impose constraints that are not true for green-field efforts.
I think I am regurgitating mythical man-month here and will shut up.
> the fact that already running systems impose constraints that are not true for green-field efforts
Maybe I'm doing it wrong but I often find that doing a new greenfield project sounds easier but by the time you deal with all of the non-functional stuff (connectivity, resilience, logging, build tools, documentation etc) you might have been quicker holding your nose and bodging it in somewhere vaguely appropriate in an existing system.
There is no bad vs good micro-service architecture. It is just that micro-service architecture imposes a different kind of penalty on co-ordination and debugging. Instead of intra-component dependency, it moves it to inter-service dependency. Each service might look simple, but the complexity is moved to service communications. It is not that obvious, imho.
There absolutely are bad microservice architectures, that's a weird claim to make. Good microservice architectures minimize or entirely eliminate the friction around the coordination and debugging.
I'm working on splitting out a monorepo as we speak and I'm determining tradeoffs we'll need to make. If I do this wrong, there will be a lot of pain around navigating between the services, but there are choices I can make now that minimize (or eliminate in some cases) that pain.
I recommend you find a way to spend time with someone who knows how to design a quality microservices architecture. It will completely change your opinion about how microservices interact and the supposed "pain" therein.
If it were so obvious, I am wondering why you need to worry about doing it wrong.
You talk about trade-offs as if they are fixed in time. That is not the case at all in anything but toy systems. Maybe you need to find someone who can design a quality micro-service?
You have no idea what I do and what my competencies are, yet, you are assuming you know a lot more about system design than I do and I am missing something simple.
Can you show me where I said "building microservices is obvious"? Or if you don't believe I said that, can you describe what you think it is I'm suggesting here? Because my intent was to say, "It is obvious that microservices can be designed well and designed poorly." In fact, if you'll observe, I removed the word "microservices" from my final statement, to demonstrate that such a statement is trivially true for any given thing.
Nowhere did I say, "It is obvious how to design a good microservice." but it seems like you're arguing against that statement, not the one I made.
And for what it's worth, I don't give a hoot who you are, who Bryan Cantrill is, or what your supposed competencies are; make your argument, don't rely on your pedigree to speak for you. That should be obvious.
I think the answer is kind of obvious, but disappointing: the way to scale is to both divide responsibility while simultaneously sharing it. The way to do this well is to work on the basics: communication, training, quality, study, operations, continuous improvement.
There is no magical model for this, no buzzword, no single practice, because different businesses and use cases need to be adapted to it. But there's 70+ years of study into methods to do this, and I believe they're taught by all the business schools. It's just nobody wants to do the work.
....On the other hand, nobody teaches MBAs how drastically different tech is than other industries, and thus how you run your "factory floor" has to be different. But the basic principles above should still be applied; they just have to be adapted to the industry and work. What one should not do is just accept things however that industry does it, because they probably aren't doing the above principles either.
I really wish more people understood this. I'm working for a company that's in the middle of a move to the cloud and it feels like no one is acknowledging the sheer level of complexity being added.
This sounds like all but two of my software jobs. The greatest challenge of being an individual contributor is being beholden to the constraints of the environment. If they tell you to dig a hole then that’s what you do. If they tell you to waste all day digging into some unnecessary framework to make a single CSS change that should take 30 seconds plus a few minutes for deployment then that's what you do.
In front end development people NEED the world's largest application frameworks (sometimes plural) because they cannot figure out state management. State management is stupid simple and a solved problem, but whatever. It will still, at the job, take you all day (maybe a week) to make that 30 second change.
This is why I hate frontend so much. Frontend sits right at the uncomfortable intersection between overly complicated tech that's tough to understand, and demanding PMs and UXs who need the feature to look or behave a certain way. I initially enjoyed frontend because of the hands-on nature of it, being able to make something and then play around with it in my browser. But after the 100th time wrestling around with CSS and JS to make some minuscule style change, I just am done with it.
I super enjoy pushing innovative new front end technologies in personal projects where a 30 second fix might take as much as 5 minutes after test automation and all necessary due diligence, but at past jobs I just dig that hole they tell me to dig.
If you try to bring up that the days work could be solved in less than hour if only we didn’t make all the wrong decisions and fear the platform they will look at you like you’re retarded. I have heard this mentality expressed perfectly in the movie Edge of Tomorrow: Don’t tell anybody. Are we clear? Best case scenario you’re gonna end up in a psych ward. Worse case you’ll get dissected for study
Do you have any recommendations for resources/tools on state management? My background is in robotics engineering and I’m working on picking up front end so I can build end to end web apps for myself. Currently learning react with a lot of head scratching.
I wrote a thorough examination of state management with a code example. That essay is small enough to fit on two printed pages. I cannot share things I have written without breaking the anonymity of this account.
Here is the summary:
* You need a storage location
* You need a defined data structure to store your state data. I recommend storing everything in a single logical storage object, because 1 is simple and simple is good.
* You will need to update and save your storage object at the needs of your application. I do it on each user interaction, because this is cheap.
* On page load you will need to access your storage object and apply it to the user facing event handlers that create your state artifacts that otherwise normally execute in response to user interactions.
That’s it. Consider the problem from the goal and work backwards to the solution.
I’m hoping to grow side projects that I enjoy working on but not in the short term, hence current focus is to only build things for myself. It’s also fun and educational for me to develop my own toolbox to get a sense for what works at different scales, how to iterate quickly on features of arbitrary complexity in the same spirit as PG’s beating the averages essay.
It's not necessarily individuals. From what I saw years ago there are tons of project kicked off to see if they pan out but are probably not going to succeed. The company has some core teams around retails, mobile and AWS that do the majority of the table stakes work. The rest is a lot of team doing things that may or may not have any value. My pessimistic view is that required teams are like 10% of the company leaving 90% of maybe useful. That isn't to say the 90% should be let go. If they did you'd see no growth but it's unclear how much of it is actually useful. In good times that's fine, in rougher time they have to reduce that extra a bit.
It's because it does not talk about employee bloat, but rather product bloat.
There are a lot of teams working on either useless or _duplicate_ products.
Amazon is a place where it is frequent to discover that another team is doing pretty much exactly the same thing as you, despite both teams existing for years.
My previous team found out that multiple of our products had equivalents built by other people (even one was just an excel sheet made by some random guy :|) and my current team has a table comparing our product with the other 15 equivalent products made by other teams...
And then there are a lot of teams working on products that do not and will never bring revenue, such as a big part of Alexa.
Another way to be "bloated" is to have a lot of teams working very hard on systems/projects that don't add value to the overall business. Those teams will still manage out their low-performers and run a ruthless environment, but the folks that remain continue to work hard without providing value. Add new systems/projects underneath because people want more scope and responsibility, repeat through a few cycles, and you arrive at the quoted line.
The biggest bloat I've found in big companies is duplicate teams. You have one problem needing to be solved and a couple VP's running a program trying to make it happen under their domain.
I generally see this play out as, one team trying to tackle the problem with a prototype and demonstration of tech. The other team just acquires as many people as possible and writes a bunch of documents. Then it gets run up the flag pole and the solution seems to be to go with the team that already has all the people.
I used to see this occasionally and always see it as wasteful. However, there is another angle here. Imagine your a C-Suite or senior level manager and you have lots of resources at your disposal. Now you have identified a strategic widget you need to get to within some timeframe, say 2 years to lay into your grand strategic vision.
Scenario A: Task a single team, staff them and let them do their thing. Cross your finger and hope they get it done.
Scenario B: Look across offices, org groups, whatever, and task 2-3 (sometimes more) teams with your task. Let them start work on it and get regular demos and updates. Eventually, pick a winner.
B looks very wasteful from the outside, until you realize that many software projects fail (like 50%). So more attempts give you a higher chance of success. Downside: Internal politics, waste, attrition from engineers throwing away code/busy work.
A is great if you can do it, but you're putting all your eggs in one basket.
A lot of times this is just bad org/bureaucracy though, but it can be done to great effect.
Disclaimer: Worked for a CEO with a large outsourced engineering base and several offices. Would see multiple attempts at different offices all the time. Eventually, grudgingly acknowledged there was a method to that madness. Trump also is famous for this (although his seemed more madness).
What actually happens is Scenario C - it doesn't arise from a top-down planner mandating it, it arises from middle managers (or their subordinates) further down the food chain each trying to grow their own kingdom, who all get the same idea at roughly the same time, and each build their own solution to the same problem.
During times of plenty, or if the top-level planner is only absent-mindedly managing that part of their org, the firm will be willing to tolerate these competing implementations, but during lean times, they cut, cut and cut and consolidate down to one winning solution.
A lot of corporate politics and strategy makes a lot more sense when you start looking at the personal motivations of the participants in it.
Some orgs within the company are fairly lean, some are hugely bloated. Amazon isn't homogeneous. For example, Alexa is very over-resourced and it's common to hear about 4+ teams working on slight variations of the same project. Lots of redundancy there. I believe Alexa as an org is losing $5b+ per year. Contrast that to all the criticism Facebook is receiving for their investment into VR/AR. The investment in Alexa was a platform play. Amazon thought that voice would be the next big platform. I'm not sure results and trajectory justify the investment anymore.
Success is relative. Voice didn't turn out to be "the next big computing platform". It's still mostly a command interface. Perhaps it still could become something bigger. Alexa isn't widely used on the iPhone/iOS/CarPlay or Android/Android Auto, the two most important places for voice. Alexa works well but doesn't have a clear technology advantage vs Google Assistant (admittedly, Siri is trash).
Contrast that to VR, which is in a much earlier stage of its technology and adoption cycle: Meta has a strong technology advantage, currently has the best overall platform and _if_ VR becomes the next big computing platform, Meta is in a strong position to capture a significant proportion of market share. It's a big if! but at least there's still a chance.
Voice still has a lot of potential, especially with the advances in AI that we've been seeing recently. A robust voice-controlled interface would be immensely useful to consumers. I think the investment in Alexa voice is well worth it compared to whatever meta is doing atm.
Voice as an interface sucks for almost everything where choices exist. As a purely serial communications method you are forced to wait for enumerated choices.
As a primary interface voice was very widely used in the 80s and 90s in the form of IVRs and the industry was immediately destroyed by web browsers as fast as was possible. Nothing makes people angrier than having to go through a phone menu system and that’s just an organized version of your more general voice interface.
“Alexa set a timer” defines the kinds of interactions that are sensible to do with voice and it is very, very narrow.
From what I heard, and this was years ago, it is a very resource intensive service to actually run. Given how little I have personally used my Alexa to make or inform actual purchases, I suspect it unfortunately doesnt actually earn much.
Alexa is crazy. Close to 10K employees for a product that they don't even know how to monetize. I understand that it's part of the Amazon flywheel but there's a limit of how much you can rely on AWS to fund you.
Alexa is full of horrible managers that only care about growing their teams so that they can get a promo.
What needs to be distinguished here is retail as in Amazon procuring and selling goods, or retail as in Amazon being a platform and another version of Aliexpress.
The former is a low single digit profit margin business, the latter probably has a decent profit margin.
Alexa does seem like it has fantastic potential. To throw so many resources at it with so little result seems like an incredibly massive failure of management.
Failure for whom? The shareholders, sure. But Alexa is pretty cool. It is the first voice interaction that I have used that actually works. So good for Jeff.
I think Siri and Alexa are simply at the end of their roads. To move Siri and Alexa ahead, we'd need a general AI so powerful, it would change the whole world.
I wonder if, within my lifetime, it will be possible to tell a digital assistant to "order all the ingredients I need to bake the cinnamon buns as detailed in the cinnamon bun baking video I watched last month with the Chinese lady that doesn't have an accent"?
Based on the capability of state of the art language models, we may get that soon. The technology largely exists, but the compute is still too expensive. Rumor has it that GTP-4 will be able to pass for human-like.
Right, the missing step to make these assistants actually-useful beyond very simple tasks like "play [album name]" or "set a timer for 5 minutes"—which are basically just a voice-driven command line—has almost nothing to do with voice recognition per se and is more-or-less identical to the problem of "invent AGI".
It'll be useful when you can have it create, say, a menu and shopping list for your week, interact conversationally to tweak it including understanding that something like "I'm allergic to that ingredient" means never ever try to include it again while other statements of preference may be much softer, learn your preferences so those conversations get shorter every week, and order the ingredients for you, too. It barely matters if that happens over keyboard input or voice, because the hard parts of that problem have nothing to do with how the input is done.
even a "voice-driven command line" would still be pretty useful if it actually worked reliably. Google's implementation misinterprets my parents' address about 50% of the time, choosing some town I've never visited in another state as the most likely alternative. I navigate to that address at least once a month, and I even have it as a saved place in maps.
The voice recognition (given decent hardware and a fairly vanilla accent) is quite good. The problem is being able to integrate, present options, learn preferences, etc. even to the degree of that subpar assistant who you only keep paying because they're the daughter of your mother's best friend.
You want to be able to give a few parameters for a trip you're taking and get some choices back. But, as you say, that's far more about "intelligence" than the type of input.
There's a The Smile song called "You'll Never Work in Television Again." Last week I said "play <name of song>" and Alexa responded that it could not find a playback method called "television." I tried to annunciate more clearly and it replied "OK, playing <song name> on repeat," because the song title ended with the word "again."
Nothing reminds you about the difficulty in cleanly parsing human language more than trying to work through a voice interface. I'm not sure what is missing precisely, but I'd say "an ability to use semantic understanding" might be helpful. All of our AI works explicitly with no understanding of semantics, but it's becoming clear to me that the ceiling that places on their "intelligence" puts them still leagues away from the world of true AGI.
If there was also a screen, so many more things could be done. For example it could show that list of ingredients and their prices, for your approval. Then let’s say you could interact with that screen by voice (your fingers are sticky because you’re cooking now) or touch.
There is one in Amazon Echo Show. I've never used one though so I don't know how useful it is in practice. The thing is though that I'm never far from a computer in my house so I'm going to one of those for anything remotely complex.
The fact that organizations have multiple teams working on overlapping or even similar things baffles me. I can't imagine how that wouldn't be immensely dissatisfying for the individual.
Internally it was sold as: working together with other teams is too inefficient due to dependencies and differing priorities. It's faster to build it again independently than integrate with the existing service.
In environments where missing deadlines can have huge cascading effects it isn't unheard of to do redundant work so that you have a better shot of meeting your deadline and in a good case you have multiple successful options to pick from. When your deadlines are potentially expensive enough (think capital investment that need to be bought in time to be built out before old ones become uneconomical to operate) this approach can be well worth it.
Not all teams are created equal. Having multiple teams with an extremely similar charter promotes competition, harder work, and deeper search for synergies elsewhere. A single team with a guarded remit is not going to try as hard and they may outright fail on their mission even if they do have internal competition.
This approach was made popular by Steve Jobs at Apple. He would have multiple teams competing to who's solution would survive, while the other teams products were thrown away
This goes all the way back to his early days (I think I remember a scene about this in The Pirates of Silicon Valley), but also reportedly multiple teams were building very different original iPhones
I think this approach makes sense for hardware but not pure software.
I think its easier to adjust pure software iteratively than hardware. So with hardware, it makes sense to have different teams working on similar but different things because variations of ideas need to be fleshed (and thoughts that spawn off those ideas) and it can be hard for one team to do this iteratively.
If you're right and this is where it came from, I think largely pure software teams doing this are wasting resources, but if its hardware I don't agree its wasteful
I don't recall this coming up in Hackers: Heroes of the Computer Revolution, but it was definitely in The Soul of A New Machine, the story about Data General trying to build their first 32-bit computer.
You spawn multiple teams working on very similar projects without them knowing about each other, let them grow for a while, then choose the most promising one (or with the highest traction) as your default solution and kill off the rest. Pretty normal exploration strategy.
Amazon has about 75,000 engineers. That's the equivalent of a large town. It's completely reasonable that many people would end up duplicating the work of other teams simply because they never communicate with them.
The philosophy is "1 > 2 > 0". This means ideally you'd prefer a single thing but single things often bottleneck delivery from different orgs as they have differing requirements. In that case you'll accept overlap/duplication if it keeps those orgs decoupled and both delivering faster.
I ran into this a couple years ago with partially duplicating a service that existed under another SVP org. It didn't feel good at the time but in hindsight it was probably less effort and higher chance of success than trying to align priorities across SVP orgs and making their thing work for our slightly different use cases.
Speculative execution .... which ever team moves fast wins ... heck sometimes its not even the team with the best features that wins ... teams with just enough features but who can move fast win sometimes and its bad for the long run. Most big companies have been doing this for a long time now.
> Amazon thought that voice would be the next big platform
It turns out that there are many interaction models where Voice is clearly inferior. Visual discovery (contrast with music) such as for videos, as well as navigation in a UI, are poorly done via voice.
I have an Echo and a Homepod and I rarely use the Echo anymore because of their "by the way, did you know..." responses. They know there are a lot of users who want to disable that but unfortunately their goals aren't aligned with their users' goals.
I got rid of my Echo mostly because of those types of responses. And also for how easy they make it for you to buy something accidentally off Amazon, or accidentally upgrade to Music Unlimited.
You can say "Alexa, stop by the way" and it will disable it for a time, but it will come back. If you really want to disable it for good, you can set up a routine to effectively issue this "snooze" on by the way at some interval.
This is what happens when you optimize for a certain metric only. Yeah you might have someone's who's writing tons of high quality code, but if this code is just a duplication of another project or there is no business use for it, then it you probably would have been better off not writing it in the first place.
People talk about food waste, but how much code is wasted?
I haven't worked at Amazon, but my experience with the world of "pip" culture is that it only really appears when value is difficult to define, which is strong evidence of bloat.
Every time you hear a story of someone at Amazon being pip'd it always comes as a surprise to the IC and, most importantly, they don't know how to avoid it.
This doesn't happen in a world where creating value is well defined. For example in the sales world nobody is confused about their performance. Sure there may be unfair reasons for having a poor sales cycle, but the sales person has zero problem identifying how they can create more value to the company: close more deals.
But I see lots of comments, both in person and online, of Amazon employees fearing a pip and not knowing the right way to keep their manager happy. This, at least to me, is evidence of the bloat. The high pressure ironically comes from the fact that nobody knows how to create real value, so they are stressed out trying to figure out how the game works.
You cannot put a dollar value to every bit of work that happens in a company.
What is the value of managers? What is the value of research? What is the value of procurement/ hr? What is the value of IT and internal support tools?
None of these individually provide value, but remove one and the company will collapse.
Ruthless environments where low performers are stack ranked out of the company creates a psychologically unsafe working environment that encourages toxic competition and makes it hard to retain your best people. I got out a long time ago, but Amazon struggled to retain their best employees because they'd go somewhere else. Amazon had such absurd turn over that they are running out of people to interview. It's a wood chipper, designed to burn out young, insecure engineers while extracting two years of boilerplate from them.
This is absurd. As an Amazonian for eight years I can say it would be absurd to do this. First, hiring someone is a lot of work. Second, we don't get much value from people the first six months anyway. We don't hire people to do boilerplate. We hire people who want to obsess over their customers.
> We hire people who want to obsess over their customers.
:eyeroll:
This reads like PR fluff and flies against the experiences shared by a lot of employees, current and former. Amazon is a huge company with a lot of variation between teams so I'm sure it's not a meat grinder for everyone, but they don't have this reputation for no reason.
> We hire people who want to obsess over their customers.
I keep hearing this, but as a customer, I don't see it.
Amazon retail experience is poor.
The layout of the site sucks (so many clicks just to see all the reviews).
They used to allow comments to reviews, which often were very useful (e.g. top review complaining about something not working, and the comments explain how to fix it). But reviewers weren't notified of the comments so they couldn't engage. And to top it all of, they recently removed all the comments.
The reviews have been gamed, not very useful.
They still let people make product pages with very different products as "formats", and that skews the reviews the wrong way.
Lots of counterfeit product issues. Perhaps more common: Problems with comingling items. I know it doesn't happen often, but being burned once is bad enough. I recently bought a toy for my daughter's birthday. The box had creases. Upon opening it was clear this was a used item. Some of the items were out of their (sealed) packaging. Perhaps my mistake for not examining it before, but whenever I buy from Walmart or Target, I don't even have to think this will be a problem. Fixing it up with a great return policy is not a solution. Oh, and I couldn't return it. They recently made it hard to contact a human, and the automated return system on their web site wouldn't let me return if I had used it. I had to open it as we couldn't change her birth date.
The search sucks. Way too many results that have nothing to do with what I searched. eBay, of all sites, is way better in this regard.
I've also been an Amazon seller (FBA). The seller portal was crap.
> Amazon had such absurd turn over that they are running out of people to interview. It's a wood chipper, designed to burn out young, insecure engineers while extracting two years of boilerplate from them.
I thought those news articles were about warehouse workers, not IT workers.
It's also true of their engineering - they have a terrible reputation which caused them to raise salaries a ton in the last 2 years just to try to get comparable engineers.
They easily pay 30% more for the same engineer just because of their culture/reputation.
I've heard about stack ranking at Amazon, but I've not seen it. Maybe it's because I work for AWS, and I'm not an SDE. But I've worked in three separate organizations within AWS, each of which have different cultures. And I have never seen any of the horror stories commonly attributed to Amazon corporate in my time at Amazon.
If only 0.1% of Amazon employees are very unhappy and vent their horror stories online, you will hear hundreds of bad stories. If 99.9 are "just fine" with it, you won't hear a single story...
Oh my friend, there is a tool called Lift used in OLR/Talent Review by every single 50+ group at Amazon that quite literally will show your face up on a screen for everyone at the OLR meeting to discuss and rank vs your peers. If they don't have the Least Effective quota hit they will go through each face near the bottom to figure out who needs to be added. The most liberal definition possible of not stack ranking.
The simple reason why most don't notice it is people really intuitively overestimate how big 6% feels, especially when a good chunk of the people who leave and satisfy the unregretted attrition quota look just like someone leaving to another company but who were in focus or pivot when they left.
To refresh the exact rules for those not in the know:
- Amazon requires 6% of employees who leave the company every year to be unregretted attrition aka URA
- To be marked as URA an employee must be in Focus aka Devlist aka Devplan when they leave
- Talent Review aka OLR must occur at least every 6 months for each leader with >=50 employees under him
- Every employee is ranked from Least Effective - High Value 1-3 - Top Tier with quotas being 5:35:25:15:20 % respectively
- The 5% rated LE must be entered into Focus
- This effectively results in 10% of employees in Focus per year
- Around half fail improvement plans in Focus and are presented with Pivot, which 90% results in firing. This is the oft discussed "Pip"
- Rest either get out of Focus or leave themselves while on Focus and are still marked URA
One of the advantages of Amazon's notoriety is you can know exactly how the process works. At other FAANGS it remains more nebulous and obfuscated to my knowledge. There still is not a concrete answer on who will actually get fired under Google's new GRAD system, and Meta does not seem particularly consistent with how they target double rated meets most. I understand the least about Microsoft and Apple, despite working there.
Just because employees are ruthlessly stack ranked doesn’t mean they are working on impactful projects. Directors and especially VPs have a ton of autonomy on what their orgs pursue and are in the dark on some areas of their org, which further provides frontline and middle managers a lot of authority and it’s up to them to report up stacking within their remit and defend the positioning. So while stack ranking decisions are made, it’s not always “fair” and varies greatly across orgs. All managers regardless of level are fallible and do not always make perfect decisions on what to pursue so that adds another layer to effectiveness of employees even if they are doing the best they can at what they have been given. Cuts are at the org level based on value to the business.
Low performance can be gauged in many ways and what is a high performer in the context of a team or org may be a low performer if taking value to the overall business into account. Headcount allocations do not always reflect value (and that value varies greatly when comparing short term to long term).
In eight years at Amazon (in the supply chain org as SDE and SDM) I have not encountered anything close to "ruthless". It is true that there is rough stack ranking, but only in large organizations where it is statistically meaningful.
I forgot to screenshot the post. But I saw a post on Blind, from a BBC user (which could or could not be a reporter) asking for people to tell stories about the layoffs. I was blown away. I always assumed reporters will try to find someone and talk to them face to face (via zoom or in person) to gather intel on news stories.
Sure, there is plenty of ways to get someone from that company's attention, Looking for trolls in Blind is not the best way really, anyone can say anything their one, and the reporter would have no way of verifying it, then will publish something that is false, which we all know have happened many times. But if you think BBC is a extremely reliable source, then, yeah, you are right.
A reported doesn't need to even know who they're talking to in order to get leads on who should be pursued, but being wrong can lead to a lot of wasted hours.
If the stack ranking works then yeah they would have no bloat, but teams are just trying to demonstrate their value to someone above them who is trying to assess their value while demonstrating their own. How valuable they actually are is pretty difficult to assess. There are probably many teams sucking up millions that have a net negative impact with their contributions but how do you measure that.
Amazon got that reputation a decade ago when they were vigorously growing in user base and revenue. They couldn't hire fast enough if they even wanted to without wrecking the organization, so there was a ton of teams/people that felt immense pressure.
These days things have leveled out a little bit and I think of Amazon as a new IBM in the making. More corporate, more cruft, more politicking. This is especially true on the retail side, as Amazon has become so complicated and specialized that you'll have specific tech teams for handling edge cases for particular types of products. I think I recall there basically being a 'shoes' team that would implement features just for selling shoes on the site, etc.
I will say though that when I was in AWS a few years ago, that I was downright shocked at how lean some of the teams were. IIRC there were less than 100 developers that maintain all of dynamodb for instance.
This is totally true, I worked at Amazon when it first launched Kindle. There were multiple software engineers 100% dedicated to ‘making the Kindle product page work’ at this time.
Exactly ... In modern big software orgs it does not even matter if you are delivering value/ All that matters is Perception, Image and Exposure (PIE). Product quality, features, technical depth none of that matters, as long as you can manage your PIE.
Managers are heavily expected to keep growing their team(s). A manager whose team is flat in terms of size and scope year over year is going to be viewed as underperforming, even if they dramatically improved what they do own (in most of the company, at least).
This means a lot of managers hire for the sake of hiring, and create projects to facilitate that hiring rather than because the projects add any real value. They'll work with their PMs to invent some numbers to sell the project to leadership, but at the end of the day a lot of what goes on there is makework, solving problems that don't exist or re-solving solved problems without improving the solution significantly.
That said, since there's so much cutthroat resource contention, plenty of extremely important/valuable projects are chronically understaffed. I'm sure there's meaningful work for most to all of the engineers currently working at Amazon, but a pretty significant chunk of them are absolutely not doing anything meaningful today.
The "worlds best employer" is horribly mismanaging this layoff. It's all hush hush, and nobody is admitting anything until suddenly you have a meeting at the end of the day with a bigwig and HR.
The severance is a pittance. 60 days garden leave like twitter where if you find employment external you give up remaining severance. If you're unable to find another job, you get a week of severance per 6 months of employment (min 4 weeks, max 20).
Oh, and we're being told to use those 60 days to find a job internally at amazon....during a hiring freeze.
This is the first ever that I hear this label attached to Amazon. Do they claim it? I've never seen them in the #1 spot on any top employer / best place to work ranking. I just googled again just to make sure, but perhaps I missed something.
When I interviewed there in 2018 the recruiter specifically asked me to memorize all the leadership principles because I will be tested on them during the on-site interview. I feel bad for the candidates who now have to memorize two more of them :(
So if you don't find other work, max severance is like 28.5 weeks? Or is 20 the cap? If it's the former, almost 7 months of runway to find a new job is pretty great.
The pulling of severance on job acceptance is a cheap move by Amazon, but not unexpected given their "frugality" in all aspects of their comp and perks.
If at the end of the 60 days, you get a lump sump payment of 4-20 weeks of base pay, no sign on bonus or RSUs included.
Amazon famously caps base pay, so most people, even super senior people will not be making more than 160k/yr unless they were hired in the last year.
If you find employment externally during those 60 days, all payments stop and you get nothing more from amazon.
To get the 7 months of pay you'll have had to be at amazon 10+ years. That's like 3 people. Turnover for all roles is >100%, tech is something like 50+%
Data point of one and all that, but I got a decent bump in base and have been with the company for more than a few years. I assume that's true for almost everyone else based off the Blind posts.
There are reporting agencies that can be used to determine who employs a person. That's not including some other shady shit I wouldn't put past the company getting up to (i.e., bribing recruiting firms to tattle on former employees). Plus, I bet there's clawback provision if you don't tell them and they find out about it.
But yeah, I'd take that gamble and just keep a low profile online. Or one could slow walk the hiring process: land a job then push your start date back out 61-x days.
Similarly could you tell your new employer "Hey don't officially hire me for another 3 more weeks - I'll still work for you now but Amazon will pay my salary - deal?"
I'm not sure why anyone would play this weird game of defrauding Amazon and working for a company for free when they could instead just do: "Hey I need some time, can my start date be X days from now", where X will probably be 30 or so days (given it takes time to apply to new jobs, go through the various stages of interview, etc).
>"The severance is a pittance. 60 days garden leave like twitter where if you find employment external you give up remaining severance."
Could you or someone say how this works or is enforced? Once you are no longer working for Amazon how do they know you have found external employment elsewhere? Is this a legal gray area?
Just wanted to say: I feel for anyone impacted by this I truly hope that they're able to land on their feet and Amazon does right by them and gives a healthy severance. Least they could do.
Another quirk of this story in terms of how this makes me feel is that this makes me sad in a strange way: Amazon was my "fallback" job if my current job ever bit the dust and I couldn't find anything else relatively quickly.
Seemed like they were always hiring, and if I needed to eat, it would allow me to keep my standard of living for a 12-18 months while I figure things out. Best case: I somehow end up liking working there and stay for 4 years, worst case: I can keep my standard of living while the recession eases and move on to something else.
I will say, I got alot of recruiters from the Alexa division and I'm glad I didn't take them up now. AWS looks unaffected by this though.
Could you help explain why the general consensus seems to consider Amazon as a just given backup and easy interview path (but the hard part is the actual job crunch apparently)? They still do leetcode screening don’t they?
IMO they’ve been harder than the others because the process is so automated that you either pass or fail on the code test. There’s no tech interviewer to give you a hint unless they changed that recently.
You don’t get to show off your leadership or any other skills this way. You either memorized the solution to the random leetcode problem you get or you fail as far as I understand it.
They clearly layout their interview process and even have a video series on YouTube explaining how to pass it. It is not difficult but time-consuming to learn their interview "language"
Leetcode screens are a matter of grinding for a couple of weeks
This may be true for most "Leetcode Easy" questions, but in my experience, Medium and Hard ones require familiarity with graph traversal, sorting algorithms, dynamic programming, etc. In other words: dedicated study.
I think the point is that it can be hard to legitimately solve some of those tricky leetcode-style problems under time pressure, with no access to outside resources, and with the knowledge that somebody is judging your every move.
Memorizing the common problems gives you a big leg up on being able to successfully pass an interview.
Honestly the "right" answer in most of these types of questions is to search for a popular existing implementation. There is never a "we've got to solve this bubble sort algorithm in a locked room with no internet access" scenario. I get that they want to select for people who can solve problems by thinking their way through solutions with code, but I've never been convinced that solving leet code challenges is the way to do that. I'd also much rather solve problems without writing a bunch of code that has to be maintained, so engineers familiar with the tooling ecosystem for their platform of choice should be highly valued.
While memorization is involved, people make it seem like you need to memorize specific solutions to specific leetcode problems, and that's just not only false but also a bizzare and almost impossible strategy.
What you do need to memorize are a small group of algorithmic designs and have a good sense of when to apply each one. The main ones include divide and conquer, greedy, graph, and what seems to be the hardest of them all, dynamic programming algorithms.
It's disappointing that so few developers know these or are comfortable with these designs since employing them provides significant speedups to what would otherwise involve deeply nested loops or other naive brute force solutions. Becoming familiar with the broad set of algorithm designs is something most competent developers should invest some time in, and it's not like it requires years and years to become good at it but the benefits are enormous.
Not only that, I had to pay for my own lunch and it took four weeks for it to finally say it wasn't hiring me.
Is the problem with leetcode the content or the process? The process is utterly broken, but any time hiring comes up it feels like most complaints are about the content.
There's the group of people for whom doing these "Algos I" problems in university was relatively painless; not that all problems were "easy" but there's an ease to approaching the problem, and with enough continuous effort the problem is solved. These people also tend to have good retention such that 10 years later, they just need to practice LC for a few weeks and they're back in top form, even if they've been building the easiest CRUD apps for years and not working their brains at all. I've seen this firsthand.
There's another group of people who, for whatever reason, are lacking the facilities to calmly and clearly approach these problems. Doing "Algos I" was a serious grind, and the Brain Toolbox for solving these problems falls apart quickly once the final has been taken. Even if doing relatively complex work at their jobs for years, when it's time to practice LC, it may take months to get anywhere near "top form".
Obviously everyone is on a spectrum between and beyond these two groups, and I fall closer to the latter.
Now add on the fact that there's a person watching you who is going to dictate whether you get a paycheck at all or a 20% boost in income. Or you're like me right now and you've been laid off. Now add on that you need to do it in 20 minutes, each minor mistake potentially becoming a devastating error if you don't catch it quickly.
I envy anyone who can just focus on the problem and remove all surrounding context. Still trying to figure out how I can add stress distractions while timing myself.
> I envy anyone who can just focus on the problem and remove all surrounding context. Still trying to figure out how I can add stress distractions while timing myself.
This is indeed a good thing to be able to do. I'm pretty good at it, but when I'm in an interview situation, I almost always have at least one moment where I start to panic a little and have to tell myself, "you know what you're doing, just relax and turn the crank." And of course, there's an implied "...but maybe you'll just choke," which I have to put out of my mind.
In other words, a huge part of being able to focus on the problem and remove the surrounding context is a sort of confidence that I can probably do fine, so I can temporarily stop worrying about how I'm looking at any exact moment.
This is one of the classics, and yeah, I've gotten this one too. But this one's a gimme since it's so simple and you really are just expected to have heard it. Someone at Microsoft asked me this one and I considered it a massive gift. I thought for a few moments, articulated the solution, and then wrote the code. Then I said, "of course, everyone's heard this one before; I didn't just come up with that on the spot." (you may as well wait to admit this at the end instead of the beginning since you then get an open-ended amount of time to give a stellar answer to what they asked, then you get honesty credit for admitting you knew it all along, plus you've eaten up time that they might have used to switch questions on you).
There are much worse ones on leetcode, and people expecting you to get the optimal solution are absurd. I fully expect to fail those unless I'm lucky. I don't study leetcode problems, because my interview approach is to first and foremost, implement a naive (aka slow) but correct solution in the time allotted, then engage in a conversation about ideas for improving it (not a rewrite). This has worked for me for decades, and it's also what I expect of people I'm interviewing.
This type of approach allows the interviewee to demonstrate that 1) they can write basic code, 2) they can solve a problem, 3) they can critique their own code and discuss perf implications, 4) they can think of ways to improve it even if they don't necessarily have time for a rewrite, and it allows the interviewer to demonstrate that they aren't a dick who's just playing "I'm smarter than you because I'm in the advantaged position."
Can you tell a little more about this situation? Because it sounds like you were the interviewer who expected this... Having conducted interviews at big tech companies, I can attest there is variance between interviewer expectations, despite leadership's best efforts to make it objective. So I have to wonder if you've seen it, doesn't that mean you were creating that environment?
Meh. I used to compete on CS and Math problems and I passed the interview for a lot of big tech companies (senior and staff levels) and I don't think at any of them I could pass the interview if I truly had never seen even a variation of the problem I was given.
They want you to work pretty fast and you only have about 20 minutes to solve one problem at most companies, no way I could work my way through something completely new that quickly.
Actually, among the MAGMA companies I've found the _least_ bias for leetcode-memorization at Amazon.
My interview with Meta was exactly as you described (a CS riddle taken from a textbook, to be solved without running the code or receiving hints). But in my interview with Amazon, each coding interview also included a couple leadership questions. If you want you can look up the exact questions that they'll give you to test what they call their "Leadership Principles"
Also the Amazon coding questions were not taken directly from Leetcode, and were easily reasoned out without prior knowledge of a special algorithm.
We have a question bank that we are required to ask from that can be found online.
Coding questions and system design challenges are individual to the interviewer. Some are good, some are bad, some are leet code, some are reasonable, it's kinda a crapshot. I saw a bar raiser (a bar raiser!) asking path finding algorithms as his coding challenge which is nuts to me. All that signals is if you've worked with path finding algorithms before, or remember your college class that taught A*
But I'll be honest, our interview process is public and online and hasn't changed in a long long time. We select mostly for people who have the spare time and dedication to learn our interview process.
It could also signal that you got motivated and took many hours out of your busy day to do a meaningless task like memorize a path finding algorithms. This might be a good signal that you will also be motivated to spend many hours doing meaningless things at your job.
Actually, if you think about it, the whole concept of getting a college degree isn't much different - its not about what you learn in the classes, it just shows that you have the capacity to go through an arbitrary social experience, follow a bunch of rules, learn some stuff, and stick with it for a few years - pretty similar to a job.
"the whole concept of getting a college degree isn't much different - its not about what you learn in the classes, it just shows that you have the capacity to go through an arbitrary social experience, follow a bunch of rules, learn some stuff, and stick with it for a few years - pretty similar to a job"
It makes me sad when I hear people say things like this. A college education has the potential to be so much more than this.
I took a poetry class, despite not being particularly interested in or appreciative of poetry and it opened my eyes and made me a life-long lover of poetry ever since. Philosophy courses taught me how to think more rigorously and question things many other people take for granted.
There were many other courses which weren't required for my degree that I sampled and wound up loving and learning to appreciate things I never would have otherwise been exposed to... even changing my major because of some of them.
I didn't even have any truly amazing teachers either, so I can only imagine how much better is the college experience of those who do. Having great classmates who inspire and motivate you can be fantastic too... not to mention the potential to make connections and broaden your horizons in all sorts of academic and non-academic ways.
College can change your life, change the way you think, open your mind and open your eyes, and so much more.
I agree 100%. To add to this, I can't tell you how many engineers I run into who possess amazing programming skills, but can not convey their thoughts and designs meaningfully in written or spoken word. Taking a few more humanities classes might not be a bad idea for most.
To be fair, I am not saying college can't be that kind of experience too! But when a company is looking for a college degree, they aren't looking to make sure their employees experienced enlightenment in a poetry class. They are looking for evidence that their employee completed a 4 year structured program.
What you should learn in college is how to teach yourself to always be learning. Or at least to be aware of the trap doors that await when you try to solve a problem in the real world.
Learning the Big O Notation performance of algorithms that traverse data structures isn't so you memorize all the different running times in perpetuity. It's so you realize that performance and the type of operations you want to commonly execute are something you need to consider for the data you have to work with.
If you didn't learn that from your college CS courses, I don't want you working on my team.
The other thing college shows is that someone is capable of committing to a long term goal and seeing it through. That's important.
Note: I am not saying non-college grads cannot commit to a long term goal, there's plenty of reasons people don't or can't go to college. I'm only saying that a college degree is a signal.
That was my point as well - its not what you learn in college, its that you can learn something. I am not a proponent of Leetcode (and suck at it personally), but I think the same concept applies - just shows you can learn an arbitrary puzzle framework tangentially related to the job you are interviewing for.
Its also my experience that as you get more senior and focused on a specific skill (I'm an iOS engineer), interviews tend to focus on that skill more than leetcode. I think there are a few stalwart holdouts (facebook + google), but I have interviewed with several trendy big tech companies and none of them asked me pure leetcode - it was always framed around my iOS skillset.
However, for a junior engineer there is no way to evaluate this kind of skillset since it doesn't exist - so Leetcode is a resonable substitute.
Is a leet code question just one that has an obscure clever answer (like use 3 pointers to process the array in time O(n) ) that doesn’t really use broader knowledge of CS?
The entire interview at Amazon is based around culture fit. The tech bar is the same across levels. The ability for you to execute in the culture is the whole point of the interview.
What is culture other than the shared set of beliefs that you agree to work with? LP questions are culture fit questions. What’s excluded are things that go beyond that, for example “how do you feel about drinks with coworkers?”
Fair, though traditionally when people talk about culture fit they are a lot of times asking "is this someone I could be friends/get a drink with" which is treading dangerous waters.
I worked at Amazon for 5 years and was in over 100 interview loops. Amazon won't hire you if you don't have the skills, but they are/were relatively lax in hiring compared to other big FAANG companies. It is also helpful that they historically have been such a huge and growing company that if you have the skills and the basic interview techniques down, they will try pretty hard to find a place for you. Amazon at least used to also offer a down-leveled role if it was obvious that you were a good programmer but couldn't prove to the capricious hiring loop that you were going to perform at the level you were applying for. This means if you are a mid-senior level programmer that interviewing for Amazon is kind of a slam-dunk in the sense that you'll definitely get hired even if for a lower level.
I have thought similar to the grand-parent commenter about having Amazon as a fallback in the Seattle area. Not my ideal but somewhere that is always recruiting me and would pay the bills if the smaller company I am working for went under.
Uh, they definitely ask you a bunch of questions and you basically need to speak to their leadership principles. Being good at leetcode alone can't get you in, or that's the impression I've gotten from friends who work there. But I suppose it depends.
They're well known for having one of the lowest hiring bars of the major tech corporations, certainly out of the traditional "FAANG" they are by far the easiest to get hired at.
N > F = G > Apple > Amazon in terms of hiring difficulty, from my impression.
Until recently, their pay was also not as competitive and they had massive turnover rates.
Yeah I would say that Amazon has a ton of basic work that needs to be done. The website is so big and complicated and multi-faceted compared to some of the other big tech companies. Sometimes you really just need to hire a developer/team to ensure that the underwear size-picker is working correctly. Of course Amazon also has lots of insane CS-heavy infrastructure and algorithm work as well.
That is a fairly uncharitable reading of that post, which mentioned nothing of the (perceived) abilities or skills of the engineers.
Your account name leads me to believe you've been impacted by this, and I feel for you. I am sorry. I hope you're able to find a new gig relatively stress free and find yourself in a better place.
Yea I suspect many of us know people who're terrible at LEET code problems who're great engineers. And vice versa.
I hope Parent gets the help they need. I am thankful I cannot imagine a world where... Google's "elite" engineers impacted my world in such a drastic manner.
Can't tell if this is sarcasm or not. I really hope you're doing ok and seek appropriate mental health support. Don't fret over the ranking of companies - we're all dead and forgotten in a few generations anyways. This is true for every Google and Netflix engineer in existence.
Internet forums are not good places to visit when you're in a stressful situation. The fact is, the parent post neither said nor implied the thoughts that you've attributed to them.
You need to make a plan to find your next position, instead of looking for things on the internet to get offended by.
> You either memorized the solution to the random leetcode problem you get or you fail as far as I understand it.
I thought the point was to actually learn the theory behind the question so memorizing isn't necessary? Like for dp questions for example: it's easier to do them if you just visualize the dag
The whole "memorize every question" shtick is the wrong way imo. Just seems very time inefficient to me
i've never interviewed at amazon, or even heard much about their interview process, but the sheer amount of recruiter spam i get from them gives off a "desperate for engineers we aren't getting" vibe, so i can see why people think it would be easier to get in there than at the other tech megacorps.
I think the Amazon recruiters are far more "spray and pray" in their approach. I get messages from Amazon recruiters telling me to attend some careers event in California next Friday, that I read from my desk in Sydney.
Part of the issue is they can't/won't compete on comp or benefits with other big tech companies, but still have high-ish standards on hiring, relative to the industry as a whole.
That means they need a huge candidate pool, since most won't make it through interviews, and most of those who do won't accept their offer since they can get better offers from other companies.
I see it the same way, once you were in and left on good terms, you are always welcome back .
I treat it as my fallback too, the shifts are easy, all you have to do is not be late (or early, for that matter) and adhere to break times. If you do that and you are not the weakest performer, you will have a good life.
It is one of the very few companies where taking ownership is really rewarded, they lay the path for promotions, they even ask you which role you would like in the future and no hard feelings if you leave for another department.
I have never seen or witnessed micromanaging, the holiday system is the best I have seen.
Keep in mind I was a fully virtual employee, maybe things are different in office.
I know I can go back there if I like and enter at a level where I get stock compensation right away with a solid salary.
If you collect plenty of accolodates and maybe get a badge or two, they will never forget you.
I think they habe a very good screening process and a pretty good sense for hiring the right people at any level(the requirements are rather high for the salary).
The reason why they like to re hire people is often the immense onboarding cost, anything level 3 and up requires quite some learning and training time before you can even think of being productive.
If I was hiring, there is no way I would hire a level 5 from outside amazon if I could give that role to an experienced level 4 employee.
All teams are pretty huge, think of lets say 10 head team, within the first six months, they will habe 2-3 months of training and upskilling, and really, you have to habe that training to do things like vcs, vat etc, as you will at least have to have some fba skills for that role.
If Amazon is letting people go, it must be pretty bad, usually they are not cheap about redundancy, theu are wise enough to be ready for spikes in business. Not sure what has happened there and I strictly speak for office jobs in europe, everything else , I do not know.
The whole thing is quasi subsidised by aws and this comes bit as a surprise to me.
I prefer bit more risky endeavours and chose amazon whenever my risk apetite has decreased.
Amazon is a rather solid employee if you perform, just be on time and have good adherence time, as a company with a million employees, this is understandable. It is also much less chaotic than you would imagine from such a giant corporate entity.
If they need you for programming, aws sales, language skills and tax matters, you will be doing fine there.
On tax matters or newly established teams, the next level is always in sight and within reach.
I hope the severance packages will be fair.
I struggle to understand the bad rep for amazon seen online, working for musk or google is many times worse. Facebook used to be pretty good from what I hear.
Maybe its all individual perception and a bit of luck or misfortune.
As for the screenings, yes, they do, but they do not care about memorized things, they try to care and see how you start to deal with an issue.
There's a lot of factors why it might have been that person's fallback even though it might have been your first choice. The product, the culture, the location, salary, WFH, options, benefits, etc.
I knew a guy who would passed up working for Apple for a relatively unknown non-FAAANG company.
People have their reasons. It's not that everyone working for Apple is lesser than. It's more that this guy had his own reasons.
so, I say fallback in the sense that I felt confident I could interview there and apply without much friction. I got alot of LinkedIn invites from recruiters - typically once a week - for over a year.
I think Amazon engineers are - by and large - pretty great actually, worked with more than a few ex-Amazon engineers to know.
This was, and I admit, an offhand comment of which I should have explained this context better.
I also don't believe the interview is "easy", but it felt available and I'm someone who - even for companies that don't crazy rigorous hiring practices - goes really deep before any interview, reading many weeks in advance worth of stuff about the company and their hiring process, learning etc. I practice alot, so I felt like I could do well with the Amazon interview. In fact, I did one once before and it wasn't nearly as bad as I thought it would be, it just didn't work out at the time for me to join.
As explained lower in the thread, I should have given more context to my offhand remark. Since I can't edit the post itself, here's the context:
I say fallback in the sense that I felt confident I could interview there and apply without much friction. I got alot of LinkedIn invites from recruiters - typically once a week - for over a year.
I also don't believe the interview is "easy", but it felt available and I'm someone who - even for companies that don't crazy rigorous hiring practices - goes really deep before any interview, reading many weeks in advance worth of stuff about the company and their hiring process, learning etc. I practice alot, so I felt like I could do well with the Amazon interview. In fact, I did one once before and it wasn't nearly as bad as I thought it would be, it just didn't work out at the time for me to join and I had to pass on the opportunity.
Both are bets to create a new platform as they feel threatened by Apple & Google's dominance on mobile.
Meta should take note. Alexa is widely adopted (# of devices) but has little engagement and still hasn't broken outside of the most primitive use-cases (play music, remind me, etc)
Meta tried to create a new market with the Metaverse, but Amazon overhired in their Alexa department because they were surprised by the financial success of smart speakers and wanted to double down.
Anecdotally, I often see the trashcan speakers in peoples' kitchens, even if people usually say that they only use it as a fancy radio alarm clock.
I rarely meet people who have tried Oculus' recent hardware, and those who have are usually gadgetheads who keep it in a closet as a party novelty. There was a spike in interest when Valve released the Vive and Oculus was an independent entity, but that was more about gaming than social experiences, and it seems to have tapered off in my social circles.
For context, I work for Amazon, have multiple Alexa devices, an Oculus Quest 2 and I think the Metaverse is absolute bullshit and will never bring a cent.
But I totally disagree with the comparison between Alexa and the Metaverse. Alexa has adoption and struggles with monetization, while the Metaverse struggles with adoption but would have endless possibilities for monetization.
What is condemning a lot of Alexa teams today is the complete inability for Alexa to be anything more than a music speaker that also tells you the weather and sets timers. It's tedious to interact with and it's impossible to monetize, just because of how limited the "interface" is.
The Metaverse will never struggle with the same problems. It's not gonna work, but not because it can't be monetized.
And how much is Bezos worth? If your company is posting profits and executives are rolling in unprecedented piles of money there's no excuse for layoffs.
If Amazon wants to be a pillar of the economy, then helping induce an even worse economic recession isn't good business.
The weird thing is that the old industrialists like Ford understood this. They achieved monopoly or cartel status, and recognized that things like pricing, work schedules, and layoffs had actual feedback loops with their revenues and profits.
Then again, maybe they didn't have the accounting technology and large scale macroeconomic measures to show that was a bunk idea.
Those days of world wars probably had more of a collectivist survival view even in the super-elites, those days are long forgotten.
Bezos worth is based on the company stock, and the stock going up or down does not conjure "piles of money" to the company. Executive compensation (any employees', really) is a matter to the owners of the company. I don't own any Amazon stock, do you?
How about the sacred "fiduciary duty" to shareholders and the Wall street gods? Sacrificing thousands employees on the altar of cutting costs stays their wrath,and they will bless you with higher share prices.
Are you suggesting Bezos didn't earn that money yet? That he still owes some duty or service in exchange for the money he's already received? At what point can he say he's actually "earned" that money and can spend it in whatever way he pleases?
Should we apply the same logic to your life? My life? Everyone?
AWS is barely touched. AWS AI even less so. A repeated lesson for me: always join a growing business for professional development, for career satisfaction, for financial reward, and for job security.
Alexa was the absolute hotness when it was first introduced. There were so many claims how it's going to take over the entire world that I started to question my own sanity. Imagine if you joined that growing business at the time? Same here, what is AWS AI and how can you tell that apart from a hyped-up diversion? Clearly, anything "AI" is extremely overhyped currently, but how can you tell which one is real.
Be willing to do the boring, unsexy stuff that is at the foundation of the business. You'll never be the hotshot, but it's extremely unlikely that you would get caught up in layoffs like this.
It depends on your definition of hotshot. If you stay in the core part of the business and reliably contribute, your star will definitely rise and almost certainly be noticed in some capacity, even at the highest levels of the company.
You're not going to be the poster boy, and trade magazines aren't going to beat a path to your door for an interview, but if job security and absolute authority over your own environment is what you expect.. that's definitely on the table, even in the "boring" parts of the company.
This I've found to be especially true and take less time in any organization that relies on commissioned sales. There's an incentive for internal recognition in those environments that improve the calculus here quite a bit.
There will be multiple personal risks with this approach. First my skills may increasingly become irrelevant, as there are only "boring" work to do. Second I don't get job satisfaction. Of course, it depends on what makes one happy. To me, it is the thrill of solving new problems and knowing that I kept becoming a better problem solver. Third, an org with no growth means incumbents fight for turfs. In contrast, a growing org has increasingly larger pie for us to eat, which means more focus on doing, less on in-fighting. Fourth, I still want to reap some financial reward. A profitable yet non-growing company naturally concentrates its resources to the top, and the future growth is predictable. A growing company has a much better chance to have better financial returns (with higher risks as well).
I didn't say you had to be stuck working on boring maintenance work on a boring team with no problems to solve, just join a boring _organization_.
There are many teams in organizations like EBS/S3/etc working on the growth and next frontier of those services - but those teams are still far less likely to be cut in a layoff than teams doing similar work in riskier organizations. Why? Because layoffs are allocated from the top first. The reliable and profitable S3 org as a whole will be required to lay off far fewer people than the Devices org that is losing $XXXXXXXX/year.
Amazon has been cutting a handful of their growing businesses aswell. Take for example Amazon Care. That team tripled in size YoY and was disbanded right before these layoffs. A growing business also needs a clear path to profitability.
Yes. Growth in user demand, number of use cases, and revenue. Uber HR used to boast that Uber was the fastest growing company because it grew its headcount faster than google and facebook, which cringes me to no end.
Seems like the layoffs were not announced well, with many people still not knowing whether they are or are not impacted, and no clear message from the top. Shameful, especially contrasting to how recent layoffs were handled by Meta and Stripe.
Strange times, but expected. At some point there was a recession to be expected at these code factories. The higher the scale the higher the impact. Old age car manufacturers used to employ entire cities and once they went bust these cities went bust with them. We need to be careful in allowing software factories to grow as large, else we risk the same fate. Personally I'd stay away from such employers (not that I have been an employee in a long time, but still if needed i'd avoid them).
The market ATM is really odd. On one side, you see these news pouring and giving us devs a little ansiety and on the other side, there are companies still trying to hire like crazy. I've received 3 emails from recruiters just today. It seems small-medium tier companies are looking to capitalize over this "downturn" by offering full WFH positions and other perks since they can't compete on salaries.
This is purely anecdotal but I shared this to give other devs that may feel like "this is the end", some hope for the future. The reality is that software development is almost ubiquitous; almost every industry is being touched by it.
We have to keep improving and wait for the whiplash when the time comes (prob. 2023Q2 at best or 2024Q2 if things get worse).
Check small-medium tier companies with WFH and try to move to a low-cost city. You'll get the best of both worlds, hehe.
out of interest, with all these big layoffs, does the tech job market in the US pretty much consume these people pretty quick? or does it take quite a while for these people to find new jobs?
Amazon is one of the more stable tech companies around. My bar for how bad tech recession is generally depends on Amazon. And things don't look good right now. If Amazon is laying off, stinky stuff has hit the fast rotating blades.
290 comments
[ 4.5 ms ] story [ 262 ms ] threadBasically there has been no official communication about teams affected, amount of people affected, or time where it would be shared, and instead each team is randomly informed by their director.
This means you can never know if you are safe or not, if the layoff wave has passed or not, etc.
The past 3 days have probably been the least productive for all of Amazon's existence, everyone is thinking only about those layoffs (and I'm in an org that is supposed to be safe...).
So far there are reports of about 30 teams being shut down, but new ones are coming every hour or so.
Everyone would have preferred a clear "you're in / you're out" email at a fixed time like it's been done at Facebook, Twitter, etc. but no, we're going to be living in fear for the next weeks or months.
I was working at Best Buy when the stock price was $8/share... we had "Tornado Thursdays" where every Thursday for months you'd hear of a small amount of people getting notice they were laid off. I suspect they did this to avoid labor rules of notification/SEC?
Prior to that, we went through a LARGE layoff where they gathered everyone in a room, said "go back to your desks you'll see a 15 minute meeting on your calendar if you're impacted" and at the end of the day they gathered the remainder in a room and said "if you're here you're safe".
Layoffs in our industry are simply part of the long term game, part of a playbook that folks coming into it in the last decade or so probably haven't experienced. My eyes were opened in the dot-com crash - I saw too many extremely smart, hard-working, and accomplished developers get dropped and spend a year or more getting back into programming gigs.
It was such a joke, but I used to be of the belief that the card processors were so incredibly profitable, that they had to actually waste money to not be targeted by regulators too much (which monitored their profit levels to determine if they wanted to impose lower card fee rates). So these kinds of things were actually healthy for the business, along with insane travel and entertainment budgets - I used to routinely spend >$10,000 on plane flights back to HQ from Asia.
Ha, at Facebook people have been complaining that they only learned at the last-minute and only thanks to leaks, saying they would have preferred a longer-term heads-up so that they could start preparing and avoid making long-term commitments (eg that guy who was laid off one day after moving his whole life from India to the USA)
I suspect that there’s actually no great win/win way of doing mass layoffs ¯\_(ツ)_/¯
The difference is that not only you get no notice, you actually don't know when the wave of layoffs is done and when you can take a break from worrying.
The people I know that worked at Meta all started interview prepping after those announcements. It should not have come as a surprise.
The company could also just give workers notice. Works fine here in Europe.
It's not, it's like that everywhere. Every layoff follows the same pattern that you describe.
I don't know the exact reason for it, but if every single company does the same thing, there has to be a reason I don't know, since I've never managed a mass layoff.
So the proposed cuts represent less than 1% of their profit (not net) from last year.
[0]: https://s2.q4cdn.com/299287126/files/doc_financials/2021/q4/...
"Amazon is very, very bloated. So there's lots of people there but they're not providing a lot of value so they're first on the chopping block."
This is counter to what I have heard about Amazon, which is that it is a ruthless environment where low performers are stack ranked out of the company. Does anyone have any insight?
"Bloated" isn't for engineers to decide really, we're terrible at judging efforts involved.
Disclaimer: I work at Amazon as an SDE II on the logistics side of retail.
If you have to fire the bottom x% of your team every year due to low performance, doesn't it mean that you have a constant low performing cadre? Otherwise, why would you get rid of them?
So I don't think it being "cut throat" and there are "many low performers/bloat" are at odds.
No matter if your team is amazing or not, 5% getting cut.
A slight correction: An organizational unit larger than a 2 pizza team -- think 50 engineers, is expected to cut 5-10%. A team within that unit may lose 0 engineers, which is how high performing teams that meet all their goals stay intact.
So Amazon, like every other FAANG, is very bloated. I've yet to experience any sort of major layoff in the industry at large. They seem mostly isolated to these mega-corps that got PPP money, hired way too much, and are now trimming back the fat. It is sort of icing the fungibility of jobs for now but not in a way that I am at all worried about.
I think your general point is correct: FAANG over hired during the pandemic, but I'm not sure you understand how PPP worked or how the money was distributed. Google, Amazon, and Meta weren't the primary recipients of PPP money (they directly received 0 of it).
Their stock price increased due to both performance during the pandemic, and the general loose environment created by the Federal Reserve which probably played more of a role than PPP targeting mid-size businesses.
1. Your manager is the one putting you in PIP (firing plan). If you're friends with your manager, he won't put your name, even if your performance is below the bar.
2. This is applicable in every single avenue of life, but your reputation is everything. Work hard for the first few months after joining a team and impress your leadership and your colleagues on your first few tickets, then you can dial it down and still be 100% safe and be regarded as a top tier engineer. You will be "the guy that ramped us fast and executed well" for the rest of your time in that team. If you have setbacks, you won't even need to justify yourself, they will just know that "hey if this top guy is struggling it just means it's very hard".
On the contrary, I have witnessed people being fired or looked down upon just for having a bad reputation, even when they were doing just fine or had legitimate roadblocks on some tasks. One of my good friends got fired because he was the party guy of our team, so nobody was ever taking him really seriously.
I rarely have seen (1) come into play. I'm sure it happens, but there is a lot of scrutiny of the stack rank, enough where I think it would be hard to pull off. I think most friend managers would tell their friend months ahead of time -- you really need to do XYZ or things are going to be tight at review time.
(2) is very true though. Reputation and perception is super important. Although I think companies now do take a harder look at delivered impact either via KPIs or OKRs.
In my experience, most engineers are pretty good. And I've struggled to find people to put in the bottom of the stack rank, because I didn't feel that their compensation would reflect the impact they had. IMO, after having to do layoffs, it is the hardest part of the job. And it sucks because there is very little way out of it for the manager. Helping person X do better, just means that now person Y is at the bottom of the stack.
In Amazon you will be PIPed (or rather put in focus, which is a first step that may lead to PIP) if you are marked as "Least effective" which is the bottom 15%.
Your manager has to demonstrate why you are "Least Effective", and they have to demonstrate why you are "Top tier". However, they don't really have to justify themselves to put you in the middle of the pack, where you will be safe from PIP.
So, for sure, you may not be ranked in the top of the team if you're buddy with your boss, which means you won't get a salary increase for example, but at least you won't be PIPed, which in the end is what I assume most people care the most about.
Worked in a company that does stack ranking. Here's how you do 1 (in the opposite sense): Give the person tough tasks, with very tight deadlines. Amplify their failings and belittle their achievements. Repeat till the employee screws up, and start building evidence for a PIP. Get others involved (customers the employee is interacting with, your own manager, etc). In most cases I've seen, if a manager is unhappy with you, the others (customers, your manager) will follow the manager's lead to get rid of the person.
If/when the employee contests this, most HRs will pick someone from the same department to be the investigator. Since it's the same department, it means it's the same culture your manager is exhibiting. They will much more likely believe them than they will you.
Source: I got semi-fired this way. To give you an example: The investigator wanted proof for everything I was claiming in my defense. Not only that, they held it against me if I had not sent emails to my manager saying I disagreed with his behavior. Eventually, I asked the investigator: "So, did my manager show you proof for all his claims?" The investigator responded with "Good point, and once this process is over I will send him and his manager feedback on the mistakes they made." Umm - sure, but why should I be punished and not them? No answer.
I somehow stayed at the company (they made an exception for me and let me change teams) - and over years saw this process repeat over and over. When an employee is in trouble, I immediately start advising them on the steps their manager will take - it usually plays out as described above.
The challenge most of the people outside of Amazon do not realize is that micro-service architecture imposes a heavy penalty on team co-ordination, esp. as the software matures. A large part of core services have been built over several years (and decades) and they have been architected to optimize for some operations at the cost of other operations. You can think of this as how you would design a DB schema. It is a trade-off between write speed, query speed and availability. Now, think about it happening at massive scale. As an engineer, you would spend a lot of time working/waiting on partner teams to prioritize your changes while under pressure to deliver. A lot of teams ended up building the pieces on their own into their own services leading to a larger maintenance and operational load.
From the outside, you are very likely to think that the team is bloated and slow-moving because you are assuming green field development. Internally, Amazon is a 25-year old legacy platform with almost no single vision across teams, tons of semi-duplicate functionality and heavy operational load. Keeping the lights on (KTLO) was a big ticket item on every annual plan I created when I was there.
That being said, Google for comparison does have good code re-use for certain core resources, like spanner, cloud, tensorflow, borg, etc. If you're talking about bedrock infrastructure like that, it's quite a different picture.
I think I am regurgitating mythical man-month here and will shut up.
Maybe I'm doing it wrong but I often find that doing a new greenfield project sounds easier but by the time you deal with all of the non-functional stuff (connectivity, resilience, logging, build tools, documentation etc) you might have been quicker holding your nose and bodging it in somewhere vaguely appropriate in an existing system.
This is, by far, the hardest scaling problem in SaaS: How do we divide responsibilities amongst our (code|services|teams) efficiently?
You can only grow each so much before they become unwieldy to manage.
Divide scope too much and communication becomes complex.
Divide along the wrong abstraction and you get duplication, overlap, and confusion about what's responsible for what.
And as time passes, decisions of the past constrain and complicate your options to redesign/rearchitect/reorg today.
...which is a fairly obvious observation. "Bad <x> imposes a heavy penalty on team co-ordination" is generalizable.
I recommend you find a way to spend time with someone who knows how to design a quality microservices architecture. It will completely change your opinion about how microservices interact and the supposed "pain" therein.
You have no idea what I do and what my competencies are, yet, you are assuming you know a lot more about system design than I do and I am missing something simple.
Here is another take from Bryan Cantrill [https://www.youtube.com/watch?v=30jNsCVLpAE&t=1413s]. Very likely, he does not know anything about services either, I guess.
Nowhere did I say, "It is obvious how to design a good microservice." but it seems like you're arguing against that statement, not the one I made.
And for what it's worth, I don't give a hoot who you are, who Bryan Cantrill is, or what your supposed competencies are; make your argument, don't rely on your pedigree to speak for you. That should be obvious.
There is no magical model for this, no buzzword, no single practice, because different businesses and use cases need to be adapted to it. But there's 70+ years of study into methods to do this, and I believe they're taught by all the business schools. It's just nobody wants to do the work.
....On the other hand, nobody teaches MBAs how drastically different tech is than other industries, and thus how you run your "factory floor" has to be different. But the basic principles above should still be applied; they just have to be adapted to the industry and work. What one should not do is just accept things however that industry does it, because they probably aren't doing the above principles either.
In front end development people NEED the world's largest application frameworks (sometimes plural) because they cannot figure out state management. State management is stupid simple and a solved problem, but whatever. It will still, at the job, take you all day (maybe a week) to make that 30 second change.
If you try to bring up that the days work could be solved in less than hour if only we didn’t make all the wrong decisions and fear the platform they will look at you like you’re retarded. I have heard this mentality expressed perfectly in the movie Edge of Tomorrow: Don’t tell anybody. Are we clear? Best case scenario you’re gonna end up in a psych ward. Worse case you’ll get dissected for study
Here is the summary:
* You need a storage location
* You need a defined data structure to store your state data. I recommend storing everything in a single logical storage object, because 1 is simple and simple is good.
* You will need to update and save your storage object at the needs of your application. I do it on each user interaction, because this is cheap.
* On page load you will need to access your storage object and apply it to the user facing event handlers that create your state artifacts that otherwise normally execute in response to user interactions.
That’s it. Consider the problem from the goal and work backwards to the solution.
There are a lot of teams working on either useless or _duplicate_ products.
Amazon is a place where it is frequent to discover that another team is doing pretty much exactly the same thing as you, despite both teams existing for years.
My previous team found out that multiple of our products had equivalents built by other people (even one was just an excel sheet made by some random guy :|) and my current team has a table comparing our product with the other 15 equivalent products made by other teams...
And then there are a lot of teams working on products that do not and will never bring revenue, such as a big part of Alexa.
I generally see this play out as, one team trying to tackle the problem with a prototype and demonstration of tech. The other team just acquires as many people as possible and writes a bunch of documents. Then it gets run up the flag pole and the solution seems to be to go with the team that already has all the people.
Scenario A: Task a single team, staff them and let them do their thing. Cross your finger and hope they get it done.
Scenario B: Look across offices, org groups, whatever, and task 2-3 (sometimes more) teams with your task. Let them start work on it and get regular demos and updates. Eventually, pick a winner.
B looks very wasteful from the outside, until you realize that many software projects fail (like 50%). So more attempts give you a higher chance of success. Downside: Internal politics, waste, attrition from engineers throwing away code/busy work.
A is great if you can do it, but you're putting all your eggs in one basket.
A lot of times this is just bad org/bureaucracy though, but it can be done to great effect.
Disclaimer: Worked for a CEO with a large outsourced engineering base and several offices. Would see multiple attempts at different offices all the time. Eventually, grudgingly acknowledged there was a method to that madness. Trump also is famous for this (although his seemed more madness).
What actually happens is Scenario C - it doesn't arise from a top-down planner mandating it, it arises from middle managers (or their subordinates) further down the food chain each trying to grow their own kingdom, who all get the same idea at roughly the same time, and each build their own solution to the same problem.
During times of plenty, or if the top-level planner is only absent-mindedly managing that part of their org, the firm will be willing to tolerate these competing implementations, but during lean times, they cut, cut and cut and consolidate down to one winning solution.
A lot of corporate politics and strategy makes a lot more sense when you start looking at the personal motivations of the participants in it.
Some orgs within the company are fairly lean, some are hugely bloated. Amazon isn't homogeneous. For example, Alexa is very over-resourced and it's common to hear about 4+ teams working on slight variations of the same project. Lots of redundancy there. I believe Alexa as an org is losing $5b+ per year. Contrast that to all the criticism Facebook is receiving for their investment into VR/AR. The investment in Alexa was a platform play. Amazon thought that voice would be the next big platform. I'm not sure results and trajectory justify the investment anymore.
Contrast that to VR, which is in a much earlier stage of its technology and adoption cycle: Meta has a strong technology advantage, currently has the best overall platform and _if_ VR becomes the next big computing platform, Meta is in a strong position to capture a significant proportion of market share. It's a big if! but at least there's still a chance.
As a primary interface voice was very widely used in the 80s and 90s in the form of IVRs and the industry was immediately destroyed by web browsers as fast as was possible. Nothing makes people angrier than having to go through a phone menu system and that’s just an organized version of your more general voice interface.
“Alexa set a timer” defines the kinds of interactions that are sensible to do with voice and it is very, very narrow.
It was never, ever going to be big.
Alexa is full of horrible managers that only care about growing their teams so that they can get a promo.
The former is a low single digit profit margin business, the latter probably has a decent profit margin.
I wonder if, within my lifetime, it will be possible to tell a digital assistant to "order all the ingredients I need to bake the cinnamon buns as detailed in the cinnamon bun baking video I watched last month with the Chinese lady that doesn't have an accent"?
It'll be useful when you can have it create, say, a menu and shopping list for your week, interact conversationally to tweak it including understanding that something like "I'm allergic to that ingredient" means never ever try to include it again while other statements of preference may be much softer, learn your preferences so those conversations get shorter every week, and order the ingredients for you, too. It barely matters if that happens over keyboard input or voice, because the hard parts of that problem have nothing to do with how the input is done.
You want to be able to give a few parameters for a trip you're taking and get some choices back. But, as you say, that's far more about "intelligence" than the type of input.
Nothing reminds you about the difficulty in cleanly parsing human language more than trying to work through a voice interface. I'm not sure what is missing precisely, but I'd say "an ability to use semantic understanding" might be helpful. All of our AI works explicitly with no understanding of semantics, but it's becoming clear to me that the ceiling that places on their "intelligence" puts them still leagues away from the world of true AGI.
Or work consistently.
"Alexa play music".. Nothing... Do it a few times and it finally does play music? I could have gotten up and done it myself easier/faster at times.
the links and offering is solid. I have spotify connected to my amazon account and this is NICE..but as i said, the inconsistency is frustrating.
Amazon music subscriptions are $15.99/month. Doesn't that count? Sure, you can buy that without an Alexa, but that is the whole reason people do.
It makes a lot of sense if you can afford it.
This goes all the way back to his early days (I think I remember a scene about this in The Pirates of Silicon Valley), but also reportedly multiple teams were building very different original iPhones
I think its easier to adjust pure software iteratively than hardware. So with hardware, it makes sense to have different teams working on similar but different things because variations of ideas need to be fleshed (and thoughts that spawn off those ideas) and it can be hard for one team to do this iteratively.
If you're right and this is where it came from, I think largely pure software teams doing this are wasting resources, but if its hardware I don't agree its wasteful
I ran into this a couple years ago with partially duplicating a service that existed under another SVP org. It didn't feel good at the time but in hindsight it was probably less effort and higher chance of success than trying to align priorities across SVP orgs and making their thing work for our slightly different use cases.
It turns out that there are many interaction models where Voice is clearly inferior. Visual discovery (contrast with music) such as for videos, as well as navigation in a UI, are poorly done via voice.
"Alexa, set a timer for x mins / wake me up at x time."
"Alexa, what's the weather today?"
"Alexa, can dogs eat <type of food>?"
"Alexa, play <the song I just referenced so my wife knows the reference even though she doesn't care>"
Mostly just the first two. I don't care about anything else they try to push on me.
People talk about food waste, but how much code is wasted?
Every time you hear a story of someone at Amazon being pip'd it always comes as a surprise to the IC and, most importantly, they don't know how to avoid it.
This doesn't happen in a world where creating value is well defined. For example in the sales world nobody is confused about their performance. Sure there may be unfair reasons for having a poor sales cycle, but the sales person has zero problem identifying how they can create more value to the company: close more deals.
But I see lots of comments, both in person and online, of Amazon employees fearing a pip and not knowing the right way to keep their manager happy. This, at least to me, is evidence of the bloat. The high pressure ironically comes from the fact that nobody knows how to create real value, so they are stressed out trying to figure out how the game works.
What is the value of managers? What is the value of research? What is the value of procurement/ hr? What is the value of IT and internal support tools?
None of these individually provide value, but remove one and the company will collapse.
:eyeroll:
This reads like PR fluff and flies against the experiences shared by a lot of employees, current and former. Amazon is a huge company with a lot of variation between teams so I'm sure it's not a meat grinder for everyone, but they don't have this reputation for no reason.
My boss at Amazon told me he was happy that his baby was born prematurely, because it meant he could be back at work in time for a launch.
I keep hearing this, but as a customer, I don't see it.
Amazon retail experience is poor.
The layout of the site sucks (so many clicks just to see all the reviews).
They used to allow comments to reviews, which often were very useful (e.g. top review complaining about something not working, and the comments explain how to fix it). But reviewers weren't notified of the comments so they couldn't engage. And to top it all of, they recently removed all the comments.
The reviews have been gamed, not very useful.
They still let people make product pages with very different products as "formats", and that skews the reviews the wrong way.
Lots of counterfeit product issues. Perhaps more common: Problems with comingling items. I know it doesn't happen often, but being burned once is bad enough. I recently bought a toy for my daughter's birthday. The box had creases. Upon opening it was clear this was a used item. Some of the items were out of their (sealed) packaging. Perhaps my mistake for not examining it before, but whenever I buy from Walmart or Target, I don't even have to think this will be a problem. Fixing it up with a great return policy is not a solution. Oh, and I couldn't return it. They recently made it hard to contact a human, and the automated return system on their web site wouldn't let me return if I had used it. I had to open it as we couldn't change her birth date.
The search sucks. Way too many results that have nothing to do with what I searched. eBay, of all sites, is way better in this regard.
I've also been an Amazon seller (FBA). The seller portal was crap.
I thought those news articles were about warehouse workers, not IT workers.
They easily pay 30% more for the same engineer just because of their culture/reputation.
The simple reason why most don't notice it is people really intuitively overestimate how big 6% feels, especially when a good chunk of the people who leave and satisfy the unregretted attrition quota look just like someone leaving to another company but who were in focus or pivot when they left.
To refresh the exact rules for those not in the know:
One of the advantages of Amazon's notoriety is you can know exactly how the process works. At other FAANGS it remains more nebulous and obfuscated to my knowledge. There still is not a concrete answer on who will actually get fired under Google's new GRAD system, and Meta does not seem particularly consistent with how they target double rated meets most. I understand the least about Microsoft and Apple, despite working there.Low performance can be gauged in many ways and what is a high performer in the context of a team or org may be a low performer if taking value to the overall business into account. Headcount allocations do not always reflect value (and that value varies greatly when comparing short term to long term).
These days things have leveled out a little bit and I think of Amazon as a new IBM in the making. More corporate, more cruft, more politicking. This is especially true on the retail side, as Amazon has become so complicated and specialized that you'll have specific tech teams for handling edge cases for particular types of products. I think I recall there basically being a 'shoes' team that would implement features just for selling shoes on the site, etc.
I will say though that when I was in AWS a few years ago, that I was downright shocked at how lean some of the teams were. IIRC there were less than 100 developers that maintain all of dynamodb for instance.
Including systems engineers ups it to 348.
This means a lot of managers hire for the sake of hiring, and create projects to facilitate that hiring rather than because the projects add any real value. They'll work with their PMs to invent some numbers to sell the project to leadership, but at the end of the day a lot of what goes on there is makework, solving problems that don't exist or re-solving solved problems without improving the solution significantly.
That said, since there's so much cutthroat resource contention, plenty of extremely important/valuable projects are chronically understaffed. I'm sure there's meaningful work for most to all of the engineers currently working at Amazon, but a pretty significant chunk of them are absolutely not doing anything meaningful today.
The severance is a pittance. 60 days garden leave like twitter where if you find employment external you give up remaining severance. If you're unable to find another job, you get a week of severance per 6 months of employment (min 4 weeks, max 20).
Oh, and we're being told to use those 60 days to find a job internally at amazon....during a hiring freeze.
World's best employer my ass.
This is the first ever that I hear this label attached to Amazon. Do they claim it? I've never seen them in the #1 spot on any top employer / best place to work ranking. I just googled again just to make sure, but perhaps I missed something.
It's 100% bullshit.
So far the actions they've taken to be the worlds best employer has been....changing the password reset cycle to be one year instead of 90 days.
You can't be world's best employer while frugality reigns supreme.
Did Amazon perhaps add it to the list because of lackluster workplace quality, and so this is still early in the journey?
https://www.amazon.jobs/en/principles
The pulling of severance on job acceptance is a cheap move by Amazon, but not unexpected given their "frugality" in all aspects of their comp and perks.
Amazon famously caps base pay, so most people, even super senior people will not be making more than 160k/yr unless they were hired in the last year.
If you find employment externally during those 60 days, all payments stop and you get nothing more from amazon.
To get the 7 months of pay you'll have had to be at amazon 10+ years. That's like 3 people. Turnover for all roles is >100%, tech is something like 50+%
If you weren't hired this year your base is likely still around the 160k
But yeah, I'd take that gamble and just keep a low profile online. Or one could slow walk the hiring process: land a job then push your start date back out 61-x days.
Could you or someone say how this works or is enforced? Once you are no longer working for Amazon how do they know you have found external employment elsewhere? Is this a legal gray area?
Another quirk of this story in terms of how this makes me feel is that this makes me sad in a strange way: Amazon was my "fallback" job if my current job ever bit the dust and I couldn't find anything else relatively quickly.
Seemed like they were always hiring, and if I needed to eat, it would allow me to keep my standard of living for a 12-18 months while I figure things out. Best case: I somehow end up liking working there and stay for 4 years, worst case: I can keep my standard of living while the recession eases and move on to something else.
I will say, I got alot of recruiters from the Alexa division and I'm glad I didn't take them up now. AWS looks unaffected by this though.
IMO they’ve been harder than the others because the process is so automated that you either pass or fail on the code test. There’s no tech interviewer to give you a hint unless they changed that recently.
You don’t get to show off your leadership or any other skills this way. You either memorized the solution to the random leetcode problem you get or you fail as far as I understand it.
Leetcode screens are a matter of grinding for a couple of weeks
Source: received an offer from them in March
Did you have formal compsci training before you started studying for leetcode? Did you study algorithms before that?
Just wondering how hard it would be for someone who never got a compsci degree and knows nothing about algorithms.
No? You can actually use code to solve problems. Don’t buy into the defeatism surrounding leetcode interviews.
Memorizing the common problems gives you a big leg up on being able to successfully pass an interview.
They don’t want thinkers who re-invent the wheel?
What you do need to memorize are a small group of algorithmic designs and have a good sense of when to apply each one. The main ones include divide and conquer, greedy, graph, and what seems to be the hardest of them all, dynamic programming algorithms.
It's disappointing that so few developers know these or are comfortable with these designs since employing them provides significant speedups to what would otherwise involve deeply nested loops or other naive brute force solutions. Becoming familiar with the broad set of algorithm designs is something most competent developers should invest some time in, and it's not like it requires years and years to become good at it but the benefits are enormous.
I agree it’s probably mostly memorized as an answer today, but I don’t think it’s fundamentally a bad question.
Is the problem with leetcode the content or the process? The process is utterly broken, but any time hiring comes up it feels like most complaints are about the content.
There's the group of people for whom doing these "Algos I" problems in university was relatively painless; not that all problems were "easy" but there's an ease to approaching the problem, and with enough continuous effort the problem is solved. These people also tend to have good retention such that 10 years later, they just need to practice LC for a few weeks and they're back in top form, even if they've been building the easiest CRUD apps for years and not working their brains at all. I've seen this firsthand.
There's another group of people who, for whatever reason, are lacking the facilities to calmly and clearly approach these problems. Doing "Algos I" was a serious grind, and the Brain Toolbox for solving these problems falls apart quickly once the final has been taken. Even if doing relatively complex work at their jobs for years, when it's time to practice LC, it may take months to get anywhere near "top form".
Obviously everyone is on a spectrum between and beyond these two groups, and I fall closer to the latter.
Now add on the fact that there's a person watching you who is going to dictate whether you get a paycheck at all or a 20% boost in income. Or you're like me right now and you've been laid off. Now add on that you need to do it in 20 minutes, each minor mistake potentially becoming a devastating error if you don't catch it quickly.
I envy anyone who can just focus on the problem and remove all surrounding context. Still trying to figure out how I can add stress distractions while timing myself.
This is indeed a good thing to be able to do. I'm pretty good at it, but when I'm in an interview situation, I almost always have at least one moment where I start to panic a little and have to tell myself, "you know what you're doing, just relax and turn the crank." And of course, there's an implied "...but maybe you'll just choke," which I have to put out of my mind.
In other words, a huge part of being able to focus on the problem and remove the surrounding context is a sort of confidence that I can probably do fine, so I can temporarily stop worrying about how I'm looking at any exact moment.
There are much worse ones on leetcode, and people expecting you to get the optimal solution are absurd. I fully expect to fail those unless I'm lucky. I don't study leetcode problems, because my interview approach is to first and foremost, implement a naive (aka slow) but correct solution in the time allotted, then engage in a conversation about ideas for improving it (not a rewrite). This has worked for me for decades, and it's also what I expect of people I'm interviewing.
This type of approach allows the interviewee to demonstrate that 1) they can write basic code, 2) they can solve a problem, 3) they can critique their own code and discuss perf implications, 4) they can think of ways to improve it even if they don't necessarily have time for a rewrite, and it allows the interviewer to demonstrate that they aren't a dick who's just playing "I'm smarter than you because I'm in the advantaged position."
They want you to work pretty fast and you only have about 20 minutes to solve one problem at most companies, no way I could work my way through something completely new that quickly.
My interview with Meta was exactly as you described (a CS riddle taken from a textbook, to be solved without running the code or receiving hints). But in my interview with Amazon, each coding interview also included a couple leadership questions. If you want you can look up the exact questions that they'll give you to test what they call their "Leadership Principles"
Also the Amazon coding questions were not taken directly from Leetcode, and were easily reasoned out without prior knowledge of a special algorithm.
Coding questions and system design challenges are individual to the interviewer. Some are good, some are bad, some are leet code, some are reasonable, it's kinda a crapshot. I saw a bar raiser (a bar raiser!) asking path finding algorithms as his coding challenge which is nuts to me. All that signals is if you've worked with path finding algorithms before, or remember your college class that taught A*
But I'll be honest, our interview process is public and online and hasn't changed in a long long time. We select mostly for people who have the spare time and dedication to learn our interview process.
I had made the jump from we->amazon because the article is about amazon, but I realize that isn't super clear to anyone else.
Actually, if you think about it, the whole concept of getting a college degree isn't much different - its not about what you learn in the classes, it just shows that you have the capacity to go through an arbitrary social experience, follow a bunch of rules, learn some stuff, and stick with it for a few years - pretty similar to a job.
It makes me sad when I hear people say things like this. A college education has the potential to be so much more than this.
I took a poetry class, despite not being particularly interested in or appreciative of poetry and it opened my eyes and made me a life-long lover of poetry ever since. Philosophy courses taught me how to think more rigorously and question things many other people take for granted.
There were many other courses which weren't required for my degree that I sampled and wound up loving and learning to appreciate things I never would have otherwise been exposed to... even changing my major because of some of them.
I didn't even have any truly amazing teachers either, so I can only imagine how much better is the college experience of those who do. Having great classmates who inspire and motivate you can be fantastic too... not to mention the potential to make connections and broaden your horizons in all sorts of academic and non-academic ways.
College can change your life, change the way you think, open your mind and open your eyes, and so much more.
Learning the Big O Notation performance of algorithms that traverse data structures isn't so you memorize all the different running times in perpetuity. It's so you realize that performance and the type of operations you want to commonly execute are something you need to consider for the data you have to work with.
If you didn't learn that from your college CS courses, I don't want you working on my team.
Note: I am not saying non-college grads cannot commit to a long term goal, there's plenty of reasons people don't or can't go to college. I'm only saying that a college degree is a signal.
Its also my experience that as you get more senior and focused on a specific skill (I'm an iOS engineer), interviews tend to focus on that skill more than leetcode. I think there are a few stalwart holdouts (facebook + google), but I have interviewed with several trendy big tech companies and none of them asked me pure leetcode - it was always framed around my iOS skillset.
However, for a junior engineer there is no way to evaluate this kind of skillset since it doesn't exist - so Leetcode is a resonable substitute.
I mean that's a big part of what makes it so easy. Near zero "culture fit" or anything random you just need to solve easy problems.
"are you willing to work nights and weekends on a moments notice no matter what?"
I have thought similar to the grand-parent commenter about having Amazon as a fallback in the Seattle area. Not my ideal but somewhere that is always recruiting me and would pay the bills if the smaller company I am working for went under.
Probably not working on the website though, which is hot garbage and has been for a decade.
N > F = G > Apple > Amazon in terms of hiring difficulty, from my impression.
Until recently, their pay was also not as competitive and they had massive turnover rates.
Your account name leads me to believe you've been impacted by this, and I feel for you. I am sorry. I hope you're able to find a new gig relatively stress free and find yourself in a better place.
I hope Parent gets the help they need. I am thankful I cannot imagine a world where... Google's "elite" engineers impacted my world in such a drastic manner.
Good luck to you friend.
You need to make a plan to find your next position, instead of looking for things on the internet to get offended by.
Now they are a bit more bimodal, but they do not necessarily have the highest (certainly they do not beat netflix).
This is only for MS as a whole though, many of the subsidiaries (LinkedIn, Github) have a harder interview circuit.
Snap > G > F > Amzn > Apple = Stripe = Twitter = …
Amazon > Stripe surprises me though
I thought the point was to actually learn the theory behind the question so memorizing isn't necessary? Like for dp questions for example: it's easier to do them if you just visualize the dag
The whole "memorize every question" shtick is the wrong way imo. Just seems very time inefficient to me
https://insights.dice.com/2017/08/22/tech-jobs-last-2-years-...
That means they need a huge candidate pool, since most won't make it through interviews, and most of those who do won't accept their offer since they can get better offers from other companies.
I have never seen or witnessed micromanaging, the holiday system is the best I have seen. Keep in mind I was a fully virtual employee, maybe things are different in office.
I know I can go back there if I like and enter at a level where I get stock compensation right away with a solid salary.
If you collect plenty of accolodates and maybe get a badge or two, they will never forget you.
I think they habe a very good screening process and a pretty good sense for hiring the right people at any level(the requirements are rather high for the salary).
The reason why they like to re hire people is often the immense onboarding cost, anything level 3 and up requires quite some learning and training time before you can even think of being productive. If I was hiring, there is no way I would hire a level 5 from outside amazon if I could give that role to an experienced level 4 employee. All teams are pretty huge, think of lets say 10 head team, within the first six months, they will habe 2-3 months of training and upskilling, and really, you have to habe that training to do things like vcs, vat etc, as you will at least have to have some fba skills for that role.
If Amazon is letting people go, it must be pretty bad, usually they are not cheap about redundancy, theu are wise enough to be ready for spikes in business. Not sure what has happened there and I strictly speak for office jobs in europe, everything else , I do not know. The whole thing is quasi subsidised by aws and this comes bit as a surprise to me.
I prefer bit more risky endeavours and chose amazon whenever my risk apetite has decreased.
Amazon is a rather solid employee if you perform, just be on time and have good adherence time, as a company with a million employees, this is understandable. It is also much less chaotic than you would imagine from such a giant corporate entity.
If they need you for programming, aws sales, language skills and tax matters, you will be doing fine there. On tax matters or newly established teams, the next level is always in sight and within reach. I hope the severance packages will be fair. I struggle to understand the bad rep for amazon seen online, working for musk or google is many times worse. Facebook used to be pretty good from what I hear.
Maybe its all individual perception and a bit of luck or misfortune.
As for the screenings, yes, they do, but they do not care about memorized things, they try to care and see how you start to deal with an issue.
They look completely insane, recruit anyone with a keyboard and might even pay well.
I knew a guy who would passed up working for Apple for a relatively unknown non-FAAANG company.
People have their reasons. It's not that everyone working for Apple is lesser than. It's more that this guy had his own reasons.
To each his or her own.
Amazon isn't selective in hiring L4s, it hires some people who simply can't code and PIP them in next 6 months.
It is just how Amazon chooses to operate.
Good ones are still there though, just varies very big from team to team, org to org.
Essentially, Amazon engineer means nothing significant, the bar isn't consistent across its body
I think Amazon engineers are - by and large - pretty great actually, worked with more than a few ex-Amazon engineers to know.
This was, and I admit, an offhand comment of which I should have explained this context better.
I also don't believe the interview is "easy", but it felt available and I'm someone who - even for companies that don't crazy rigorous hiring practices - goes really deep before any interview, reading many weeks in advance worth of stuff about the company and their hiring process, learning etc. I practice alot, so I felt like I could do well with the Amazon interview. In fact, I did one once before and it wasn't nearly as bad as I thought it would be, it just didn't work out at the time for me to join.
I say fallback in the sense that I felt confident I could interview there and apply without much friction. I got alot of LinkedIn invites from recruiters - typically once a week - for over a year.
I also don't believe the interview is "easy", but it felt available and I'm someone who - even for companies that don't crazy rigorous hiring practices - goes really deep before any interview, reading many weeks in advance worth of stuff about the company and their hiring process, learning etc. I practice alot, so I felt like I could do well with the Amazon interview. In fact, I did one once before and it wasn't nearly as bad as I thought it would be, it just didn't work out at the time for me to join and I had to pass on the opportunity.
Both are bets to create a new platform as they feel threatened by Apple & Google's dominance on mobile.
Meta should take note. Alexa is widely adopted (# of devices) but has little engagement and still hasn't broken outside of the most primitive use-cases (play music, remind me, etc)
https://developer.amazon.com/en-US/alexa/alexa-skills-kit/ge...
https://developer.amazon.com/es-ES/blogs/alexa/alexa-skills-...
Meta tried to create a new market with the Metaverse, but Amazon overhired in their Alexa department because they were surprised by the financial success of smart speakers and wanted to double down.
Anecdotally, I often see the trashcan speakers in peoples' kitchens, even if people usually say that they only use it as a fancy radio alarm clock.
I rarely meet people who have tried Oculus' recent hardware, and those who have are usually gadgetheads who keep it in a closet as a party novelty. There was a spike in interest when Valve released the Vive and Oculus was an independent entity, but that was more about gaming than social experiences, and it seems to have tapered off in my social circles.
But I totally disagree with the comparison between Alexa and the Metaverse. Alexa has adoption and struggles with monetization, while the Metaverse struggles with adoption but would have endless possibilities for monetization.
What is condemning a lot of Alexa teams today is the complete inability for Alexa to be anything more than a music speaker that also tells you the weather and sets timers. It's tedious to interact with and it's impossible to monetize, just because of how limited the "interface" is.
The Metaverse will never struggle with the same problems. It's not gonna work, but not because it can't be monetized.
And perhaps you’ve forgotten, Bezos isn’t CEO any more and doesn’t have anything to do with day to day Amazon.
The weird thing is that the old industrialists like Ford understood this. They achieved monopoly or cartel status, and recognized that things like pricing, work schedules, and layoffs had actual feedback loops with their revenues and profits.
Then again, maybe they didn't have the accounting technology and large scale macroeconomic measures to show that was a bunk idea.
Those days of world wars probably had more of a collectivist survival view even in the super-elites, those days are long forgotten.
It's imaginary:
https://medium.com/bull-market/there-is-no-effective-fiducia...
https://www.nytimes.com/roomfordebate/2015/04/16/what-are-co...
https://skeptics.stackexchange.com/questions/8146/are-u-s-co...
Should we apply the same logic to your life? My life? Everyone?
I doubt many (if any) cuts are being made in EC2/EBS/S3/etc.
Be willing to do the boring, unsexy stuff that is at the foundation of the business. You'll never be the hotshot, but it's extremely unlikely that you would get caught up in layoffs like this.
It depends on your definition of hotshot. If you stay in the core part of the business and reliably contribute, your star will definitely rise and almost certainly be noticed in some capacity, even at the highest levels of the company.
You're not going to be the poster boy, and trade magazines aren't going to beat a path to your door for an interview, but if job security and absolute authority over your own environment is what you expect.. that's definitely on the table, even in the "boring" parts of the company.
This I've found to be especially true and take less time in any organization that relies on commissioned sales. There's an incentive for internal recognition in those environments that improve the calculus here quite a bit.
There are many teams in organizations like EBS/S3/etc working on the growth and next frontier of those services - but those teams are still far less likely to be cut in a layoff than teams doing similar work in riskier organizations. Why? Because layoffs are allocated from the top first. The reliable and profitable S3 org as a whole will be required to lay off far fewer people than the Devices org that is losing $XXXXXXXX/year.
This is purely anecdotal but I shared this to give other devs that may feel like "this is the end", some hope for the future. The reality is that software development is almost ubiquitous; almost every industry is being touched by it.
We have to keep improving and wait for the whiplash when the time comes (prob. 2023Q2 at best or 2024Q2 if things get worse).
Check small-medium tier companies with WFH and try to move to a low-cost city. You'll get the best of both worlds, hehe.
But what’s the logic behind them?
So on one level it's a bribe.
Which reminds me, what ever became of O3DE (Lumberyard)? Seems like they should refocus some hiring there to get any market penetration.