Become A Debugging Master [Part 7] - Understand The Blast Radius

One of the biggest mistakes software engineers make is jumping straight into fixing a bug without first understanding the full impact. Here are the core points from the lesson:

- Before fixing anything, assess and document the “blast radius” by asking when the issue started, who and where it impacts, and what product versions are affected
- Think ahead to the post-mortem by tracking detection, notification, response, and mitigation details early, even while still gathering info
- Communicate frequent updates to leadership and stakeholders—even if there’s no fix yet—to maintain trust and reduce panic

Become A Debugging Master [Part 6] - Reproduce The Issue

It's crucial to thoroughly reproduce a bug before attempting to fix it - This can be often trickier than engineers think. Here are the core points from the lesson:

- Reproducing a bug requires systematically testing different versions, languages, devices, network conditions, experiments, and user paths—not just trying once and giving up
- Bugs might appear intermittent or path-dependent, so multiple attempts and thoughtful investigation into what *wasn’t* captured in the bug report are essential
- Understand the broader categories of software failures (functional, usability, integration, concurrency, security, performance, user error) so you can better diagnose the true underlying problem
- Strong debugging starts with deeply understanding when and why the bug occurs, forming the foundation for prioritizing and fixing it effectively

Types of software bugs: <https://www.browserstack.com/guide/types-of-software-bugs>

15 SWE Years In 1.5 Hours [Part 19] - Work-Life Balance

We work to live, not live to work. Unfortunately, it can be very tricky living that reality, especially in the post-layoffs age of 2023 and onward. This lesson teaches you:

- Why your work-life balance isn't purely dictated by the company you work for
- Which factors you can adjust to facilitate work-life balance
- A healthy way to prevent yourself from sabotaging your own work-life balance

Get The Rating You Deserve [Part 1] - Course Outline

**In this course, we'll explore strategies, principles, and tactics to effectively convert the value you create into the rewards you deserve.**

- **Unleash Your Potential:** We'll address common pitfalls and biases that hinder career advancement, empowering you to overcome obstacles and achieve your goals.
- **Mindset Matters:** By shifting your mindset and adopting a positive, empowered perspective, you can accelerate your progress and achieve significant results.
- **Proven Strategies:** We'll delve into specific strategies and tactics that have been proven to be effective in maximizing your career potential.
- **Real-World Insights:** Through real-world examples and case studies, we'll illustrate how these principles can be applied to your specific career situation.

If you want to get personalized support from Yogi, you can reach out to him at [coaching@yogisharma.com](mailto:coaching@yogisharma.com) or schedule an introductory call to dive into your situation at <https://tinyurl.com/meetyogi>.

DSA Crash Course [Part 39] - Depth First Values Approach

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

> Write a function, *depth_first_values*, that takes in the root of a binary tree. The function should return a list containing all values of the tree in depth-first order.

```
a = Node('a')
b = Node('b')
c = Node('c')
d = Node('d')
e = Node('e')
f = Node('f')
a.left = b
a.right = c
b.left = d
b.right = e
c.right = f
#      a
#    /   \
#   b     c
#  / \     \
# d   e     f

depth_first_values(a)
#   -> ['a', 'b', 'd', 'e', 'c', 'f']
```

```
a = Node('a')
b = Node('b')
c = Node('c')
d = Node('d')
e = Node('e')
f = Node('f')
g = Node('g')
a.left = b
a.right = c
b.left = d
b.right = e
c.right = f
e.left = g
#      a
#    /   \
#   b     c
#  / \     \
# d   e     f
#    /
#   g

depth_first_values(a)
#   -> ['a', 'b', 'd', 'e', 'g', 'c', 'f']
```

```
a = Node('a')
#     a

depth_first_values(a)
#   -> ['a']
```

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 24] - Linked List Values Approach

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

> Write a function, *linked_list_values*, that takes in the head of a linked list as an argument. The function should return a list containing all values of the nodes in the linked list.

```
a = Node("a")
b = Node("b")
c = Node("c")
d = Node("d")
a.next = b
b.next = c
c.next = d

# a -> b -> c -> d

linked_list_values(a) # -> [ 'a', 'b', 'c', 'd' ]
```

```
x = Node("x")
y = Node("y")
x.next = y

# x -> y

linked_list_values(x) # -> [ 'x', 'y' ]
```

```
q = Node("q")

# q

linked_list_values(q) # -> [ 'q' ]
```

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 12] - Pair Sum Approach

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

> Write a function, *pair_sum*, that takes in a list and a target sum as arguments. The function should return a tuple containing a pair of indices whose elements sum to the given target. The indices returned must be unique.
>
> Be sure to return the indices, not the elements themselves.
>
> There is guaranteed to be one such pair that sums to the target.

```
pair_sum([3, 2, 5, 4, 1], 8) # -> (0, 2)
```

```
pair_sum([4, 7, 9, 2, 5, 1], 5) # -> (0, 5)
```

```
pair_sum([4, 7, 9, 2, 5, 1], 3) # -> (3, 5)
```

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

Master The DSA Interview [Part 29] - LeetCode Stockholm Syndrome

Even after passing the data structures and algorithms interview, a surprising amount of engineers maintain a toxic relationship with it. This lesson teaches you:

- What LeetCode Stockholm Syndrome looks like
- Why it doesn't make sense to continue studying data structures and algorithms after you have started the job
- The key towards true growth as a software engineer (hint: it's not LeetCode)
- A super simple way to understand data structures and algorithms studying and how it fits into your life

Master The DSA Interview [Part 21] - Programming Language Selection

There are a ton of programming languages you can use for a data structures and algorithms interview. This lesson teaches you:

- A basic flowchart to follow to determine which programming language you should use in data structures and algorithms interviews
- Why it's often not worth it to pick up an entirely new but "optimal" programming language for data structures and algorithms interviews
- How overly verbose languages can ruin your chances, explained with an in-depth example

Master The DSA Interview [Part 19] - Perfection Obsession

Getting the optimal solution to a data structures and algorithms problem is great, but it isn't always possible. This lesson teaches you:

- Why pursuing the optimal solution upfront when you're very stuck can easily lead to your rejection in a data structures and algorithms interview
- What to do instead when you're unable to get the optimal solution upfront
- How being completely stuck can lead to a vicious cycle that forces you to fail interviews
- A simple way to think about data structures and algorithms problem solving in general

Master The DSA Interview [Part 14] - Clean Code

Just because you're solving a made-up problem doesn't mean that you can write messy code during a data structures and algorithms interview. This lesson teaches you:

- What most engineers don't realize when it comes to code quality, in particular with why it's easier to achieve than they think
- The types of engineers who tend to struggle with code quality
- Common messy code patterns to avoid when coding up a data structures and algorithms solution (and in general)

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

Break Into Tech And Become A Software Engineer [Part 20] - Demystifying Resume Selection

In this lesson, Brian shares insights from his experience as an engineering manager, explaining how resumes are sorted into "no," "maybe," and "yes" piles during the hiring process.

This lesson covers:

- Why resumes with a skills mismatch or unclear roles are put into the "no" pile, and how to avoid this by clearly presenting your relevant experience and skills
- The challenge of standing out from the crowded "maybe" pile, where many passionate junior developers end up due to generic projects and experiences
- Tips for increasing your chances of landing in the "yes" pile by demonstrating experience, showcasing personality, and experimenting with different resume approaches to see what resonates with employers

If you need extra help breaking into tech, join Brian's exclusive, cohort-based bootcamp (just 10 students per batch). Use this special link for $800 off: <https://www.parsity.io/taro>

Connect with Brian on LinkedIn: <https://www.linkedin.com/in/brianjenney/>

Break Into Tech And Become A Software Engineer [Part 15] - Fostering Online Relationships

In this lesson, Brian shares his strategy for using comments and direct messages to build meaningful online connections and network effectively.

This lesson covers:

- Starting with genuine, thoughtful comments on posts to build rapport and avoid disingenuous engagement, which helps foster real conversations
- How to follow up comments by sliding into DMs, offering value first rather than asking for a favor, and creating opportunities for connection without being awkward
- The importance of short, 15-minute coffee chats to learn from others while keeping the conversation low-pressure and focused on mutual interests

If you need extra help breaking into tech, join Brian's exclusive, cohort-based bootcamp (just 10 students per batch). Use this special link for $800 off: <https://www.parsity.io/taro>

Connect with Brian on LinkedIn: <https://www.linkedin.com/in/brianjenney/>

Become An Open Source Master [Part 10] - How To Evaluate A Project’s Health

We can evaluate potential open-source projects by examining their issues and community interactions:

- **Analyze the Issues tab**: Look for a healthy ratio of solved to open issues, evidence of tagging and triage, and positive community engagement. Check for responsiveness to older issues.
- **Observe conversations around issues and pull requests:** Get a sense of the community's dynamics, code quality standards, and how welcoming they are to new contributors.
- **Check the Discussions tab (if available):** See how the community debates future changes and get a feel for the project's overall vibe.
- **Utilize the Insights tab:** Look at statistics like open and closed pull requests, active issues, and contributors to gauge the project's activity level.

Connect with James: 

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

Become An Open Source Master [Part 8] - Find Companies Active In Open Source

The video discusses where to find open source projects to contribute to.

- The GitHub Octaverse Report and websites like <https://gitstar-ranking.com/> provide lists and rankings of companies and projects active in open source.
- Many large tech companies, like Microsoft and Google, have active open source ecosystems.
- The GitHub trending pages can help you discover new and interesting projects that are gaining popularity.
- Don't limit yourself to one type of project or technology; contributing to a variety of projects will broaden your skills and experience.

Connect with James:

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

Grow From Junior To Mid-Level Engineer [Part 12] - Disambiguation

Engineers will constantly get tasks that aren't fully defined, especially if they work at a top tech company like FAANG. This lesson teaches you:

- The differences between junior and mid-level engineers when it comes to disambiguation
- How mid-level engineers are much more effective at disambiguation compared to junior engineers, explained with an in-depth example

Top System Design Interview Mistakes [Part 15] - Don't Ask For Too Much Permission

In this lessons, we address a common mistake, especially among junior engineers - Asking for too much permission. This often stems from a lack of confidence and a desire to avoid making decisions. Here are the core points:

- We often encounter candidates who, after discussing various options for solving a problem, defer decision-making to the interviewer

- Instead, we should make decisions ourselves. We can evaluate the options based on their trade-offs and choose the best one

- By taking ownership and driving the design, we demonstrate strong decision-making skills

- While it’s important to ask clarifying questions, we should avoid relying too heavily on the interviewer for directional guidance. Instead, we should proactively drive the conversation and make decisions that address the key issues.

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>

Top System Design Interview Mistakes [Part 12] - Don't Ignore New Information

In this segment, we discuss the issue of ignoring new information during system design interviews. This happens when candidates fail to adapt their designs based on additional requirements or edge cases presented by the interviewer. Here’s the core points from the video:

- If the interviewer introduces new requirements or issues, like handling scenarios with no available drivers, we must adapt our design accordingly. Ignoring these hints can lead to incomplete or impractical solutions

- Sometimes, a simpler solution might be more effective. For example, informing customers that no drivers are available and suggesting they try again later might be a better approach than complex tracking systems

- When given new information, reassess and incorporate it into the design. This flexibility is crucial for creating effective and practical solutions

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>

Top System Design Interview Mistakes [Part 10] - Don't Speak Only in Hypotheticals

In this video, we discuss a common mistake in technical interviews - Talking only in hypotheticals instead of applying knowledge to practical scenarios. Here are the key points we cover:

- Many candidates discuss system design concepts theoretically without considering real-world applications
- We provide an example contrasting a hypothetical approach with a more practical one
- The goal is to show real-world engineering skills, not just theoretical knowledge
- **Our main advice:** Avoid "it depends" answers and make assertive decisions with proper justification

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 16] - Next Steps And CTA

Thank you for watching my course on clear communication for software engineers! To enhance your communication skills, regular practice is essential, along with real-time feedback and role-playing exercises. This video also talks about my coaching services tailored to software engineers aiming to improve their communication skills, including non-native English speakers seeking confidence and effectiveness in communication. I can help you with public speaking, presentations, active listening, and everyday work communication, providing a hands-on approach in a supportive environment.

Connect with me on LinkedIn (it's also the best way to reach out to me for coaching services): <https://www.linkedin.com/in/ryan-wiens/>

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.