Microsoft

Lots of internal mailing lists to ask questions on, keep up on technology, and explore interests.

Great health benefits.

Decent work/life balance recognition and managers accepting pushback if you feel it has gotten out of whack.

Broad reach, as some products are used by hundreds of millions of people.

Some very smart people. The ones that aren't jerks can also be very helpful and good to learn from.

Heavily against any open source usage or involvement by employees.

Serious bureaucracy; sometimes it takes moving a mountain to get the smallest things done.

Massive, legacy code bases written years before anyone thought unit testing was a good idea. This means massive amounts of complex code with pretty much zero test coverage. Oh, and you get to change it all. Make sure you don't regress anything or introduce any bugs!

Convoluted build systems and source control management.

Little cross-team collaboration, to the extent you have to request permission to get access to the Office PDBs, and they likely won't give you permission.

Lots of arrogant people. Some won't even bother responding to emails or will be very rude or dismissive, as if it is a waste of their time. These people are usually also the creators of all the terrible mess alluded to above, so good luck convincing any of them it needs to change, since 'it' is what got them promoted at one time.

Test frameworks are a horrible mess: convoluted, unreliable, and arcane.

Branching and code motion (FI/RI) is terrible. Changes take forever to propagate, and when they do, they inevitably leave your branch on the floor for a number of days afterward.

Lots of PMs who seemingly spend their day reporting on your work (and mostly taking credit for the things that go well) to management. They also play bug games to hide bugs around senior management review time and send out update emails with indecipherable tube charts and ridiculous timelines that have no basis in reality. These timelines pretty much show the opposite of what every dev says to them every day in terms of where the project is, what risks are present, etc.

Get rid of people managers who have zero people management skills. So many mediocre ICs choose the management route as they realize they will never make principal or higher in IC roles. They don't do it because they possess any leadership talent or people management talent; most of them actually have negative abilities in this area, alienating the devs that are successful and causing the less talented to play political games of suck-up to try and get a good review, or at least avoid a bad one.

Flatten the overall hierarchy. There are ridiculous depths in the reporting chain such that what I tell my boss and what I see our VP write in an email weeks later literally look like completely unrelated things, even when the VP is talking about the same thing, feature, or area I am. It is a giant game of telephone, except instead of accidental message mutation, it is purposeful to avoid delivering bad news when it arises.

Have your senior leaders focus on business and stop giving busy work to generate reports, meet some arbitrary ZBB date, or involve yourself in bugs or individual customer interaction. You just cause fire drills and wasted time. You aren't an IC anymore (if you ever were), and though we all know you have the power to 'make things happen,' you are constantly making the wrong things happen and costing stockholders lots and lots of value.