I've personally never thought of Uber engineering as the pinnacle of contemporary engineering teams, is that a common sentiment for others? I know they're popular, but I thought it was mostly due to the pay scale / name recognition, not technical quality.
It took me a second to correctly analyze the sentiment of “hot shit.” I realized it means “really good,” as opposed to, for example, “steaming pile of shit” which means the opposite.
The expression “shit hot” is a superlatively good thing. I don’t ever recall hearing “hot shit”, although perhaps it is a US term or a modern usage. Urban dictionary defines both.
I had 6+ years at a FAANG. It was awful. I would never go back. I happily took a 20% pay cut to go elsewhere. This said, I learned a lot (both good and bad) and it has been a good reference point for my career.
So I recommend all engineers to strongly consider a FAANG while they're young and can tolerate a bit of burnout. Learn how the big companies do it, pay attention to what's good and what's bad, and keep that perspective with you in your career.
But be honest with yourself ahead of time about what would make you leave and follow through with that. "Golden handcuffs" of high pay is a real thing.
Not all teams in FAANGs result in burn out or require careful through about joining. I've been at one of them for 6 years and still find my work life balance to be sane. In fact I enjoy what I'm doing quite a bit because of the business space I'm working in and the quality of peers.
Another data point: I've never felt pressured to work more than 40 hours a week, and have probably averaged quite close to that over my FAANG career. Recently, with pandemic/WFH/less-to-do-outside-work, I started working some on evenings/weekends, and my manager asked me to stop because he doesn't want to have that kind of team culture.
It likely depends on the team and area of company. Any company of reasonable size will have a distribution similar to bell curve of teams ranging from excellent to complete shit shows. Most fall somewhere in the middle with diverse pros/cons depending on the tech stack, connectedness to customer and where their software falls in its lifecycle from shiny new to dusty needs replaced.
You get lucky rarely with an awesome team and usually fall in middle with some gripes. If you get into a shit show head for the door as fast as you can or stick around to learn a thing or two about what NOT to do.
Yeah, but if you're not already in the job, the distribution of "teams that are currently hiring external candidates" can be quite skewed towards the worse side of things, and if you don't know this going in, you'll have a very bad time at most large organizations.
A successful strategy is quite frequently to treat your first team at a company as just the second phase of an interview to get into one of the better teams in the company. Depends on the company, to be sure, but I've definitely seen many instances of "we're a good team, we know it, we'll happily poach good engineers from any team we like". It helps that the good engineers are going to be unhappy with their current team and looking to make the switch, anyways.
If you don't switch teams within your first year or so, it usually means you a) got very lucky at random, b) got into a good team because you knew someone internally with good info and were able to short-circuit the process, or c) you failed to network/interview well enough internally to move up, and you should probably either be okay with a dumpster fire or move to another company.
Funny, that was my first thought as well. Recently read their engineering blog post from 2012 on the API gateway + UI system [1] and thought it was really cool and made a lot of sense (in their specific, truly massive use case).
From recent memory, I can't recall Netflix really reinventing the wheel a-la-OP/Uber.
> I can't recall Netflix really reinventing the wheel
Netflix has many private and public projects that have alternatives that could have been adopted. I'm glad they didn't, because Netflix releases quality product and I'm super appreciative of their contributions.
You can bet that working on the Google Ads teams is far more 'boring' than Stadia or Glasses. Similarly, at my FANGAM company, the most boring teams are also the most stable.
Slow shipping is tied to coordination more than standards (although if the standards are enforced by testing from another team, there's your coordination). If the standards are self enforced, you can still ship frequently, but maybe not a lot of big releases. Small teams and decoupled work where possible helps.
I can only quibble about boring though. The code changes may not be exciting, but the environment can be. Some external event that spikes traffic can test your high standards, and may need remediations (in which case, I hope you can ship fast). Of course, boring is actually nice.