[skyo]

Yeah, I've heard that some AWS teams can have heavy operational load. If it's important to you to avoid that, you could consider somewhere in WAP/BuilderTools. That's where I work (so yes I am biased), and in my experience the operational load tends to be pretty light throughout the org. On my particular team we almost never get paged. Plus we get to build neat things in this org (remember how Stevey mentioned that Amazon's "versioned-library" system is good?).

Silk is probably a neat team to look into as well. They're building a cool product, they're still a small team, and they have good leadership. The director in charge of it used to be the head of Builder Tools and he's great.

But yeah, talk to a lot of teams and ask them about the things that are important to you (operational load, current/future projects, code quality standards, whatever other things you can think of to ask) and see if any of those teams sound cool to you. I won't lie and say that every place in Amazon is perfect, but if you choose well I think it's possible to find a great team to work on.

[TruthPrevails]

Just now found out that "no college hires" in Silk team. That sucks! College hires are high on energy and enthusiasm. I don't know why teams would not want college hires :(

[srdev]

At the risk of being slightly offensive, college hires are high on energy and enthusiasm but low on ability to produce reliable code (on average). They can produce a lot of code, but they tend to have blind spots when spotting failure scenarios, resulting in "gotcha!" outages or bugs. Its not a big deal if they have a more experienced developer reviewing their commits, but if you're iterating fast on something that's going to be a flagship product, it becomes less tolerable.

[TruthPrevails]

No offence taken :) I understand your point. Silk was something I was really interested in. Tough luck. I wonder whether there is still a chance if I can talk to the Silk team manager.