Amazon

Learn so much about building, delivering, and monitoring software. Work with tons of smart people. Fantastic build and deployment tools compared to other software shops. It needs to be great to work at Amazon scale. If you think you need a tool, chances are someone has already built it. Your developer box is in the cloud. Whatever hardware you need for the job, it’s there. Decent pay compared to others in Vancouver, for the first while anyways. Vancouver teams strive to have good work-life balance. Since your experience is heavily dependent on your management chain and so many teams have open headcount, if your current team is not a fit, there is probably another team that is. Internal movement is encouraged (better to keep you at Amazon than lose you). Amazon values aren't just words; they live and breathe the values. Customer obsession is key. You're building at the bleeding edge of the cloud. Some really cool stuff at incredible scale gets built, and more often than not, you can be proud of what you build.

• Though the Vancouver office strives for work-life balance, politics from Seattle come into play. There can be a perception that you’re “doing less work” even if it’s just better planning.

• It’s hard to get visibility with the management chain in Seattle. If you’re not constantly putting out fires, you’re not visible and delivering.

• Not so good long-term retention. A lot of people churn. The benefit of this is getting to know the smart people and where they are going.

• After the signing bonus is up, bonuses afterwards are underwhelming. Many just stick it out until vested.

• Stress from the on-call rotation. You’re not just a developer, but you’re also the one who gets paged when the software your team owns breaks. This rotates among the team. It’s good in theory to get issues and customer problems resolved quickly, but it adds a lot more stress to an already fast-paced environment.

• Good luck getting promoted, especially if you’re in Vancouver and someone in Seattle needs to approve it. There’s so much complexity and red tape here, it seems like it would be easier to quit and get hired into the next level than to get promoted.

• Consolidate specific product teams into one site.

Splitting them between Seattle and Vancouver hurts in terms of communication, visibility, and delivering results between the subteams. Even if you think your cross-site team isn’t affected, it is, and it eventually impacts customers. Management visibility of the other site suffers, and developer morale suffers.

• Put more emphasis on allowing developers to fix problems that cause them pain.

On-call is a huge issue for developer retention, and when people go, their knowledge and expertise goes with them. Systems that keep breaking and paging developers don't just impact developers either – developer pain leads to tired/unhappy developers that have less time to deliver cool features, and short-term hacks to get around that pain, which cause customer impact.