[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer

There are **ton** of great points in this presentation, so to prevent this summary from being a 10 page essay, we're only including our Top 5 points:
1. **Asking for help != weakness** - In fact, it's quite the opposite: Trying to figure out everything on your own and not asking questions is what makes you weak. Being comfortable with your cluelessness and putting yourself out there aggressively to get all the help you need is what makes you strong. Learn more about this dynamic here: ["How do I balance being more independent and asking questions?"](https://www.jointaro.com/question/cLsgiARaD5kVmV1BvdUi/how-do-i-balance-being-more-independent-and-asking-questions/)
2. **Get maximum value from questions** - Ask high-quality questions and ask follow-up questions to really understand the answers your teammates give you and the systems they followed to arrive at those answers. Your goal is to learn skills in a sustainable way that makes you more independent as opposed to needing hand-holding all the time. To better understand hand-holding (and how to evolve from it), check out our in-depth explainer here: ["What does it mean to not require handholding anymore?"](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/)
3. **Don't get trapped reading the code and documentation** - The only real way to learn a codebase is to just hop in, start changing code and seeing what happens. Software is all about learning via doing. Watch this video to learn more: [How To Learn A New Codebase Fast](https://www.jointaro.com/lesson/DX27hiXPJ4G7Czk2mwLL/how-to-learn-a-new-codebase-fast/)
4. **Thanking people is a skill** - When you're onboarding especially, it is crucial for you to show your gratitude effectively: Don't just do the basic, boring "Thanks for the help!" DM over Slack/Teams after you have been helped. Send the helper a heartfelt note, tell them in person, or let their manager know about their great deed. You can learn more about "deep thanks" here: [Effective Communication Guide [Part 3.1] - The Power Of Thanks](https://www.jointaro.com/lesson/noWZaoGWlrYQxX2Vhigd/effective-communication-guide-part-31-the-power-of-thanks/).
5. **Be empowered to help others, even when you're new** - Anyone can help others, even the newbie. In fact, newbies are equipped to add unique value by having a fresh pair of eyes, particularly around improving the onboarding process for others. If you're onboarding, make it one of your priorities to earn respect as that will make the entire onboarding process smoother for you.

For more premier resources on onboarding:
- [[Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta](https://www.jointaro.com/lesson/X8vpfJooDpsX915ouC00/case-study-becoming-a-tech-lead-again-in-just-1-month-after-joining-robinhood-from-meta/)
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://www.jointaro.com/question/vNE8kgpx2zdI1wACg9jA/how-do-you-overcome-the-fear-of-asking-stupid-questions-bothering-people-when-you-need-help/)
- ["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/)
- [Presentation Slides](https://docs.google.com/presentation/d/1MTs7GIklpVnYrA_JRlgcpKu1reeTLto1kYEsa6M8UqI/edit?usp=sharing)

This Is How You Become A Layoff-Proof Software Engineer

Some software engineers are better equipped against layoffs than others. They are less likely to get laid off, and if they do get laid off, they bounce back faster than everyone else. This video covers how those engineers do that.

Here are the core points:

- **Focus on building up fundamental skills** - Divorce yourself from specific technologies and product spaces. Always be thinking: *"Can I take my abilities to a completely different team/company and succeed?*"
- **Soft skills are very underrated** - Communication, leadership, and project management are skills that are useful anywhere. They are also skills that are almost always required to reach senior engineering levels, especially at Big Tech companies like FAANG.
- **Learn how to do real system design** - This is how you ascend to the higher level, away from the direct code, allowing you to add more value to engineering organizations. To learn how to do real system design (not the trivia you need to know for interviews), watch our course here: [\[Course\] System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

Related resources:

- ["What are software engineering fundamentals?"](https://www.jointaro.com/question/3VNPK7wol76s89EkgFeW/what-are-software-engineering-fundamentals/)
- ["How to develop soft skills like leadership, stakeholder management, etc.?"](https://www.jointaro.com/question/Ivo1RsizAMGoGKXmqg6N/how-to-develop-soft-skills-like-leadership-stakeholder-management-etc/)

DSA Crash Course [Part 6] - Big-O Basics Lecture

In this lecture, Alvin goes over the basics of Big-O notation and how to use it to describe the complexity of algorithms.

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/>

15 SWE Years In 1.5 Hours [Part 8] - Finding A Job

Finding a job as a software engineer sucks, especially when it comes to your first one. This lesson teaches you:

- How to differentiate yourself from the massive pool of other applicants
- Why most engineers have the wrong mentality going into interviews and how you should flip it to be much healthier
- How to structure your job search (and why you shouldn't just start off grinding LeetCode into oblivion)

To dive deeper into the full mechanics behind landing any tech job (FAANG, startups, etc), take our course here: [Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Ace Your Tech Interview As A Software Engineer [Part 4] - The #1 Trait For Interview Success

Software engineers overwhelmingly blame the wrong thing when it comes to why they aren't landing job offers, particularly their own lack of skill. This lesson teaches you:

- What the actual #1 trait among successful job searchers is
- How to build up your personal grit
- Why most software engineers have the wrong perspective post-interview and are unable to fully learn from their failures
- The success metric you should be weighing yourself against as you progress through the job search, viewing everything as more of a spectrum instead of a binary state

To go deeper into developing your grit and boosting your productivity, watch this video: [2 Ways To 100x Your Productivity That Nobody Does](https://www.jointaro.com/lesson/RXEca9zfyZG0pl015att/2-ways-to-100x-your-productivity-that-nobody-does/?playlistId=JNCZ1vbRF3NwsOQCqblt)

Asking Effective Questions That Get Great Answers Quickly

What are some things you can do to improve your question?

True or false: Ideally, your question takes less time to answer than it took for you to ask the question.

What is the core operating principle behind asking and answering questions?

True or false: In order to be polite, you should preface your question with a simple greeting like "Hello". After the potential answerer responds, then you can ask your question.

Why do you need to attach a lot of context and be as specific as possible asking questions in tech?

- **Core principle**: Questions are an exchange of time. You put some time to write your question and the answerers take some time to respond. Your goal is to make the amount of time necessary to answer your question smaller than the amount of time you spent asking it.
- Have empathy for the people answering the question. Thank them pre-emptively!
- Avoid leading "hi". Just ask them your question directly!
- Google your question and go through the initial results prior to asking your question. Inline that context in your question.
- Attach as much relevant context as possible. You want to prevent back-and-forth where answerers need to ask you questions to clarify your initial question.

Related resources:
- [Bad Question vs. Good Question Example](https://link.jointaro.com/fiY293kj2ewPwMqB8)
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://link.jointaro.com/37FJnTAX1BN2e5wt6)

15 SWE Years In 1.5 Hours [Part 2] - Learning How To Code

In order to become a software engineer, you need to learn how to code. This lesson teaches you:

- The optimal way to use tutorials
- Why tutorials can easily start *hurting* your learning progression
- The dubious value of books when it comes to learning how to code
- An incredibly effective and altruistic way to truly learn technical material

Follow the advice here to understand any new codebase fast: ["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/)

Master The Behavioral Interview [Part 3] - The 3 Keys To Behavioral Interviews

In a behavioral interview, you can say literally anything. So what should you say? This lesson teaches you:

- The 3 keys to any effective behavioral interview answer
- How to specifically show each of the 3 keys
- What a good behavioral interview answer looks like vs. a bad one (hint: the good ones integrates the 3 keys while the bad one doesn't)

To learn how Alex built 30 side projects with 5 million+ users combined: [\[Taro Top 10\] Building Impressive Side Projects](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/)

Engineer Your Ideal Tech Career [Part 11] - Michael Novati: Becoming A High-Level IC

Next, [Michael Novati](https://www.linkedin.com/in/michaelnovati) chats about his impressive career advancement and passion for high-level IC work. Michael progressed from a new grad engineer to Staff engineer at Facebook within 3 years, and then Senior Staff after.

He reflects on the key steps he took to progress quickly, common misconceptions people have about being a high-level IC, and the types of people who may love this work longer-term.

Looking for mentorship from tech’s top engineers + personalized job hunt assistance and interview prep? [Formation.dev](http://Formation.dev) can provide you unlimited career coaching, technical mentorship, personalized practice, and mock interviews. Join us here: <https://formation.dev/partners/taro>

Worksheet: [Formation - Coding Your Career](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/courses%2Fslides%2FFormation%20Career%20Direction%20Worksheet.pdf?alt=media&token=f6344b78-529a-411e-a449-7a34a8d55fc8)

Top System Design Interview Mistakes [Part 4] - Don't Introduce Tools You Don't Know

In system design interviews, it's important to avoid introducing tools you’re not familiar with, as this can lead to unnecessary challenges. This video highlights the pitfalls and best practices:

- Introducing tools you don’t fully understand can backfire, especially when follow-up questions arise
- Candidates may nervously drop buzzwords or advanced concepts to prove seniority, leading to mistakes
- We gave a demonstration of how panicking during follow-up questions can derail the interview
- Emphasizing the importance of admitting when you don’t know something, allowing the interview to move forward
- Clear communication about your knowledge level helps focus the interview on areas where you can truly showcase your expertise

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>

Introduction

Machine learning interviews are brutal—and most engineers prep for them the wrong way. This course flips that on its head. Here’s what's covered in this lesson:

- Your instructor Yayun Jin walks you through her background as an ML lead who’s been on both sides of the interview table. She goes through her journey breaking into the ML world, working across startups and big tech, and interviewing 100+ ML candidates.
- You’ll learn why most prep strategies fail: They're too scattered, too theoretical, and completely disconnected from how interviews actually work.
- We’ll walk you through the course game plan so you know exactly what to expect:
  - 🧭 Learn how to prep for ML interviews with structure instead of chaos

  - 🔍 Understand key differences between ML roles (ML engineer, infra, AI engineer) so you don’t waste time on irrelevant material

  - 🧱 See what great performance looks like in each interview type: coding, modeling, system design, and behavioral

  - 🚀 Get actionable prep tactics tailored for both current ML pros and SWE-to-ML switchers

  - 🎯 Understand how expectations shift based on seniority—so you’re not prepping like a junior when you’re going for a senior role

If you want to learn even more from Yayun:

- Book 1 on 1 career guidance with her here: <https://calendly.com/your-friend-yayun/1on1>
- Follow her on LinkedIn: <https://www.linkedin.com/in/yayunjin/>

Come Up With 500k+ User Project Ideas [Part 2] - What Makes A Project Valuable

Most engineers optimize for the wrong thing when they build personal software projects, which is 99% of engineer portfolio projects don't matter at all. This lesson teaches you:

- The only metric that matters when it comes to the quality and impressiveness of your side project
- Why getting actual users supercharges the learning and growth you get from building a side project, far more than choosing the best "modern" tech stack ever could
- Common traps engineers fall into that make their side project meaningless, especially when it comes to recruiting

2 Ways To 100x Your Productivity That Nobody Does

What are the 2 underutilized but straightforward ways of becoming far more productive?

True or false: Often times you should sacrifice sleep and exercise in order to get more hours, thereby becoming more productive.

Why is it absolutely necessary to get in good sleep and regular exercise no matter what?

- The 2 core pillars of productivity are a consistent, good night's sleep and regular exercise (3-5 times a week).
- "I don't have time for that" is not a real excuse. There are thing you *make* time for. Nobody says they stopped brushing their teeth to become more productive: That is an example of something everyone makes time for. Sleep and exercise are the same way.
- The math doesn't check out for sacrificing these. It doesn't matter if you have more hours in a day from doing this if your rate of getting things done is very low. And it will be low if you are constantly sleep deprived and not physically fit.

[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms

Data structures and algorithms (often abbreviated as "DSA") is an infamous staple of the software engineer interview experience. Data structures and algorithms problems are the most well-known for being part of the FAANG interview process, especially for Google.

Here are our Top 5 favorite points from this masterclass (in no particular order):

- **DSA prep is insanely high ROI** - In fact, the return on investment for time spent on DSA studying makes it one of the highest yield activities any human can do period. If you haven't worked at FAANG / Big Tech before, switching into it is likely to increase your pay by 50%+. If you're in the US, this will often mean a raise of $50k+. So the next time you're feeling burnt out from DSA studying, keep this very bright light at the end of the tunnel in mind.
- **Leetcode and Glassdoor are all you need** - DSA studying is a solved problem. You can use other, newer tools if you want, but the old-school ones still work just fine. Glassdoor in particular is naturally very effective given the "Big" nature of "Big Tech". Go through the recent data points from Glassdoor if you're interviewing for Big Tech and make sure you have a good grip on recurring recent problems.
- **Learning DSA is all about pattern recognition** - For 80%+ of DSA problems, there will be some 1-2 liner "trick" that represents the whole solution. For example, the "trick" to 2 sum is "Look for the difference and use a set/dictionary". It is not scalable to memorize solutions as code - Look for patterns and remember solutions as that high-level insight.
- **Communicate, communicate, communicate** - Since FAANG companies are so huge, there are naturally going to be far more stakeholders on every project, making alignment far more important. Because of this, Big Tech companies will often closely judge your communication skills during the interview. Don't just code in silence - Even if you get the right answer, you may still fail for not maintaining a dialogue with your interviewer.
- **Don't forget about space** - Most people are aware of big O run-time complexity, but candidates often forget about space complexity. Make sure to talk about both when you analyze your solution. As a side note, remember that a recursive solution will *not* be O(1) space.

Related resources:

- [\[Course\] Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)
- [How Alex Got Into Meta With 0 Prior LeetCode Experience](https://www.jointaro.com/lesson/ZYiTbN21FsqFxFdpwt5a/how-alex-got-into-meta-with-0-prior-leetcode-experience/)
- ["How do I balance my time between studying DSA and fleshing out my portfolio?"](https://www.jointaro.com/question/fhV2SCn56aYF4gfPVLmV/how-do-i-balance-my-time-between-studying-dsa-and-fleshing-out-my-portfolio/)
- ["Should I quit to prep for interviews?"](https://www.jointaro.com/question/Cno3oaZkvUu7BPLhHB7g/should-i-quit-to-prep-for-interviews/)
- [Presentation Slides](https://docs.google.com/presentation/d/13uLUHDvZifjp2aVClGsW29nfuVpQYvrkGLP8cej0R_k/edit#slide=id.p)

Come Up With 500k+ User Project Ideas [Part 3] - The Key To A Great Project Idea

Most engineer resume projects are half-baked school projects or wrappers around basic tutorials, lacking the necessary continuity to be impressive and get users. This lesson teaches you:

- The #1 cause of death with engineer side projects
- The key that every good side project idea needs to even have a chance of being successful
- What it means for a side project idea to satisfy that key, explained with a concrete example showing the inspiration behind Alex's Random Name Picker app, which has over 1.1 million users

The Path To Career Success

Before diving into the pros and cons of Big Tech, we introduce two foundational career frameworks that offer different approaches to growth. These models help structure decision-making as one considers roles at large tech companies.

- **Explore vs. Exploit (David Epstein’s “Range”)**: In the early career stages, it’s valuable to gather a wide range of experiences—trying different roles or disciplines—to discover personal strengths and interests. This sampling period can lead to deeper, more informed commitments later.
- **Cultivate Passion through Skill (Cal Newport’s “So Good They Can’t Ignore You”)**: Rather than waiting to find a passion, pick a field and become excellent at it. Passion often emerges through mastery and impact in a chosen domain.
- Both frameworks offer valid paths and should be selected based on personal goals and life stage. The talk later connects these frameworks to the realities of working in Big Tech.

DSA Crash Course [Part 8] - Anagrams Approach

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

> Write a function, *anagrams*, that takes in two strings as arguments. The function should return a boolean indicating whether or not the strings are anagrams. Anagrams are strings that contain the same characters, but in any order.

```
anagrams('restful', 'fluster') # -> True
```

```
anagrams('cats', 'tocs') # -> False
```

```
anagrams('monkeyswrite', 'newyorktimes') # -> True
```

```
anagrams('paper', 'reapa') # -> False
```

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/>

[Case Study] Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta

For the key points, you can find them in the slides (linked below), so the summary will be framed more as action items.

**If You're Pushing For Senior/Are Senior+ Already**

- Mentorship is a core part of healthy senior engineer behavior, so invest in it if you aren't already.
- Now you need to find good mentees. *The main thing to look for is their coachability, which largely depends on how smoothly they process feedback*.
- How can you tell if someone is coachable?
  - They go the extra mile making sure their code is clean.
  - They respond to code review comments (particularly yours) with enthusiasm and speed. They're hungry to learn more and go deeper into feedback on their code.
  - They go out of their way to help others as opposed to many people who just help reactively (or not at all).
  - They have a good cadence with you when you spend time with them (e.g. it's easy to have a fun conversation with them over lunch).

**If You're Mentoring Other Engineers**

- *If the extent of your mentorship is that you answer a lot of your mentee's question, you're not truly a mentor.*
  - True mentorship is being proactive and having a clear vision for what your mentee will become. Create a growth plan for them to get to the next level and outline deltas to make it clear.
- If you haven't already make sure that your manager and the manager of your mentee (if they're on a separate team) are aware of your involvement. This is vital for getting proper credit and not growing them incorrectly.
- Your mentality should be that you serve your mentee, not the other way around.
- To build a ton of trust quickly, tell your mentee this: *"No matter what happens, I'll do whatever extra work is necessary to make sure that you're okay."* You are majorly responsible for your mentee's well-being.
- Always call out when your mentee does good work, even if it's something small like a well-written commit. Do it in your 1:1 where it has more gravity. Showing appreciation as a trust/morale building technique is *severely* underutilized.

**If You're A Mentee Looking For A Mentor**

- Show strong gratitude for code review comments on your commits. Don't just give them a thumbs up or worse, silently make the change. For deeper feedback (often times coming from senior engineers who you want to mentor you), go the extra mile giving thanks.
- Put yourself out there: Don't be a hermit. Go to team lunch, offsites, coworking - Become known as a friendly face within your team. Strike up conversations with engineers more senior than you just to get to know them.
- Strive to write good code. It can scary as a junior engineer in particular and default to churning out tickets as fast as possible with bare minimum quality; avoid that instinct and try to spend an extra 30 minutes to 1 hour trying to build things out properly (and then talk about your thought process on your pull requests). You want to show senior+ engineers that your hunger to be an actually good software engineer instead of a commodity coder is there.

Related Resources:

- [Presentation Slides](https://docs.google.com/presentation/d/12OelIHF08oBZwe-TzVlz8fqp4WiOTem_e9KsGe7X8XA/edit?usp=sharing)
- [Meta E4 To E5 Growth Plan (Pretty Applicable To Any Large Company)](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/articles%2Fmeta_e4_to_e5_growth_plan.pdf?alt=media&token=e13d88fd-9356-4c20-a229-cf0cad78a9af)
- ["How do you get the most out of mentorship?"](https://www.jointaro.com/question/IbuZydz0QzsVVqESVaxQ/how-do-you-get-the-most-out-of-mentorship/)

Level Up Your Code Quality As A Software Engineer [Part 4] - What ACTUALLY Makes Code Good

Code quality is one of the most misunderstood topics in software engineering due to a combination of engineering laziness and misinformation. This video will teach you:

- What ACTUALLY makes code good and high-quality and why we're even software engineers to begin with
- How to have proper empathy for the end-user
- The common mistakes software engineers make when determining how good code is, including a very common misconception about how FAANG works
- The true value of clean code patterns and how they add value to the end-user instead of just being buzzwords (that can potentially make the code worse when used incorrectly)
- The #1 guiding principal when it comes to writing truly high-quality code

What The Optimal Discussion On Code Review Looks Like

In this video, we explore the **spectrum of code review discussions**, highlighting what kinds of conversations are appropriate—and which are not—for an effective and healthy code review process. We emphasize that great code reviews live in the middle: technical, constructive, and context-rich.

### Key Takeaways:

- **We avoid extremes on the code review spectrum**: Debates about architecture or product behavior should happen *before* the code is written. On the other end, trivial nitpicks like formatting should be automated with linters—not left to human reviewers.
- **We aim for meaningful middle-ground discussions**: The best code reviews focus on topics like naming clarity, input assumptions, and logic validation—things that improve understanding and code quality without being overly granular.
- **We talk about testing and future-proofing**: We use code review to validate testing strategies and anticipate how upcoming features or changes might interact with the current code—enabling forward-thinking design.
- **We reduce unnecessary friction with agreed standards**: By aligning on style conventions and automating formatting checks, we free up our code reviews to focus on higher-order thinking and shared learning.
- **We use code review to transfer experience and context**: A reviewer’s knowledge of future plans or broader system behavior adds lasting value. These discussions aren’t just about code—they’re how we build team wisdom.

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.