Pros
If you're getting into software development and want to touch some of the newest technologies, play in the world of cloud services, work in python or hone your chops as a devop, you'll find lots of opportunities to improve your skills. Due to the flat management structure, you can often just start doing whatever the task is you think is important and become an "expert" in it. Even if you're not really an expert, chances are nobody else cares about it so you get to be the go to person (for good or bad). If you're the type of person that works very well independently and likes to set your own agenda you'll probably feel comfortable in the working environment. Don't expect a lot of communications, and you'll probably be making a lot of things up as you go. At least 80% of the people you'll work for are great folks, they will often spend hours working with you to make sure you get what you need accomplished and the 1:1 time is a great way to keep knowledge transfer and understanding at rock solid levels.
Cons
1. Leadership: Leadership is not a thing here, perhaps we should call them "chaperones" as their only job in life is to make sure we are not too angry and that we don't hurt ourselves. In general, we're like a tech version of Lord of the Flies. We are stranded on this strange island and we're trying to each govern our own little teams. Some of us are good at it, some of us are not. But those that are not often are louder so they win. 2. Lack of Design Design documents are left short, often intentionally vague, and get "sign off" by all teams (who don't really always understand what they're signing off on). This leads to mis-communication, unexpected behavior and supportability problems. 3. Technical Debt We generate technical debt faster than we generate solutions. Many of the development decisions are made by amateurs and they will defend them as "it was a good choice at the time." Nope, it was a bad choice from the start but you're too green to see it. 4. Tons of Meetings If you're like me and find mornings the best time to write code, you'll be disappointed. Usually we've got meetings until noon (Boston Time at least), that will be team stand ups, 1:1's, company meetings, team weekly meetings, project review meetings, sprint meetings, retro meetings, etc. Usually separated by a half hour or full hour so just went you get back into the swing of things...oops, another meeting. 5. Tribal Knowledge Rules Our teams are not great at writing stuff down. This means lots of additional meetings and 1:1 "pairing sessions" to transfer tribal knowledge so others now have the value. They see this as "valuable pairing time" vs. "if I just wrote down how things worked I could get more work done."