In my personal experience, the more the org gives off the impression that it is hot shit, the worse it usually is.
I expect it's a variation of "hot stuff" which I've heard in songs from the 1930's.
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.
In general, I try to do this discretely by not pinging people outside working hours or trying to give impression I'm working late. Working late for me is usually working through code or a design at a time when I'm caught in it and don't want to let it sit until I solve it. If this happens I'll start late next day or reduce hours following week and I make sure I call this out during standup so my team knows why I'm signing off early.
It can become a snowball when one teammate sees another working and feels compelled to do same. Kudos to your manager for calling this out.
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.
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.
From recent memory, I can't recall Netflix really reinventing the wheel a-la-OP/Uber.
[1] https://netflixtechblog.com/embracing-the-differences-inside...
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.
Very high standards = Slow shipping = Boring
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.
I don't think this is quite right.
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.