[Masterclass] Should You Work At FAANG? - What Big Tech Is Like For Software Engineers

Working at FAANG isn't all sunshine and roses, which most software engineers don't realize. This masterclass extensively covers both the pros *and* cons of working at Big Tech, with the cons being angles that are rarely talked about online.

### Pros of Big Tech
- Compensation (obviously)
- Boosts your resume 10x, often automatically getting you phone screens
- Higher-quality and more well-rounded learning from being surrounded by talent
- In general, provides a solid foundation for your career across most crucial aspects

### Cons of Big Tech
- It's stressful - Between the sky-high expectations, PIP culture, and much more, most engineers find it difficult just to survive at Big Tech. The vast majority of SWEs at these companies have poor work-life balance
- Politics - There's so many cooks in the kitchen that it can be glacially slow to get anything done
- Growth wall at senior/staff - The senior promotion is notoriously difficult at FAANG, especially at Amazon and Google. You are often competing for scope against your teammates
- Unfulfilling work - Big Tech projects are usually very incremental, and you will own a tiny piece of a tiny piece of a tiny piece, especially if you're L3/L4 (junior/mid-level).

### Is Big Tech right for you?
- It depends! Work backwards from your career goals and use the information from this presentation to make an informed decision
- Big Tech generally pays higher dividends when you're earlier-in-career
- If you're a very experienced engineer who hasn't worked for Big Tech before, it can be dangerous. Work-life balances needs generally scale up with age, and it will be harder for you to adapt to the Big Tech style

Related resources:
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://www.jointaro.com/question/KWXIrFIR1EIJsvdOdo7u/whats-the-difference-between-big-tech-and-startups-in-terms-of-learning-and-growth/)
- [How To Get FAANG Interviews](https://www.jointaro.com/lesson/pIMdopWoJFfbANnzo7U5/how-to-get-faang-interviews/)
- [[Masterclass] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)
- [Presentation Slides](https://docs.google.com/presentation/d/1T5prt4AsEUxS1Yx5BvAIO4OYNFFGD5mCyv8g9UFzrTA/edit?usp=sharing)

DSA Crash Course [Part 37] - Binary Tree Intro Lecture

In this lecture, Alvin explains the basic structure of a binary tree.

If you need additional support taking these DSA skills and actually applying them, take [**Alvin's**](https://www.linkedin.com/in/alvin-zablan-b73a92117/) *complete* data structures and algorithms course on [**Structy**](https://structy.net/?utm_source=taro). You can try out the concepts yourself in their interactive code editor and learn advanced DSA patterns like stack exhaustive recursion.

Use [**this link to get 20% off**](https://structy.net/purchase?promo_code=taro20) the entire Structy DSA learning experience.

Follow Alvin on LinkedIn: <https://www.linkedin.com/in/alvin-zablan-b73a92117/>

Part 0 [RBP] React Best Practices - Course Intro

Florian Walther, from Coding In Flow, shares the common pitfalls and best practices in React development. This course will help developers write cleaner and more robust React code by addressing frequent mistakes. The lesson also highlights additional resources available, including a YouTube channel, newsletter, and a GitHub repository with code examples.

- Florian’s free web development playlist on YouTube: <https://www.youtube.com/playlist?list=PLrnPJCHvNZuDG6BWjUFVxeWyYlve_SVJO>
- Code link: <https://github.com/codinginflow/react-best-practices/branches/stale>

Top System Design Interview Mistakes [Part 8] - Don't Make Arbitrary Decisions

This video discusses the importance of explaining technical decisions during interviews. Key points include:

- Candidates often make arbitrary choices without justification, missing opportunities for self-correction or valuable discussion
- We go through an example contrasts a poor response (choosing a database without explanation) with an improved one (considering options thoroughly)
- If a decision is worth stating, it's worth defending
- **Concluding tips:** Ask questions, document as you go, and always show your work for technical decisions

If you need extra help with your system design interview, [Formation.dev](https://formation.dev/partners/taro) can provide you hands-on, personalized support. Join us here: <https://formation.dev/partners/taro>

Clear Communication For SWEs [Part 1] - Welcome And Course Overview

Hi everybody, I'm Ryan, and in this course, we'll cover the foundations of clear communication, practical exercises, advanced techniques, and how to adapt as a software engineer. By the end, you'll be equipped to communicate effectively within your team and with other builders. Expect to understand core elements of clear communication, develop a good communicator mindset, and master practical communication structures. Tailor your messages for different audiences and apply these techniques immediately. Join me on this journey to enhance your communication skills!

Connect with me on LinkedIn: <https://www.linkedin.com/in/ryan-wiens/>

System Design Series: Taro Playlists [Part 10] - This Is Just The Beginning

Congratulations, you made it to the end of our **system design** series! If you liked this series and want to see more like it, give this video and all the others in the playlist a like!

You can find the full [system design doc here](https://docs.google.com/document/d/15WaM8Ojan82g0m2mtz6kC2Hiyj0Q6VbjfqRmVNDI3qw/edit?usp=sharing) - Feel free to use it as a template for when you are working through a **system design** at your job!

Here are the core points from the video:
- Creating the **system design** doc is just the 1st step of the process: The next step is getting aligned from the team!
- Here are the steps to get strong alignment and the technical and overall product direction on a project:
  - Time-box the exercise: Have a firm date in mind on when this alignment needs to happen and work backwards from that date.
  - Share the doc with teammates and stakeholders and push them to leave feedback asynchronously. You can directly cc important people on relevant portions for them to look through.
  - Set up a tech review meeting as a forcing function to solidify all the alignment and talk through any remaining points of content. This meeting should probably be 45 minutes or more. Book it far ahead of time as senior+ engineers, tech leads, and managers tend to have very busy schedules.
  - Remind people before the meeting to go through your system design doc beforehand and try to resolve as many threads before the meeting as possible. You might need to do this several times.
- Everything covered in this system design series is effectively a requirement to be a competent senior+ engineer and tech lead, *especially* if you work at FAANG or some other Big Tech company.
- This can all be done reactively as well. If you're working on a small, tightly-knit team with very high synergy (common in startups), raw tribal knowledge and ad-hoc collaboration may be enough to ship projects consistently well. In this case, doing all this probably doesn't make sense. However, if your last couple projects have been pretty rocky, you might want to consider adding all the processes outlined in this series.

If after all this, you're still hungry for more **system design resources**:
- [How To Ace Your Big Tech Interview [System Design]](https://link.jointaro.com/NoVGhFiEErzfh61f6) - This is a full 1.25 hour masterclass, so prepare yourself for a **ton** of knowledge!
- ["How do I get better at building large scale systems without working directly on such projects?"](https://link.jointaro.com/Dm9wE33YC7ffwAPa6) - Question from a Senior Software Engineer at LiveRamp
- ["How to improve on non-technical skills like writing software design document?"](https://link.jointaro.com/T7GCmM4Z4CZhve4y5) - Question from a Mid-Level Software  Engineer at Microsoft
- ["My team has been doing architecture debates for months and we’re in gridlock."](https://link.jointaro.com/Zzx1NRMJFHvtHcvP8) - Question from a Senior Software  Engineer at Google
- ["How can I better contribute to system design discussions on my new team?"](https://link.jointaro.com/FH7ED2533nSTJSRc6) - Question from a Senior Software Engineer at Google

Effective Communication Guide [Part 3.2] - Deep Listening

- *Communication isn't just how you share information, it's also about how you take in information.*
- It is crucial to listen intently, especially during 1 on 1s. A lot of people don't realize that there's a large skill range when it comes to listening.
- How to show that you're engaged:
  - Lean in
  - Nod to acknowledge core points
  - For something heavier, you can say "Mmhmm".
- A very powerful way to gain trust is to listen to people's problems and acknowledge them. A lot of people when they're faced with a problem, their initial goal isn't to actually solve the problem: It's just to find someone who will listen to their pain and feel less alone.
  - Just saying something along the lines of "Dang, that sucks" can go a long way.
  - Letting someone know that you have also faced this problem is also very effective. It builds solidarity and can help combat imposter syndrome as a lot of people are afraid that they are the only one facing the problem they have due to their own lack of ability.
- Revel in people's wins with them! Respond to people's excitement and positive energy with your own.

Why All Great Engineers Are Great Debuggers

A lot of engineers will run away from bugs to solely focus on feature work instead. This is a huge career mistake as it deprives you of one of the core sources of engineering growth.

This video is a clip from our debugging masterclass. You can watch it here: [[Masterclass] How To Become A Debugging Master And Fix Issues Faster](https://www.jointaro.com/lesson/ioR6WzamAIUTpySLAr7o/masterclass-how-to-become-a-debugging-master-and-fix-issues-faster/)

Related resources:
- ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://www.jointaro.com/question/QhqQQGrDgFjZbqohpKe0/how-can-i-become-more-independent-and-better-at-unblocking-myself-with-tricky-technical-issues/)
- ["What is the effective way to understand new repository in order to make the required changes in that repo?"](https://www.jointaro.com/question/KoxB3UU2zWC9pdYU6Rx0/what-is-the-effective-way-to-understand-new-repository-in-order-to-make-the-required-changes-in-that-repo/)
- [[Taro Top 10] Junior Engineer To Mid-Level Engineer (L3 To L4)](https://www.jointaro.com/playlist/iBKHYpkjd0BRWWLKQG2j/)

How Managers Hire Great Engineers [Part 1] - How This Course Works

With this lesson, you’ll begin your learning journey of how to effectively manage the recruiting process to build a strong team. [John](https://www.linkedin.com/in/jwegan/) shares personal experiences and actionable insights for hiring success. We go through the course objectives, and after this course, you will:

- Understand the importance of prioritizing recruitment and building a robust candidate pipeline
- Learn how to evaluate and troubleshoot the recruiting funnel to ensure a steady flow of qualified candidates
- Discover strategies for sourcing top talent, especially when resources are limited
- Gain techniques for closing candidates who have multiple job offers, including specific tactics and phrases

Connect with John Egan on LinkedIn: <https://www.linkedin.com/in/jwegan/>

Grow From Senior To Staff Engineer [Part 7] - Own The Goal

As a senior engineer, you are used to getting large, impactful projects and delivering them well, even if the initial project is incredibly ambiguous. However, this isn't nearly enough to get to staff. This lesson teaches you:

- The difference between senior and staff engineers between what they own on their teams and how staff engineers have a fundamentally higher altitude with their perspective
- What it means to own impact at a staff level instead of a senior, explained with an in-depth example
- The core, high-level behavior shift you need to make from an ownership perspective to grow from senior to staff

Building Software For Optimal Learning Example - Login Flow

A lot of junior engineers wonder why they have working software projects on their resume but aren't able to get a job. 99% of the time, it's because the projects they have built aren't anywhere near production quality.

This video covers an in-depth, concrete example of how you can level up a feature to be truly impressive in a portfolio:
- Bad login flow (bare minimum only):
  - Email input
  - Password input
  - Submit button which probably stores inputs on the server
- Good login flow (additional components on top of the above)
  - Ability to view the password in plaintext
  - Confirm password
  - Validate email
  - Password strength protections
  - "Forgot your password?" flow
  - Password hashing
  - Login attempt throttling

Related resources:
- [[Masterclass] How To Learn Quickly In Tech](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/) - The full video this clip was taken from
- [How The Best Software Engineers Learn - The Lego Model](https://www.jointaro.com/lesson/9cVK5zsAQstbTCc1wrWx/how-the-best-software-engineers-learn-the-lego-model/)

Ace Your Tech Interview As A Software Engineer [Part 13] - Cold Messages

You're applying to tons of software engineer jobs, and it's not working out. In your desperation, you come up with a genius idea: You'll reach out to company employees directly with a cold message. That'll work right? Guess again. This lesson teaches you:

- Why cold messaging isn't as effective as software engineers think
- How a reliance on cold messages often mask a deeper personal problem for the engineer
- The necessary conditions for a cold message to have a high likelihood of working
- Why cold messages are far more effective with startups and near useless for Big Tech
- How to write an excellent cold message, demonstrated by a thorough example of a bad cold message vs. a good cold message

The Most Dangerous Thing People Don't Realize About FAANG

So many engineers focus on just the interview when it comes to breaking into Big Tech. However, cracking the FAANG interview isn't the main thing you should worry about: *Surviving at Big Tech is what's truly hard.*

Here are the core point from the video:
- **Big Tech expectations are very high** - In exchange for world-class pay, you are expected to have world-class productivity. For most engineers coming from non-Big Tech backgrounds, they're going to have to put out more work that's also higher quality compared to what they've normally done.
- **It can be hard to adjust** - This is especially relevant if you spent a very long time (10+ years) working at companies that weren't as cutting edge as Big Tech prior to going there. It is very difficult to do things in a completely different way to what you're very used to.
- **Performance review is stressful** - Since these companies are so big and have so much process, performance reviews are incredibly thorough and take a long time. It often takes months to write and collect all the feedback necessary to compute the final rating. Couple this with fear of PIP and stack ranking and you have an environment that really puts engineers on edge.

Related resources:
- [[Masterclass] How To Navigate Your Performance Review In Tech](https://www.jointaro.com/lesson/b0B8uqIAUnBLE10jJHJG/masterclass-how-to-navigate-your-performance-review-in-tech/)
- ["What's the difference between a low performer software engineer and a high performer?"](https://www.jointaro.com/question/nMxx2EMVIlJbl1oK4SGu/whats-the-difference-between-a-low-performer-software-engineer-and-a-high-performer/)

This Is How You Get Feedback - Making The Process Smooth

The best way to improve as a software engineer is to get feedback, especially when you're new to a team or company. However, this is much easier said than done - Simply having the mentality of being open to feedback isn't enough.

Here's the core points from the video:

- **Don't just ask "Do you have any feedback for me?"** - The cognitive load for the person you're seeking feedback from is simply too high: They need to mentally comb through everything you're doing and then think through every aspect of it to find feedback to give you. Instead of doing this, they'll often default to the "lazy" response of "Nope, you're doing great!". Lazy inputs result in lazy outputs, and you definitely shouldn't be lazy when asking for feedback.
- **Reduce feedback requests to yes/no questions** - Regularly retrospect on your own and use that to craft more pointed questions when asking for feedback. Let's say you're not happy with how clean your code is, evidenced by a lot of pushback when you submit it for review. Using this, you can ask something like, *"I feel like I could do a better job polishing my code; my PRs get a lot of thrash. Do you think I can improve here?"* If they say "Yes", you can then ask for tactics you can apply to get better here.
- **Core areas for onboarding feedback**
  - Overall velocity and output
  - Code quality
  - How good your questions are

Related resources:

- [Suppress Your Instincts And Treat All Feedback As A Gift](https://www.jointaro.com/lesson/dpTu1KBbXJdnHdrQLxsG/suppress-your-instincts-and-treat-all-feedback-as-a-gift/)
- [How To Get Real Feedback So You Can Actually Improve](https://www.jointaro.com/lesson/srTbalkn0HMwEH7HoOpY/how-to-get-real-feedback-so-you-can-actually-improve/)
- ["How can I find more opportunities to grow when I'm getting very little real feedback?"](https://www.jointaro.com/question/7nrslKZuiFdYeutpeX5k/how-can-i-find-more-opportunities-to-grow-when-im-getting-very-little-real-feedback/)

3 Ways To Write Deeper, More Impactful Code Review Comments

In this video, we explore how to give more impactful code reviews by moving beyond surface-level feedback and investing in deeper understanding and learning from experienced peers. The focus is on practical habits that help us become more thoughtful, effective reviewers.

- **We rely on automation for style and formatting.** It's not our job to catch syntax or stylistic issues—those should be handled by IDEs and CI systems with pre-agreed style rules.
- **We review code with a clear perspective.** Before reading the diff, we mentally plan how *we* would solve the same problem, which helps us offer more meaningful, constructive feedback beyond just approving what “looks fine.”
- **We learn by watching the best.** One of the fastest ways to improve as reviewers is to observe how senior engineers reject code—what they flag, how they communicate, and the patterns they look for.
- **We replicate good habits.** By studying thoughtful reviewers—like those who consistently flag performance issues like mobile frame drops—we can develop our own review instincts and level up faster.
- **We treat reviewing as an intentional skill.** There are no shortcuts; it takes practice, pattern recognition, and curiosity to become great at it. But by mimicking smart peers, we shortcut years of trial and error.

How To Find A Good Team With Career Growth Opportunities

Not every team will have the scope you need to get to the next level, especially at FAANG and Big Tech. If you're looking to get to senior engineer levels and beyond, here's what to look out for in a team:
- **Past launches** - If the team has frequent, meaningful launches from the past year, it's likely this will continue.
- **Healthy balance of levels** - You want folks more senior than you to learn from and folks more junior than you for you to mentor and work through.
- **Strong engineering manager track record** - In particular, see who they have been able to get promoted. If there are examples of senior and staff engineers grown organically within the team, that's another good sign.

This clip was taken from our team selection masterclass. You can watch it here: [[Masterclass] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

Related resources:
- ["What should I look for in a new team in terms of growth?"](https://www.jointaro.com/question/i2bOMPrqaRc0NUZ7918F/what-should-i-look-for-in-a-new-team-in-terms-of-growth/) - Question from a Google L4 engineer
- ["How do I find a good team that sets me up for the mid-level -> senior level promotion?"](https://www.jointaro.com/question/oHJWlzm1qdHUZx66moaT/how-do-i-find-a-good-team-that-sets-me-up-for-the-mid-level-greater-senior-level-promotion/) - Question from an Amazon SDE 2
- ["What does it mean to not have enough scope to be promoted?"](https://www.jointaro.com/question/bJuagPwOEEy5vkcXKkqh/what-does-it-mean-to-not-have-enough-scope-to-be-promoted/)

DSA Crash Course [Part 16] - Intersection Approach

In this lesson, Alvin explores the strategy to solving the following interview problem:

> Write a function, *intersection*, that takes in two lists, *a*,\_b\_, as arguments. The function should return a new list containing elements that are in both of the two lists.
>
> You may assume that each input list does not contain duplicate elements.

```
intersection([4,2,1,6], [3,6,9,2,10]) # -> [2,6]
```

```
intersection([2,4,6], [4,2]) # -> [2,4]
```

```
intersection([4,2,1], [1,2,4,6]) # -> [1,2,4]
```

If you need additional support taking these DSA skills and actually applying them, take [**Alvin's**](https://www.linkedin.com/in/alvin-zablan-b73a92117/) *complete* data structures and algorithms course on [**Structy**](https://structy.net/?utm_source=taro). You can try out the concepts yourself in their interactive code editor and learn advanced DSA patterns like stack exhaustive recursion.

Use [**this link to get 20% off**](https://structy.net/purchase?promo_code=taro20) the entire Structy DSA learning experience.

Follow Alvin on LinkedIn: <https://www.linkedin.com/in/alvin-zablan-b73a92117/>

Grow From Senior To Staff Engineer [Part 4] - Structuring Your Growth

When going from senior to staff, you need to develop a *ton* of new skills across several difference categories. This lesson teaches you:

- A framework for organizing the improvements you need to make to grow to staff, based off of Meta's engineering performance axes
- The most important axis engineers need to grow in order to get to staff
- A healthy way to understand this course and your overall progression to staff in general

Take Jordan's course here: [\[Course\] Become The Go-To Expert As A Software Engineer](https://www.jointaro.com/course/become-the-go-to-expert-as-a-software-engineer/)

Maximizing a Severance Package 4/9 - Never Accept on the Spot

During a termination, don't sign anything on the spot. **Buy time.** Buy time to do your research, to prepare, and to come back and negotiate.

- Connect with [**Ethan on LinkedIn**](https://www.linkedin.com/in/ethanevansvp/)
- Taro members get a discount to join [**Ethan's Level Up community**](https://levelupwithethanevans.substack.com/taro25)

Grow From Mid-Level To Senior Engineer [Part 17] - Meetings

Every tech company needs a ton of meetings in order to function. The tricky thing is that a lot of software engineers are introverts, so they have trouble participating in meetings, especially when they're more junior. This lesson teaches you:

- The differences between junior, mid-level, and senior engineers when it comes to meeting presence
- The difference in types of meetings mid-level engineers participate in vs. those of senior engineers
- How meeting ownership shifts as engineers grow from mid-level to senior
- Tips to run an effective meeting which is an efficient use of time

To dive deeper into how to run a good meeting: ["What are some thoughts on maintaining good meeting hygiene?"](https://www.jointaro.com/question/CModSkZ4LWzw9bdaiakt/what-are-some-thoughts-on-maintaining-good-meeting-hygiene/)

Tech Career Growth Videos

Our instructional videos provide software engineers with insights needed for career growth. Masterclasses go incredibly in-depth on a specific tech topic while case studies are real examples from established engineering leaders.