Advice for someone joining big tech from a non big tech background?

Late to the party but this is an important question since we will all face it at some point. Alex already made some good points here.

IMO, besides ramping up & demonstrating your skills are only part of the equation. You also need to build a map of knowledge about your team, your org, the company. Eventually, you want to be able to answer "what are the problems I should solve / what domains i should become expert in" in 6 months.

Here is a framework I stole from the CTO of FB (Boz)

From Boz (NOT me)

— Written by Boz @ FB

Several times in my career, I’ve joined a team whose work was already well under way, where I had a massive knowledge deficit, and didn’t have pre-existing relationships. None of those excuses relieved me from the pressure I felt to establish myself and contribute. Over time, I realized that the natural instinct to push for early impact leads many incoming leaders into challenging relationships as they expose their knowledge deficit and waste time. So, I developed an algorithm that has helped me ramp up quickly — and in several cases — have an impact in a relatively short period of time, while minimizing collateral damage.The first step is to find someone on the team and ask for 30 minutes with them. In that meeting you have a simple agenda:

• For the first 25 minutes: ask them to tell you everything they think you should know. Take copious notes. Only stop them to ask about things you don’t understand. Always stop them to ask about things you don’t understand.

  • The sum of the answers from the first 25 mins will not give you a complete picture of the team's work. That will take months to develop. But they will give you a framework for integrating new information more quickly, which will speed up how fast you ramp. It will also heavily over index on the areas of work under active discussion, which will help you dive in productively to the most critical discussions immediately.

  The nature of what people choose to discuss is a very valuable signal about the problems the team face, as it may be about the work, the organization, or process. Finally, it will give you a sense of the language and terminology that can very often be a barrier to working smoothly with teams.

• For the next 3 minutes: ask about the biggest challenges the team has right now.

  • The answers from the second question give you a cheat sheet on how to impress the team with early positive impact. Some of the things you'll hear will take time to fix, such as “we need a bigger team” or “our infrastructure isn’t scaling.” Those are important and it will be good for the team to hear you internalize those challenges. But a surprising number of the issues you'll hear repeatedly will be things you can easily help with, like “we waste a bunch of time in meetings every week” or “we need a dedicated conference room.” I start with the latter as quickly as I can because those are the types of things teams often neglect to prioritize, in spite of a compounding negative impact on progress.

• In the final 2 minutes: ask who else you should talk to. Write down every name they give you.

Repeat the above process for every name you're given. Don’t stop until there are no new names.

Congrats on the new job! There's a couple existing resources I recommend.

The first is the highlights of our onboarding masterclass: [Highlights] How To Succeed At A New Team Or Company As A Software Engineer

The second is around how you can build your reputation quickly as an earlier-in-career engineer, which I wrote about here: "What can I do to quickly build my reputation as a junior engineer?"

At a high-level, I think the big transition going from a small company to a large company involves the following 2 core mentality shifts:

• Realizing that you need to take code quality a lot more seriously - More scale = Worse if you mess up. The larger scale also means that there are far more edge cases lurking around - Be very diligent thinking about these upfront and catching them proactively in your commits. To make things clearer, there are code samples (they're Android though) in the above link about reputation building, which show how to make a really high-quality PR. If you want to go really deep on code quality, I recommend our 3.5+ hour course about it: [Course] Level Up Your Code Quality As A Software Engineer
• Learning to communicate - Bigger company means more stakeholders on each project, which is more people to interact with and align to ship anything. This means that large tech companies are often less forgiving of software engineers who have a more isolated, "lone wolf" style of working. To learn how you can communicate effectively, check this out: [Course] Effective Communication For Engineers

Also, I've heard that Forward Deployed Engineer is sort of a "Sales Engineer" type role where you talk to customers directly and make custom solutions. If this is the case, communication becomes a lot more important.

Best of luck! Let us know how things go as they start.

Efficient growth is definitely a thing! One effective tactic is to arrange a "date for a date" with your manager to discuss career growth. So you'd say:

Doing well here and advancing my career is really important, but in the short term I really want to focus on making an immediate impact. Could we create a growth/promo plan in 6 weeks? I'd love to discuss the job expectations with you at that point and discuss what it looks like to exceed expectations.

This way you are communicating that you are putting the team first, focusing on being valuable, but you're also saying that your career is important, and you want to have a dedicated discussion about that in the near future.

Thanks!

Love the advices here!