Typical Day of Average FAANG Software Engineer?

I was an SDE2(L5) at Amazon, and SWE2(L4) at Google, and I know of SDE2s at MSFT.

This is an interesting question, and I get the sense that what you are looking for is what kind of effort it takes to be "meeting expectations" to "exceeds" at mid level but not try so hard to get promoted. Note most FAANG expect promotions to senior, with Google being an exception, "try to not get promoted" isn't helpful long term.

In short, I don't believe overtime is frequent and isn't expected, but can happen from time to time. I'll split my answer into "what I've seen" and "what I recommend".

Sorry about the essay in advance 😅.

Workloads

• The majority of engineers I've known don't work overtime, at least not consistently. I didn't and most of my colleagues rarely did either.
  • When myself or people I know did put in overtime work, it was generally due to (1) oncall / off-hour outages / executive escalations (I got a Jeff Bezos "?" Email once.)(2) aggressive deadlines for projects, which would happen once in a while (a weekend every couple of months or so?)
  • Aside from oncall, I've only worked overtime for projects because I wanted to get them done by the certain date. No one's ever asked me to work overtime.
• If you are not oncall, you don't need work emails, slack, or any other communication on your personal device.
• Majority, up to 75%, of your time is tasks related to coding (reading code, debugging code, writing code, reviewing code) when not oncall. This can fluctuate, depending on the stage of the your project (you'll usually get 1 project at a time)... typically around the beginning and the end a project you spend a lot of time coordinating your project and talking to people. Then you'll have some chunk of your time (5-10%) taken up by team activities.
• When oncall, it generally takes 120% of your normal time, and you need to plan your personal life around it. Pages in the middle of the night happen. There's generally no time for project work when you are oncall either, but you usually can skip team related meetings if you got urgent stuff going on.
• You can generally work whatever work hour you prefer, but you won't have much control over the timing of your team meetings, and these tend to run 10am-3pm.

Strategies to not overwork

Fundamentally, as an mid level SWE, you need to be (1) independent, and (2) effective, to get good performance ratings. You can do this without overworking most of the time.

• Independence
  • Know your people (Who knows what and who's helpful? Who is the gate keeper?)
  • Know your processes (How do launches work? Some processes are very LONG and you need to know to start them early.)
  • Know your system (How do you debug your system? Can you explain to others how things work?)
  • Fundamentally, if you are able to unblock yourself using these above knowledge for your projects, you'll be good.
• Effectiveness
  • Good time management matters. No one cares whether you work overtime, or when you do your work, but you need to get your work done. You need to know when you are most productive and manage your focus, see this video for more tips.
    • Are you a morning person? Come into office early before anyone is there and crank out your work before your daily standup. You can "chill" rest of the day and head home early. I did this a lot.
    • Are you a night owl? Show up to work right before your first meeting and crank out your work in late afternoon or do it in evenings instead.
    • Additionally, establish clear boundaries between work and personal life. Turn off slack/calendar/email notifications whenever you are not oncall. Even better, don't have them on your personal devices at all (I don't!).
  • Good code quality and high code velocity matters.
    • If you are able to crank out good code, quickly and efficiently, and get them through review quickly, you'll rarely ever have to work overtime. This amazing Taro video goes into more detail about myths around code velocity and code quality. This is by far one of the most important skills to have as an L4.
      • Most engineers that do work overtime do so because they struggle at code velocity (and in return code quality). It's a vicious cycle. Avoid it at all cost.
  • Being good at incident management matters.
    • Knowing how to handle pages is super important. If a page goes off in the middle of the night, you need to be able to quickly determine whether it's a real issue so you can go back to sleep. This requires a pretty good understanding of your team's metrics and how to read them. This shouldn't be hard to pick up (find someone to shadow) but might require 2-3 times oncall to get used to it.
    • You also need to know when to escalate - if you don't know what to do or you can't make the decision, escalate it to your management chain. Or if you need knowledge of a peer to address the outage, pull them in as needed.
      • I once had a partner team page me to try to get me do some work off-hour to unblock their release, which wasn't part of our team's protocol, so after some back and forth I just paged my managers and let them handle the discussion

Apart from focusing on behaviors, choose your team wisely - you can generally get good answers to these questions from talking to team members (beware, managers can give rosy answers).

• How healthy is the team's oncall systems? Do you have to be oncall at all? (Some teams don't have oncall at all!)
• Does the team historically been pretty good at estimating projects? Do managers and leads in the team proactively shield the team from external pressures?

Avoid some of these following L5/senior level work.

• Mentoring your peers. Keep relationships professional and help when you can, but you don't need to actively look for mentees. Limit regular 1:1 to those with your manager and your tech lead and formally meet your other teammates on an ad-hoc basis whenever needs arise.
• Multi-person projects when possible. These require more coordination. Prefer big multi quarter projects you can do mostly on your own.
• Getting interns and being the main person onboarding new teammates. Though be generally helpful when they do have questions.
• Being the main code reviewer your team. Prefer being an occasional / backup reviewer. Or being a primary reviewer for a sub system.

Please note that these are all fairly natural progressions and are extremely rewarding, so I don't generally recommend avoiding all of this. You need at least one of these to reach exceeds anyway. However, this is a possible way to reduce time commitments at the cost of career progression.

I worked at Amazon as an L5 engineer, then L5 software development manager, then promoted to L6 software development manager. As such, I only worked in a mid-level engineer role there. What is going to impair my ability to answer exactly as you want to is I didn’t really do what my role entailed? I was glue, and sometimes that was coding, but a lot was being a de facto TPM, solving one big thing that impacted a lot of teams, and other weird things.

I will tell you what I saw as more common for the role. At first in video the L5 SDEs were the senior people, even if it’s a mid-level role. There was one L6 that was drifting away, and 3-4 L5s, with… I dunno, 20-25 L4 engineers we supported. That ratio meant a lot more support via code review, design review, triaging issues, validating test strategy with QA, arguing with counterparts on the devices side about requirements, and so on. I would expect a TPM or senior engineer to do a lot of those things.

In my second org, things were a little more normal. L5s were the coding workhorses. They did design some subsystems, led projects with a couple of other engineers on them, did some cross-team work, but still had to do a lot of the coding. The L4s were slower, needed more handholding, and so on, though many grew very quickly. I don’t recall a hard breakdown, but would say that meetings were 8-10% of their time, reviewing code 10-15%, reviewing designs 3-5%, planning 10%, designing 1-3%, oncall/operational support 10%, other weird overhead 5-10%, then coding in what’s leftover (37-53%). As they grew toward senior, the coding shifted down, mentorship, reviewing, ombudsperson work with other teams would go up.

Maybe this helps?

This is a really hard question to answer, but we'll shed a ton of light on it in our upcoming event: Should You Work At FAANG? - What Big Tech Is Like For Software Engineers

So the "average" Big Tech engineer is probably L4 (I'm using the Google/Meta standard), which is mid-level and getting the average rating with maybe the one above every once in a while. They would probably have some of these attributes:

• Working 45-50 hour weeks regularly (so a good amount of overtime)
• Taking 1 hour for break across lunch and other small breaks
• Is pretty stressed out meeting expectations and project deadlines
• 20% time in meetings, 50% dealing with code in some way (writing, reviewing, debugging), 30% for other stuff (writing docs, helping others, breaks)

Again, this will vary a lot and Big Tech isn't a monolith. You literally can't just be L4 at Meta for 2-3 years, as you need to get promoted to senior or get fired. Meta and Amazon tend to push workers much harder than Microsoft and Google.

In the meantime, you can watch the following video to get some insights into this before the event: The Real Pros And Cons Of Working At FAANG And Big Tech

Note most FAANG expect promotions to senior, with Google being an exception...

I think this is just for Meta. For Amazon in particular, SDE 2 is terminal, which makes sense given how hard the SDE 3 promotion and how many engineers get stranded at SDE 2.

Historically, Netflix only hired senior engineers and above (they only had 1 level), but they are now hiring across all levels (including interns), adopting Google's leveling structure (L3 for junior, L4 for mid-level, and L5 for senior). I'm unsure if they have a similar policy to Meta's up-or-out.

I don't know much about Apple as it's more secretive, but I don't think you're explicitly expected to progress to ICT4. I know a few people who are from Apple, and they mentioned that promotion is on the slower side too.

Thanks for all the feedback everyone :)