92

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

Profile picture
Mid-Level Software Engineer [SDE 2] at Amazon2 years 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?

15.3K
4

Discussion

(4 comments)
  • 44
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    2 years 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: [Course] Frontend System Design Masterclass - Building Playlists
  • 31
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    2 years 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?"
  • 18
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    2 years ago

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

  • 16
    Profile picture
    Senior Engineer @ Amazon, Founder @ Roman Yusufov Coaching
    7 months ago

    Getting to SDE3 was one of the hardest steps of my career. It ultimately took 4 years to get there from the time I was hired. I went through a lot of frustration because I either didn't understand the process, didn't have enough buy-in at the start of projects or had to navigate circumstances outside my control (descoped projects, canceled roadmaps, etc).

    So, I wanted to share some things I learned along the way.

    There are a few key things that need to align to get the SDE3 promo:

    1. Being a solid SDE2 performer. Work with someone you trust to assess your readiness for the next level. I personally struggled here because I tried to get to SDE3 while I had significant gaps to fill at SDE2.
    2. Having a good manager. This isn't always within your control but I believe a good manager is responsible for up to 40% of your promotion success. Promotions at Amazon are manager-driven. The groundwork starts long before your promotion panel. There are two parts to this:
      1. How experienced and comfortable they are with the promotion process. They have to line up the projects, get stakeholder buy-in, write the promotion doc and ultimately advocate for you in front of the review panel. I've seen multiple botched promotions where the manager was either underprepared, failed to gather the right data or wasn't confident enough when challenged by the panel.
      2. The quality of the data they're able to gather to support your promotion. Part of this comes from you. You have to provide the right quality, delivery and performance metrics of your projects. The rest comes from them gathering the right feedback from key stakeholders and their own assessment of your performance.
    3. The right scope of technical work for SDE3. This is one of the most challenging parts. Unfortunately, there's no magic formula for this. But, there are a few things you can do to help yourself in this process.

      First, you need to understand what SDE3 scope looks like. You can do this by reviewing designs from current SDE3s, talking to more senior engineers and getting feedback from your manager.

      The next step is finding the right scope project. This is where most people struggle. Below are some ideas but by no means an exhaustive list:
      1. Finding the right project in the existing roadmap. You can work with your manager to assess the complexity of planned projects and which ones will fit the SDE3 bar.
      2. Finding projects that can be expanded in scope. The right scope can come from the way you deliver a project and not the initial set of requirements. Even with limited initial functionality, you can propose a bigger technical vision that can support the future expansion of the product. You don't have to deliver on the whole vision to get credit for the design. The key is to keep the initial deliverable simple but showcase the considerations that went into making it scalable and expandable.
      3. Look for problems with large impact that no one else is solving. I've seen Principal-level projects dealing with metrics improvements. The difference was in how they solved it. Instead of solving the problem for a single team, they solved it for the whole company.
      4. Networking with other engineers and managers. If your team doesn't have the scope you need, you want to be on the radar of other teams that may have the right scope. This requires visiblity into other teams.
      5. There's a "hidden" option that I'll discuss in the bullet point on documentation.

        Lastly, make sure to get any proposed project vetted and approved before you start it. This is crucial. When I was still at Amazon, there was an official process for doing this (although it wasn't required). This will save you a lot of frustration dealing with last-minute disagreements about scope.
    4. Demonstrating LPs at the L6 level. As you already know, LPs are at the center of all roles at Amazon. Having the technical skills and projects isn't enough. You need to demonstrate the key LPs required at the L6 level. This includes Think Big, Are Right a Lot, Hire and Develop the Best, and Invent and Simplify. These are the major differentiators at the L6 level but all the others are important as well.

      SDE3 is a team lead role at Amazon (although there's no official team lead role at Amazon). You have to demonstrate the ability to deliver through others, force multiply and drive influence within and outside your team.
    5. Getting buy-in from key stakeholders. This is a "behind the scenes" thing most people don't realize. Not only do you need other SDE3s to validate the complexity of your projects but you need other key L6+ stakeholders to provide feedback that you're operating at the L6 level. I forget the exact number (Alex's statement that it's 6 people may be right).

      But, the important part is that you have to demonstrate this through your limited interactions with these people. The stakeholders include PMs, TPMs, SDMs of partner teams and senior managers. The more the better. You can't ask for this feedback directly so you have to work through your manager to solicit and process this feedback.
    6. Having the right documentation. You need a solid portfolio of work to demonstrate your growth. This is particularly important if you've switched multiple teams and projects as you're working on your SDE3 promo. Your manager won't have visibility into your past work. They will talk to your previous SDMs (if they're still around) but it's always better to create all the necessary documentation in real time than hope you can gather it later.

      There is also an option to get promoted based on "portfolio complexity" rather than individual projects. This is what happened to me. After working on multiple projects that didn't hit the complexity bar on their own, my manager was able to make a case for promo based on my portfolio of work. I hit all the right checkboxes in at least one of my projects.

    There is a lot more I could say on this topic but I will leave it here for now. If you have any questions, feel free to post a reply.