Pros
The robustness and company culture/leadership principles. The high level of developer involvement in designing what to build. Large opportunities for relocation to a different US or international office once reaching level 5. Likely enriching learning of highly-scaled, full-stack systems, service-oriented architecture. Some well-developed systems/tools as part of the dev. environment.
Cons
Bureaucratic: sometimes a relatively straightforward change that needed to be made by a package owned by another team could take weeks to get into that team's agenda. Daily phone conferences were once required for my team to get a dependency implemented that lied in a distant service level. Unstable: While working on the Cloud Drive team, I had been around for its rapid growth to 100+ members, followed by a sudden rapid decline. That greater project was a mess. Managers/team situation: There is no "judicial system" as one of my old managers put it -- on my most recent team I had worked on a team comprised of Localization Project Managers, despite my role as a developer. My code reviews would have to go out to the development team, though I was not allowed to sit with them after several serious discussions with my manager on this. Depending on your proximity to your manager's manager, there may be nothing to do to prevent these sorts of scenarios, so be very careful when choosing a team when you are allowed to do so. My initial team consisted of 5 developers initially, going down to 2 after a split a few months later. The other developer and I received little interaction from our Software Development Manager who was often somewhere else trying to move up himself, and we worked primarily with some Technical Program Managers. The biggest issue in this situation was that the nature of our work was not the type of project needed to get promoted to SDE-II, though our half-of-the-time present manager would often persuade us in believing otherwise that this was not the case.