Amazon

After working as a college intern at the company, I was offered a full-time position, which I accepted.

As a first-time job out of college, I can't recommend it enough; just make sure you're on a team working on an unreleased product.

An Amazon team in heads-down development mode is an amazingly productive and inventive thing. Projects are rapidly prototyped, torn down, and built anew. The build system is bar none the best I have ever used; if you need some library to do something, you just depend on it. Done.

We had a senior principal engineer acting as a sort of roaming quarterback among our teams, and he frequently sat in on design brainstorming sessions. He also sat ten feet away from me, so bouncing ideas off of him was frictionless and really helped me grow as a fault-tolerant systems architect.

People wear many hats at Amazon, and you can quickly make a name for yourself as "the X guy" if you devote yourself to being an expert in X. Plans change, and you can get a golden opportunity in your lap if you're lucky. For me, it was defending our system architecture against three senior principals.

Get your name out there, and you'll have other (potentially cooler) teams trying to headhunt you from your current one. I would recommend this strategy: stay on a project long enough to make a name for yourself in some way and then jump ship to another team. A year and a half to two years is a good periodicity for this process.

The best thing about Amazon is that if you find yourself getting tired of the same old drag in your current position, you can jump ship to another team and work on something entirely new and exciting. This is not Microsoft: there is little animosity between teams, and no hard feelings will be had. You can be writing servers in Java one year, virtualization modifications to the Linux kernel the next, and messaging systems in Erlang the next.

Corporate culture is good. There aren't as many hokey ice-breaker or get-to-know-each-other events as in other companies. I once heard the company described as "having a good drinking culture," which certainly was true within my team. Our outings were more like pub crawls, with pool and bowling often thrown in as an afterthought as we wandered around Capitol Hill. Good times were had.

The pay is pretty good too, and I hear the stock ain't doing half bad, too.

In summary, I wholeheartedly endorse Amazon as a first out-of-college job for people who want to learn a lot about anything. Just don't dig down too much in one team, and you can rise to prominence in any area you want. Within a year, I was designing and implementing key pieces of our architecture, and my ideas and proposals were taken as seriously as those from people with a decade or more with the company.

N.B.—My team probably ranked in the top five for pager pain metrics. I've seen the histograms, and there is a long tail. You'll likely find yourself in a team with far less pager pain, but be warned that it can be bad.

Yes, you have to carry a pager. Yes, it can be hell. You will invariably try to go to a pub one hour before your rotation ends, only to be paged into an event that requires a conference call with multiple VPs and on-edge datacenter engineers. You may go to bed at 1 AM Sunday night, be paged at 5 AM Monday morning, and not stop firefighting until 2 AM Tuesday. It can be draining.

People say Amazon never ships a version two of anything, and I think this is the reason why. Asking your educated thought workers to sit around doing menial "keep the stack running" tasks can be a pain, and the small team sizes are great and all, but you'll find yourself wishing for more people to share the pager pain; misery loves company.

At one point, my project entered a dark phase in which all feature development tasks were superseded by the need to just keep the service up and running. Hacks and kludges were put in place to reduce the load, and extreme measures were taken to keep us up and running. In retrospect, our project was characteristically different from other web services, and this sort of thing was predictable, but we didn't get ahead of the problem quickly enough. One tends to blame management when these things happen, saying "we'll take the technical debt and put it on the backlog for now" one too many times can result in one hell of a lot of interest to pay off.

The whole period seemed like hell when it was happening. A team member switched teams, the intern went back to college, the managers did a nice little switcharoo, we had three developers to actually code. But it passed. And I got an offer with another team with essentially no on-call rotation and whose work I really admired. I didn't take it because I knew I'd soon leave the company due to a cross-country move (I didn't want to join a brand new team for only two months), but the thought crossed my mind.

So, if you have a needy family, enjoy sleeping, or can't bear the thought of a pager, maybe Amazon is not for you. If you're willing to look past that in order to work at a company that actually ships products (rather than having them always in beta or research), I say the pain outweighs the gain.

Being second to market is not always the end of the world. Ship early, ship often is fine, but when crucial flaws are found, putting band-aids over them and saying "we'll take the debt" is not a good solution. We don't have anyone nearby in the web services category, and I'd rather see things ship perfect than them ship first and have terrible performance issues.

But I'm not a manager and I'm not a businessman. Perhaps the added personnel, hardware, and emotional costs are eventually overcome by all the cash that comes in.