Become A Debugging Master [Part 9] - Understand The End-To-End Flow

Most engineers waste time guessing at random fixes instead of methodically understanding the flow of what’s actually happening. Here are the core points from the lesson:

- Before you fix a bug, deeply understand the end-to-end flow, the intended behavior, and where reality deviates
- Avoid “blind fixes”—randomly adding things like null checks without fully identifying the root cause leads to fragile software
- Break down the system into smaller steps, narrow down the problem area through a process of elimination, and ask better questions based on where things fail
- Understand which components are involved, how they communicate, and what data formats they expect to quickly spot mismatches or errors
- Strong debuggers act like detectives: they map out the flow precisely, isolate the problem, and only fix after gaining clarity on why things broke

Master The DSA Interview [Part 26] - Find A Buddy

When it comes to data structures and algorithms, it's best to not go it alone. This lesson teaches you:

- Why data structures and algorithms is the easiest part of the interview space to partner with someone on
- How having a data structures and algorithms buddy is greatly helpful for your personal morale
- A sample meetup agenda that you can use when you meet with your data structures and algorithms interview buddy

Find a data structures and algorithms interview buddy here: <https://www.jointaro.com/networking/?selectedServices=Mock+Interviews>

DSA Crash Course [Part 63] - Island Count Approach

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

> Write a function, *island_count*, that takes in a grid containing Ws and Ls. W represents water and L represents land. The function should return the number of islands on the grid. An island is a vertically or horizontally connected region of land.

```
grid = [
['W', 'L', 'W', 'W', 'W'],
['W', 'L', 'W', 'W', 'W'],
['W', 'W', 'W', 'L', 'W'],
['W', 'W', 'L', 'L', 'W'],
['L', 'W', 'W', 'L', 'L'],
['L', 'L', 'W', 'W', 'W'],
]

island_count(grid) # -> 3
```

```
grid = [
['L', 'W', 'W', 'L', 'W'],
['L', 'W', 'W', 'L', 'L'],
['W', 'L', 'W', 'L', 'W'],
['W', 'W', 'W', 'W', 'W'],
['W', 'W', 'L', 'L', 'L'],
]

island_count(grid) # -> 4
```

```
grid = [
['L', 'L', 'L'],
['L', 'L', 'L'],
['L', 'L', 'L'],
]

island_count(grid) # -> 1
```

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/**](https://www.linkedin.com/in/alvin-zablan-b73a92117/)

DSA Crash Course [Part 58] - Connected Components Count Walkthrough

In this lesson, Alvin walks through the python implementation for the *connected_components_count* problem.

Code along and test your work in the following editor workspace: <https://structy.net/problems/connected-components-count?language=py>

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/**](https://www.linkedin.com/in/alvin-zablan-b73a92117/)

DSA Crash Course [Part 75] - Count Paths Approach

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

> Write a function, *count_paths*, that takes in a grid as an argument. In the grid, 'X' represents walls and 'O' represents open spaces. You may only move down or to the right and cannot pass through walls. The function should return the number of ways possible to travel from the top-left corner of the grid to the bottom-right corner.

```
grid = [
["O", "O"],
["O", "O"],
]

count_paths(grid) # -> 2
```

```
grid = [
["O", "O", "X"],
["O", "O", "O"],
["O", "O", "O"],
]

count_paths(grid) # -> 5
```

```
grid = [
["O", "O", "O"],
["O", "O", "X"],
["O", "O", "O"],
]

count_paths(grid) # -> 3
```

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/**](https://www.linkedin.com/in/alvin-zablan-b73a92117/)

DSA Crash Course [Part 61] - Shortest Path Approach

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

> Write a function, *shortest_path*, that takes in a list of edges for an undirected graph and two nodes (\*node_A\*, *node_B*). The function should return the length of the shortest path between *A* and *B*. Consider the length as the number of edges in the path, not the number of nodes. If there is no path between *A* and *B*, then return -1. You can assume that *A* and *B* exist as nodes in the graph.

```
edges = [
['w', 'x'],
['x', 'y'],
['z', 'y'],
['z', 'v'],
['w', 'v']
]

shortest_path(edges, 'w', 'z') # -> 2
```

```
edges = [
['w', 'x'],
['x', 'y'],
['z', 'y'],
['z', 'v'],
['w', 'v']
]

shortest_path(edges, 'y', 'x') # -> 1
```

```
edges = [
['a', 'c'],
['a', 'b'],
['c', 'b'],
['c', 'd'],
['b', 'd'],
['e', 'd'],
['g', 'f']
]

shortest_path(edges, 'a', 'e') # -> 3
```

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/**](https://www.linkedin.com/in/alvin-zablan-b73a92117/)

Grow From Senior To Staff Engineer [Part 16] - Specialist

When you grow your junior to senior, it's best to [pick something, focus on it, and go deep](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/?playlistId=iBKHYpkjd0BRWWLKQG2j). You can actually continue this trajectory all the way to staff. This lesson teaches you:

- What the specialist staff engineer archetype is
- What it takes for a technical domain to be worthy of staff scope
- Examples of staff-level specialist domains

Tech Lead Blueprint 7/17 - Team Productivity

Connect with Lalit on LinkedIn: <https://www.linkedin.com/in/lalitkundu/>

How To Be An Effective Tech Lead [Part 9] - It's All About The Team

The best tech leads are selfless, not selfish. But what exactly does that mean? This lesson teaches you:

- The proper mindset to have as a tech **lead**
- A simple mental model to understand your overall goal as a tech leader
- How to divide up work as a tech lead
- What sort of tasks you should take on within a project as a tech lead

Become An Open Source Master [Part 16] - Understand The Basics

We need to learn the codebase of a new open source project to contribute effectively. It's important to understand the bigger picture instead of focusing on every single line of code. Some questions worth asking when approaching a new codebase are: what is the purpose of the code, what are the opinions of the developers, and how is the code structured?

Connect with James:

- GitHub: <https://github.com/jamesgpearce>
- Twitter (X): <https://twitter.com/jamespearce>

Clear Communication For SWEs [Part 5] - Structuring Your Thoughts Logically

In this video, I delve into the significance of logical structuring in communication. I discuss how organizing thoughts logically enhances clarity, persuasiveness, and aids in memory retention. Crafting a clear outline before communication and using different speaking frameworks are highlighted as key techniques. No action requested, just valuable insights shared.

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

Nail Your Promotion As A Software Engineer [Part 28] - This Might Not Be Enough

So many software engineers feel unfairly treated when it comes to their promotion, being stuck at the same level forever. And here's the thing - A lot of them are right! This lesson teaches you:

- The right mentality to have when it comes to deciding between doubling down and jumping ship
- The large career cost of switching teams, especially if you are changing companies in the process
- A framework to use when figuring out whether you should give up and change teams or continue plodding on and fighting for that promotion

Reactions After A PIP: The Ultimate Guide To Navigating A PIP

If you received a PIP, be ok with a flood of emotion. Anger, sadness, and humiliation are normal, and you should give yourself at **least half a day** simply to process. Don’t take any action erratically. 

Once you’ve had time to process, confide in a mentor or trusted friend. Online communities like Taro can help you feel less lonely. You should **not** over-share this information with your colleagues. There is a negative bias associated with a PIP, so sharing the news with people who don’t truly care about you may end up backfiring. 

Do ✅:

- Confide in a mentor or trusted friend
- Find a community (like Taro!)

Don't ❌:

- Act from a place of emotional instability
- Over-share with colleagues

A PIP is not entirely your fault, but it's also not entirely your company's fault. Do some honest reflection about what has been working and what has not.

Some recipients of a PIP are (understandably) outraged and want to take take legal action. In theory, you could sue the company, but in practice is almost never recommended. Given that employment is “at-will”, you’ll need ot clear a very high bar to show that you were unlawfully targeted to be let go or put on a PIP. In addition, to collect evidence of unfair treatment which could take dozens of hours, there’s also a high cost associated with finding legal assistance. Ou recommendation is to focus your energy on the next career move, where you can work with people that value you, rather than focusing on an unfortunate job that will soon be in your past.

DSA Crash Course [Part 56] - Undirected Path Walkthrough

In this lesson, Alvin walks through the python implementation for the *undirected_path* problem.

Code along and test your work in the following editor workspace: <https://structy.net/problems/undirected-path?language=py>

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/**](https://www.linkedin.com/in/alvin-zablan-b73a92117/)

Signs Of A Bad Engineering Manager: Reactive vs. Proactive

This segment emphasizes the importance of proactive leadership in engineering management and critiques the pitfalls of reactive behavior. It explores how great managers shield their teams from chaos, plan strategically, and take ownership rather than deflecting blame.

- **Proactive management reduces team thrash**: A strong engineering manager provides stability by creating clear plans and resisting frequent directional changes, which reduces mental fatigue and improves execution.
- **Poor planning leads to unrealistic deadlines**: Reactive managers often fail to properly estimate scope, ignore hiring timelines, and overlook time off or unforeseen absences—resulting in last-minute pressure on the team.
- **Deadline stress is often preventable**: Many deadline issues stem from a lack of foresight rather than actual resource scarcity. Better forecasting and preparation can avoid overburdening engineers.
- **Accountability is critical**: Managers who shift blame to upper leadership while ignoring their own responsibility to protect the team demonstrate weak leadership. Managers are expected to advocate for their team’s bandwidth and well-being.
- **Good managers don't just "pass down" orders**: While managers may not control strategic directives from above, they are responsible for how those directives affect their teams—and they should take action to manage that impact effectively.

Asking Great Questions [Part 15] - RFC Pull Requests

As a software engineer, you're inevitably going to have to ask a lot of questions about your code. This lesson teaches you:

- A natural tactic you can use to share code context with engineers you want to help you
- What a quality RFC pull request looks like, shown with an in-depth GitHub example
- Why pull requests are so powerful and organic when it comes to attaching technical context 

Level up your code quality here: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

Staff Engineer (L6) Describes Most Important Skill - Sammy Nguyen

Sammy is a Staff Engineer (E6) at Gusto.

- **Most important skill**: level up and unblock your team. At the Staff level, you need to have multiplicative impact on the team, which means making your teammates better.
- **Advice**: talk to people and learn about the problems. This is how you learn about the organization and land enough impact.

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:
- [The Journey to Staff Engineer In Big Tech (Panel Discussion)](https://www.jointaro.com/lesson/SaYyJGLYvrAy4XGrDhy7/the-journey-to-staff-engineer-in-big-tech-panel-discussion/)
- Taro's top 10 to get promoted from [mid-level to senior engineer](https://www.jointaro.com/playlist/AUMiBTvYUv0gcOzuu26V/)
- 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/)
- [Sammy on LinkedIn](https://www.linkedin.com/in/sam-nguyen-43519023/)

Come Up With 500k+ User Project Ideas [Part 9] - Single Player vs. Multiplayer

The most successful apps are those where users interact with other users - Facebook, Uber, and Airbnb are just a few. However, this model doesn't translate well to side projects. This lesson teaches you:

- The difference between a single-player product and a multi-player product
- Why multi-player products are both insanely hard to get off the ground and a recipe for disaster
- Why your side project really should be a single-player products
- The brutal chicken-and-egg problem multiplayer products must solve initially, shown with a concrete example from Alex's past

Grow From Junior To Mid-Level Engineer [Part 15] - Participating In Bigger Meetings

Big meetings can be daunting for engineers, especially junior ones - What if you say something dumb? This lesson teaches you:

- The difference between junior and mid-level engineers when it comes to meeting participation, explained with very simple pictures
- Tactics you can use to come up with more to say in meetings, even if you're the most junior person there
- A clever tactic you can use to participate in a meeting and add value to the discussion, even if you aren't entirely sure of what's going on

How To Be An Effective Tech Lead [Part 15] - Unite The Non-Engineers (XFN)

One of the most common traps engineers fall into is only caring about other engineers and engineering work. You cannot make this mistake as a tech lead. This lesson teaches you:

- The core non-engineering relationship you need to maintain in order to effectively lead projects
- Other examples of non-engineering (XFN, cross-functional) relationships to maintain
- Why earning trust across several organizational functions is so important for your role as a tech lead

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.