Figuring Out What Matters In A Codebase

In a large codebase, the code will follow the Pareto Principle (the 80/20 rule): 20% of the components account for 80% of the impact. So your goal as the engineer is to spend most of your time on the 20% of code that matters to the business and matters to your coworkers.

How do you figure out where that 20% comes from?

- Talk to people
- Use blames to find hotspots
- Look for patterns in code reviews
- Look at past alerts and what triggered them

Level Up Your Code Quality As A Software Engineer [Part 20] - Code Comment Caches

Code comments can be immensely helpful, but they can be incredibly damaging to a codebase if used incorrectly (which this course will cover even more later on down the line). This lesson will teach you:

- Why engineers will try the very weird "code comment cache" anti-pattern
- The important of Git, GitHub, and version control platforms in general
- How to not be lazy and properly deal with code that isn't necessary now but may be useful later

Principal Engineer (L8) Describes Most Important Skill - Pong Eksombatchai

Pong is a Principal Engineer at Pinterest.

- **Most important skill**: technical communication. As a Principal Engineer, you can't have sufficient impact on your own. Effective technical communication enables you to work through others and advise other teams on the recommended technical path. 
- **Advice**: model the behavior and culture you want. A Principal Engineer is, by default, a role model for the team and org, so their actions set the tone.

Here's the full playlist asking engineers what the most important skill is for their level: [Asking 7 Levels Of Engineers The Most Important Skill](https://www.jointaro.com/playlist/J9Io5lDGaYUpI8vGrUyI/)

Helpful links:
- [SWE2 --> Principal Eng in 4 years](https://www.jointaro.com/lesson/Lvf1TDKt1R4ZJSCr9BVv/rockstar-software-engineer-story-sw2-greater-principal-in-just-4-years/)
- Taro's top 10 to get promoted from [senior to staff engineer](https://www.jointaro.com/playlist/YD8LMCSlE71VUGUbNAWM/)
- [David Pan on what makes a great tech lead](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/)
- [Pong on LinkedIn](https://www.linkedin.com/in/chantat-eksombatchai-268142b8/ )

[Case Study] How to Quit Your Job The Right Way (w/ ex-Netflix TL Michael Lin)

[Michael](https://www.jointaro.com/profile/Ab2xedZA7RhROW0wo9wBHIJbAsX2/) famously [quit his $450,000 job at Netflix](https://www.jointaro.com/blog/why-i-quit-a-450k-engineering-job-at-netflix/), and asked for (and received) a severance package in the process! If you're thinking about quitting your job, consider these points **before** leaving: 

### Timing is important
- It’s better to leave on the 1st of the month than the 31st because employee benefits renew on a monthly basis.
- If you leave on the 1st, it’s like getting a full extra month of benefits. 
- But if you leave on the 31st, your benefits may end the next day.

### Quitting is a trade-off
- You’re weighing that the negatives of staying outweigh the negatives of losing out on income.
- If you have to cut vacations, move away from loved ones, and say no to social events, then those negatives may outweigh the negatives of your job.

### Act with urgency
- If your career is not going the right way, take action quickly.
- If you stay an extra two years at a job you wanted to leave and did this over five jobs in your lifetime, that’s ten years of your life spent doing work you never wanted to do.

---------
- Connect with Michael on [LinkedIn](https://www.linkedin.com/in/michael-lin-tech/)
- Subscribe to [Michael's newsletter](https://michaellin.substack.com/)

Related questions: 
- ["Should I request a voluntary layoff to my manager?"](https://www.jointaro.com/question/FnInc1bJ3AUJBz0grFyj/should-i-request-a-voluntary-layoff-to-my-manager/)
- ["Should I quit to prep for interviews?"](https://www.jointaro.com/question/Cno3oaZkvUu7BPLhHB7g/should-i-quit-to-prep-for-interviews/) from a Data Engineer

[Part 2] Software Engineer Onboarding: Learn the Workflow

To make the hard work easier, learn the workflow and process first.

**A big mistake new engineers make**: they dive in directly to a project and start landing code/landing impact. You goal is be curious about the testing and deployment procedures, along with the workflows and processes. One way to do this is to deliberately pick the simplest possible bugs and code changes to make, so you can exercise the workflow. 

- [Use Code Review Feedback For Hypergrowth](https://www.jointaro.com/lesson/aBRgdYpUfnUpoyWG4qZC/use-code-review-feedback-for-hypergrowth-meta-prodigy-engineer-story/)
- [How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/how-to-write-better-code-faster-as-a-software-engineer-11192022/)

This is part 2 of a 4 part series from Daniel about how to **most efficiently** and **most effectively** onboard into a new team or company. What should you spend your time doing in the first few months of joining, and how should that change based on your level? 

This masterclass covers this topic from the perspective of Daniel Tomko, a 20 year Big Tech veteran. Daniel spent 11 years at Microsoft and 8 years at Meta in various senior IC and management positions. 

- [Go to part 3 of the masterclass here](https://www.jointaro.com/lesson/7l4Nr4hQf8Pv8zfGZwh4/part-3-software-engineer-onboarding-understand-tactical-decisions/)
- [Go back to part 1 of the masterclass here.](https://www.jointaro.com/lesson/IYZRmwp33E3TBeFQFr9c/part-1-software-engineer-onboarding-embrace-your-lack-of-knowledge/)

System Design Series: Taro Playlists [Part 6] - Overall Approach And Tradeoffs

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're designing systems at your job!

The tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

- When it comes to determining your overall approach, it's important to understand the priorities and values of your team/company. You can't have it all when building software; when you invest more in a certain attribute, it will generally take away from others. Here are some example attributes:
  - Execution speed
  - Feature robustness
  - Code readability
  - System scalability
  - Design and aesthetic
- Taro and very early-stage startups in general will make warped decisions as the prioritization leans extremely heavily towards execution speed. The goal is to 80/20 as much as possible when it comes to all the other attributes surrounding quality.
- Since this case study is a pretty basic CRUD play building on top of an existing model, there isn't too much complexity around the approach. However, you generally want to propose 2+ concrete approaches and the tradeoffs behind them, especially at a Big Tech company where you often have many, many options.
- Here are the technical design principles covered in the video:
  - **Single source of truth**: This is a very easy way to systems to break and have inconsistent experiences. Let's say your content object has 2 fields, a boolean of "hasLikes" and then an array of users who have liked this particular piece of content. You can either check the emptiness of the array to see if the object has likes or consult the boolean. It's extra work maintaining these 2 different representations of this information, and if they fall out of sync and 2 services/surfaces each read from a different one, things will get weird.
  - **Smart server, dumb client**: You cannot scale the user's device unless you ship them a new computer or phone. However, you can theoretically infinitely scale your server-side. This is why clients (i.e. usually front-ends) should be as dumb as possible with the back-end abstracting away as much complex logic as possible. This is especially true when your product is a mobile app as there will always be users lagging on older versions of the app - You don't want to have to make a mobile update every time you have a basic product logic change. Make your back-end protocol generic, flexible, and powerful.
  - **Be additive with data model**: This is primarily relevant with mobile apps as you will have users on older builds. If you change or remove a field, older builds will break. You can't count on your users to all update to the latest version of your app immediately.

[Part 3] Meta Intern Success Series - Onboarding Efficiently

- Onboarding is arguably the most important part of your internship as it sets the foundation and tone for your entire software engineer internship.
- Set up a 30 to 45 minute meeting with your intern manager (IM) ASAP, so they can explain the codebase to you at a high-level (i.e. a component level).
- Make sure you have a recurring 1:1 meeting with your IM, which should be a weekly 30 minutes. Your IM should set this up for you, but in case they don't, you can work with them to set it up.
- You will get 2-5 onboarding tasks to work on across the first ~2 weeks. The purpose of these is to familiarize yourself with the codebase.
- Aim to put out your 1st diff by the end of Week 1. If you're doing this around the end of Week 2, you're really behind.
- Ask a ton of questions and learn to ask high-quality questions. Don't be afraid of "over-asking" questions: If you're polite while asking questions and attaching great context to them, you will be fine no matter how many questions you ask.
- Use Work Chat DMs to ask for help aggressively during this period as it's vital for you to become productive within the codebase very quickly

Related resources:
- [Asking Effective Questions That Get Great Answers Quickly](https://link.jointaro.com/E8eaKmMpZcKWNGkbA)
- ["How can I learn a large codebase fast as an intern?"](https://link.jointaro.com/L8tXjWah6ycdNpNf7)
- [There Is No Such Thing As A Stupid Question](https://link.jointaro.com/F4p3fL4eHqp5GXti7)

What To Do If Your Manager Seems Detached

This segment addresses the common experience of feeling disconnected from a manager and provides tactical advice for becoming more visible and driving engagement in that relationship. The message is rooted in realism: most managers are overwhelmed, and visibility must be earned through structured communication.

- **Managers often appear detached—not maliciously, but due to bandwidth**: With many reports and constant demands, a manager may not track every individual’s progress or struggles unless the impact is urgent or visible.
- **Visibility must be self-driven**: It's essential to lower the "activation energy" required for a manager to know what’s going on. Regular updates make it easier for them to stay engaged and supportive.
- **Weekly written updates are powerful**: Creating a consistent cadence of updates helps establish a communication rhythm. These should include:
  - *Top of mind*: What’s currently being prioritized.

  - *Priorities*: Key goals from the current or past week.

  - *Actions*: Clear tasks being worked on, by either the employee or the manager.
- **Proactive documentation helps managers help more effectively**: Preparing and sharing this structure before one-on-ones gives the manager context and allows for more productive, actionable feedback.
- **Taking initiative builds influence**: Instead of expecting a manager to chase progress or identify gaps, the individual contributor can shape the relationship by driving clarity and making collaboration easier.

1 on 1 Meetings Are An Exercise In Proactivity

Why should you err on the side of creating a 1 on 1 meeting instead of waiting for it to be absolutely necessary?

True or false: Team meetings are more important than 1 on 1 meetings, so you should create them more aggressively for everyone to stay in sync.

Being proactive about setting up one-on-one meetings helps build strong relationships and avoid costly misalignments down the line.

- **Default to setting them up**: It’s better to create a recurring one-on-one and cancel it later than to realize too late that it was needed.
- **Low time cost, high value**: One-on-ones only use two people’s time, making them much less costly than poorly-run team meetings.
- **Prevent bigger issues**: Skipping one-on-ones can lead to being misaligned with key collaborators, which may cause serious problems later in a project.
- **Sync early with core stakeholders**: Especially in cross-functional teams or shared ownership scenarios, early and regular one-on-ones help prevent misunderstandings and build trust.

20 Years Of Fighting Procrastination [Part 13] - Your Phone Is A Menace

Your phone can be both a powerful tool and a massive productivity killer—how you manage it makes all the difference. Here are the core points from the lesson:

- To prevent unconscious distractions, keep your phone physically out of reach during deep work and turn off nearly all notifications by default
- Replace passive phone checking with active forecasting—mentally plan what you’ll do next based on the outcome of a task to stay engaged
- Use batching strategies (e.g. scheduled email checks) to reduce context switching and maintain focus
- Aim to move up the PEM framework: from Pleasure (mindless scrolling) → Engagement (being immersed in your craft) → Meaning (working toward a long-term purpose)

15 SWE Years In 1.5 Hours [Part 13] - The Secret To Growing Fast

Getting better isn't about which AI tool you use or what books you read or even which company you work for. How fast you improve comes down to one fundamental skill that most people struggle with. This lesson teaches you:

- Why feedback is the fuel for rapid engineer growth
- How many engineers respond incorrectly when it comes to getting feedback
- The right mentality to have when it comes to feedback overall
- Why an incorrect piece of feedback can actually be a good thing

DSA Crash Course [Part 10] - Most Frequent Char Approach

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

> Write a function, *most_frequent_char*, that takes in a string as an argument. The function should return the most frequent character of the string. If there are ties, return the character that appears earlier in the string.
>
> You can assume that the input string is non-empty.

```
most_frequent_char('bookeeper') # -> 'e'
```

```
most_frequent_char('david') # -> 'd'
```

```
most_frequent_char('abby') # -> 'b'
```

```
most_frequent_char('mississippi') # -> 'i'
```

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

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

How to Crack System Design Interviews - Part 1: Introduction to the course

This course will help you understand system design interviews, prepare for them, and learn what to keep in mind during the process. Here's what we'll cover:

- **Understanding the Interview:** We'll review the structure of a system design interview and how it evaluates your skills, focusing on preparation, communication, and problem-solving.
- **Importance of Communication:** We'll discuss how to effectively communicate your ideas, understand requirements, and collaborate with the interviewer.
- **Technical and Problem-Solving Skills:** We'll explore how to leverage your experience and knowledge to answer questions effectively, drawing on real-world examples and theoretical understanding.
- **Preparation Strategies:** We'll cover various methods for preparing for system design interviews, including mock interviews, independent learning, and structured courses.
- **Step-by-Step Guidance:** We'll break down the interview process into manageable steps, offering clear and concise instructions to help you succeed.

Do mock interviews from one of the services on the [perks page](https://www.jointaro.com/perks/) (e.g. [Exponent](https://www.tryexponent.com/?ref=taro)) or [Taro's networking tool](https://www.jointaro.com/networking/?selectedServices=Mock+Interviews).

[Gaurav Sen](https://www.linkedin.com/in/gkcs/) has conducted 1000s of system design interviews while working at Uber and building his [YouTube channel](https://www.youtube.com/@gkcs) to 500K+ subscribers. His platform [InterviewReady](https://interviewready.io/?_aff=JOINTARO) combines video explainers, live Zoom classes, and an automated System Design Judge.

Master The DSA Interview [Part 23] - Don't Just Surrender

When preparing data structures and algorithms, you will almost certainly get frustrated at many points in the process. How you react to those moments will dictate how well you do in those interviews:

- What to do when you're stuck on a data structures and algorithms problem in prep so you can actually learn the problem and its concepts
- How to unblock yourself on a data structures and algorithms problem properly in prep, shown with an in-depth example

Master The DSA Interview [Part 22] - The #1 Tool For DSA Prep

As a mainstay of the software engineering industry for 15+ years, data structures and algorithms have more than their fair share of online resources to help you learn it. This lesson teaches you:

- The #1, time-tested resource to learn data structures and algorithms
- The trap many engineers fall into when learning data structures and algorithms when it comes to tool selection
- How to organically expand LeetCode into the rest of your learning tree
- What to do when you get a FAANG interview

If you're interested in NeetCode, you get a discount on it with your Taro Premium membership. Redeem it here by using code TARO at checkout: <https://neetcode.io/pro?utm_source=taro>

Master The DSA Interview [Part 16] - Alternate Approaches

The beautiful (and sometimes frustrating) thing about software engineering is that almost every technical problem has a ton of possible solutions. This lesson teaches you:

- Why being able to come up with alternate approaches is so important as a software engineer at the top level
- How to have a proper discussion with your interviewer about alternate approaches
- What a great alternate approach discussion looks like, discussed with an in-depth example

Dive deeper into real system design here: [\[Course\] System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

Master The DSA Interview [Part 9] - Outline Your Approach

Once you have clarified exactly what you need to deliver with a data structures and algorithms interview problem, you need to figure out how to deliver it. This lesson teaches you:

- How to come up with a data structures and algorithms solution plan
- The many benefits of coming up with a plan proactively
- What a good data structures and algorithms plan looks like, explained with an in-depth example

Grow From Junior To Mid-Level Engineer [Part 2] - At A Glance: Junior Vs. Mid-Level

What exactly does it mean to be a junior engineer vs. a mid-level engineer? What's the gap? This lesson teaches you:

- What it means at a high-level to be a junior vs. a mid-level engineer
- The difference in execution between a junior engineer and a mid-level engineer
- The types of tasks junior engineers work on vs. a mid-level engineer
- The ownership and scope difference between a junior vs. a mid-level engineer
- The difference in organizational complexity between junior engineers and mid-level engineers

Maximize Your Productivity As A Software Engineer [Part 19] - Eat The Frog

The first couple hours after you start work are absolutely crucial - Unfortunately many software engineers waste this crucial time, working on the wrong type of tasks. This lesson teaches you:

- What it means to eat the frog (don't worry, it doesn't involve any actual eating or 🐸s)
- Why eating the frog is so important
- The difference between junk food tasks and core tasks

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.