What would you do in the first 30 days after joining a FAANG like company?

Short Answer: Go through the following playlist and follow its advice - [Taro Top 10] Effective Onboarding

Longer Answer: I'll go through the questions 1 by 1.

What would you prioritize?

1. Get 1 small code change in with an extremely high level of quality to show my fundamentals to the team (i.e. prove why I deserve senior/staff) and just get the code working
2. Have a great first 1 on 1 with my manager and establish the cadence going forward
3. Trying to help at least 1 other person (code review and tech design docs/meetings are the most straightforward avenues). Senior/staff engineers are expected to uplift the team
4. Setting up recurring 1 on 1s with core stakeholders on top of the manager (other senior/staff engineers, designer/PM if appropriate, my counterparts on other stacks)

What questions would you ask?

Use your judgment to figure out the best person to ask these questions to. This may adapt over time (e.g. you ask a person and they point you to another person).

1. Whatever questions are necessary for me to contribute to the codebase
2. What's the biggest problem(s) the team is facing right now?
3. What's our priority for the next quarter? For the next half/year?
4. Who should I talk to?

When given your first tasks, what additional/beyond scope extras would you consider?

Not really scope, but the important thing is quality. Make sure that you deliver with a higher level of care and quality than most people on the team, especially the junior and mid-level engineers. This is something that can be easily controlled, especially as onboarding tasks are small. It is hard to impress with velocity as your velocity will naturally be poor at a new company (especially one as rigorous as FAANG).

When it comes to figuring out when the expand scope, my advice is the same as it always is: Look for problems and then do a calculation to see if they're worth solving. The calculation will be units of impact delivered per time spent. The tricky part about onboarding is that your time spent will be high as your velocity is low - A lot of the extra stuff you find should probably be backlogged (just pointing out the problem has value in and of itself too).

When it comes to proper prioritization, I recommend this: "How to figure out what the most important projects are?"

We also have a playlist around creating scope: [Taro Top 10] How To Create Scope As An Engineer

What would you be mindful of NOT to do?

The engineers I saw get fired/PIP-ed in their cycle at Meta were usually L5/L6. It's because senior/staff expectations are very, very high at FAANG (there's a reason why Big Tech usually downlevels, it's for your own good), and if you haven't operated at that level before, it is very hard to catch up.

The common traits I noticed among them were:

1. Poor communication - They didn't ask good questions or just didn't ask enough questions. They were hard to understand, especially with technical communication.
2. Self-centered - They made 0 efforts to help others on the team. Even though you're onboarding, it should still be easy for an L5/L6 engineer to help an L3/L4 engineer or an intern. An easy win I've seen a lot of senior/staff engineers do in their first 1-2 months is to improve the onboarding documentation (I did this at Robinhood and got a lot of kudos).
3. Low code quality - This is by far the biggest killer of SWE performance at Big Tech companies. From interns who failed to get the return offered to PIP-ed L6s, this was a common theme 95%+ of the time.
4. Reactive - At Big Tech L5+, engineers are expected to be very proactive and independently deliver value (this is why Meta literally forces engineers to get to E5 within 5 years). They don't need to be told what questions to ask and who to ask them to. With a few sentences of direction, they are able to find the right people, get the right inputs, and start building the relationship very fast. The senior+ engineers who weren't able to make needed an astonishing amount of hand-holding.

We dive into all this far more here: "What's the difference between a low performer software engineer and a high performer?"

How would you start prepping to figure out what to become an SME in?

You can't, especially at Staff level. While you can sort of homework/study your way to being a decent L3/L4, this isn't really possible at L5 and especially at L6 (Staff).

One of the core purposes of L5/L6 engineers is that they're very flexible. They have fundamental skills that are easily transferable between domains and situations. So you can't really study/prepare - You just need to slot into the team, be dynamic, and find where you can add the most value (and learn that).

As I was growing to Staff at Meta, my manager repeatedly said: "Fill in the gaps". As a Staff Engineer especially, you have to identify the largest problem and morph into a powerful resource to solve that problem. That area can change every year, every half, or even every quarter, forcing you to be an SME-level person on different fields regularly. If you can do that, you're an effective Staff Engineer worthy of working at the best companies like FAANG.

Here's a good discussion that covers this in more detail: "What makes a staff engineer from a technical perspective?"

I also recommend this one: "For a Staff engineer at a Big Tech company, what should their first 3-6 months look like?"