Amazon

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 and service-oriented architecture.

Some well-developed systems and tools as part of the dev. environment.

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 lay 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 into believing otherwise, that this was not the case.

Reaching up the chain shouldn't result in an escalation being sent back down to the original manager upon whom the escalation was brought. There shouldn't be development teams of two being managed by one manager, and likewise, there shouldn't be development teams of greater than 10+ managed by one manager. Teams should not have a TPM act in place of an SDM's role. An SDM should not get promoted to "the next level" if they neglect the duties of their previous level; in my experience, this has all too often been the situation.