How to navigate the difficult SDE 2 to SDE 3 promotion?

Profile picture
Mid-Level Software Engineer [SDE 2] at Amazona year ago

I have been at SDE 2 for a couple years now, and I feel like getting to SDE 3 is unnecessarily complicated. I've gone through multiple teams, and the recurring theme is that there isn't enough SDE 3 scope for me. You also need a lot of documentation (think 5+ pages) to show that you have the sufficient impact to deserve the promo, and that's really daunting as well. Any tips on how I can find that SDE 3 scope and navigate this senior promotion in general?

59 Likes
6.2K Views
3 Comments

Discussion

(3 comments)
  • Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    This promotion at Amazon is notoriously difficult, so I have a lot of thoughts here. I'll split it into 2 parts:

    1. Finding senior scope
    2. Documenting your impact

    Finding Senior Scope

    • Of course, the team has a huge impact on the availability of scope. To figure out how to find those teams, I recommend going through this Q&A around questions to ask to vet a team (also from a mid-level engineer: "What questions can I ask a potential new team?"
    • However, something I really recommend for every engineer to do (especially mid-level/senior engineers) is to flip the mentality of "I need a good team to have good scope to move to the next level" into the more self-empowering mentality of "I will create the scope I need to move to the next level". I believe this is effectively a requirement for the mid-level to senior promotion, especially at FAANG where the bar for SWEs is so high. In terms of resources on how to create scope, I recommend these:
    • On top of expanding/creating scope, another dimension many mid-level engineers don't fully realize is that quality of execution matters a lot. You can always ship a project with:
      • More scalable code
      • Less production issues
      • Less thrash
      • More detailed analytics to better understand its performance and impact in production
    • I have seen many engineers get promoted to senior/staff level because they took the scope/projects they did have and shipped them far, far more smoothly than everyone else around them. The main lever to pull here is to get better at system design, and I recommend my System Design Series to learn just that, which includes a very thorough 9-page system design doc you can use as a template: System Design Masterclass: Taro Playlists
    30 Likes
  • Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    Documenting Your Impact

    • The most important thing here is to represent yourself well in the self-review part of the performance review. We have a great video on how to optimize that here: Making The BEST Case For Yourself In Performance Review: The Self Review
    • It's true that showing the necessary impact and behavior to merit SDE 3 (and FAANG senior engineer in general) is hard, and my main piece of advice here is to document your progress here over the entire performance cycle as opposed to scrambling at the very end to compile everything. In general it's good for software engineers, especially senior+ engineers (and those targeting these promotions) to get into a habit of doing technical writing regularly. Tactically, the biggest piece behind this is writing a lot of great project updates, which I cover in-depth here: "How to get more visibility on work?"
      • In my case, this turned my self-review at Meta largely into an exercise of largely just linking things together instead of building the entire case for myself from scratch. A big part of my growth to E5 (SDE 3 equivalent at Meta) was making sure that all my projects and their impact were impeccably documented, especially in the launch posts and milestone celebration posts. My self-review was always a sea of links to these posts, which means that the many pages of documentation I needed to make my case was effectively "pre-loaded".
    • In general, it's good to keep a brag journal, which is a long-running document of your accomplishments. This is necessary as not all of your accomplishments will be covered in project updates - For example, if you have found success mentoring a more junior engineer, you wouldn't really have a "project update" post for them. I think most people who do the brag journal have it as a separate document, but I personally sort of "hacked" it by always having a "wins" section in my manager 1:1 notes. When I needed the "brag journal" contents for writing my self-review, I would just skim through my manager 1:1 doc. I detail my process in-depth here: "What’s a good example of a 1:1 document to help your manager keep track of your accomplishments?"
    23 Likes
  • Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    4 months ago

    It's been a long time since I last commented on this question, so here's some additional resources and thoughts:

    11 Likes