Block

Great worker treatment. Work whatever hours make sense for you, and take off however many days you need.

The office environment is terrific, and they provide you with great laptops and other equipment you need to work at home.

Diversity friendly, for every kind of diversity you can think of. There is even funding for communities that are centered around minorities of every possible kind.

Great software development infrastructure. You get a reasonable deployment system, a staging environment, a CI builder, pull requests using GitHub, and ticket tracking using Jira. You get all the local software licenses you may want, for example, top-end IDEs and other tools.

Great mentorship for basic software development skills. This is a top-notch company for a new graduate who wants to learn practical skills they don't teach in college.

Great promotion track up to level 6, so you can quickly accelerate your career standing as a new developer at this company.

A mature process for blame-free post-mortems. This is cool to see and something a lot of companies could emulate.

I'm not sure if this is a pro, but if you are happy pushing papers and smiling through half-truths, you can have a really cushy middle-management position just by sticking around and not causing problems. Great compensation and benefits.

Internal transfers are easy. You can start in one place and then teleport around Block to something wildly different.

Engineers are on-call, and there are no SREs. This is true in a lot of places, but not everywhere.

Expect to spend 1/4 to 1/10 of your life being paged and questioned, and once every few months to feverishly scramble to restore a broken system that customers depend on. I don't like all this, but in fairness, it is a pro if you are newer in the field, or otherwise you are happy to have the excitement in exchange for the hands-on experience.

It feels insane, all the time. You are forced to use software, standards, policy documents, migration guides, and requirements documents that just don't provide what they are supposed to. Your peers will use them anyway and say it worked out, which means you'll stand out as a troublemaker if you don't say the same thing. Nobody from above checks that any of the review documents actually line up with what the software does. So there's a pervasive atmosphere that what everyone is saying is fairly fake when you go look beneath the surface.

Meeting hell. Quite a lot of people have over half of their calendar full. They'll suck you into it if you don't push back very hard. Even after you push back for your own calendar, all these people are talking each other into crazy stuff, all the time.

The majority of mid to upper management has a policy that they just want to hear if there is a problem, and otherwise will trust you. That sounds great at first, but the problem is that certain functions have a single gatekeeping team, and it applies to them, too. As soon as you run into that, you have to dumb down what you're creating to match what they insist on. You can't push back effectively on what they do, because there's no accountability that they're actually doing it.

A lot of the larger technical plans don't make any sense. New components will be put forward to unlock a problem, and a large team formed around its development, but it will either not be needed or will not have the right things in its design to help the stated problem. Other teams will willingly say they're waiting on the flashy new component because it gives them cover by blaming another team for their own lack of progress. The new component sometimes implodes, but in some cases goes on for 5+ years without success and with avoidable fundamental design problems.

Deals with large partner companies are exciting at first, but then due to the above problems, fall apart when we don't deliver. The partner has a chance to walk away and generally will do so unless they've been acquired. It can be very demoralizing to be anywhere near one of these deals, because you'll know what to do but have to watch it go slowly bad, anyway.

There are corrupt managers, and HR will play ball with them. HR and management will do joint presentations at 100-person meetings and joke around like they are just the best buddies, when it seems like those are exactly the people HR ought to be scrutinizing. In my worst experience, I had one manager support and edit my promotion packet, but my next manager overturned my promo. The new manager told me that it didn't matter what the bullet points in the leveling guide were, that they had asked a specific individual who everyone knows must say yes or no to level 7 promos, and that individual had said no without looking at my packet. My new manager had not looked at my packet either, and furthermore brought me to a surprise meeting with HR and said it was a performance violation to respond to performance review by talking about other things I have done.

This was an impossible situation and felt very calculated. The manager carefully said I was under performance warning but not a PIP, and they went on to explain that that meant I could transfer off their team. They anticipated that I would talk about my contributions in rebuttal; the complaint was on groupwork, so I pointed out some multi-team projects I had coordinated, which in some cases spanned the majority of the company. The literal complaint at my surprise HR meeting involved telling an upper manager a surprising architectural suggestion when I was asked to do so at a major meeting, thus embarrassing the upper manager. This is obviously not a bad performance demonstration unless you really think the suggestion is impossible, so they changed it to a complaint about organizing large multi-team projects, but I was not allowed to discuss the large multi-team projects I have been part of, because the formality of this HR ritual was that I'm supposed to listen to feedback and accept it at the implicit threat of being additionally dinged for not being good with feedback. So I sold my soul and said I understand what I'm hearing and will try to do better, but it wrecked me. I was more than happy to transfer out, which on the bright side is very easy at this company.

If this is happening to other people, then all the L7s in a large chunk of the company must be the personal appointees of this one individual, and the elaborate process around making packets and seeking peer reviews is more of a formality after the real decision has already been made. As well, I can see why unworkable architectures are being pushed all the time, because look what happens if you speak up. This won't affect new grads and other people early in their career, but it can be psychologically rough when you try to build and accomplish bigger things.

Talent retention is low. I've had almost as many managers as I've had years at the company. My first two managers have left the company. Flipping that around, you have to go 5 levels of management above me before you find someone that has been in their role for more than two years. Of those 4 newbies, 2 of the 4 are new to the company as well as to their role.

The same thing happens with your partners around the company. You build relationships and then learn that the person has changed roles or has left the company.

Almost nothing is built out and then retained. People will go nuts on a problem area for 1-2 years, but then get their project paused, get disillusioned, and transfer or quit. The new people that replace them will usually say the old thing is terrible and will want to start over.

Lines of ownership are frequently unclear. Instead of positioning people to make decisions and live with the results, most things you suggest will lead to a number of additional people being tagged into the discussion, and before you know it 5-10 people are on a call and in a doc making off-the-cuff suggestions and trying to make a decision by averaging all the extreme statements together. Likewise for your own team's software, people will "contribute" to it and then say they project worked, and you have very little power to push back on what they do in your software. They'll then turn it around and say you're on the hook to rewrite it the correct way, in the next quarter.

So all in all, it's a fine place to start a software engineering career, but really bad for people who want to build and launch bigger things.

Identify capable people, and let them be in charge of a domain within their skillset. Your good people are being eaten alive until they burn out, and your ranks are filling up with people who play the corporate game.