Maximize Your Productivity As A Software Engineer [Part 17] - The Demon In Your Pocket

Smart phones unlock infinite opportunity, but they also unlock infinite distraction - We've all lost countless hours towards mindlessly scrolling through the many addictive apps on our mobile devices. This lesson teaches you:

- A basic tactic to prevent you from getting distracted by your smart phone
- A more involved and technical tactic to discourage smart phone user, which Alex is a big fan of
- An extremely aggressive tactic to get your smartphone away from you, used by a Staff Engineer at LinkedIn who's also a parent!

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

Maximizing a Severance Package 9/9 - Summary

Watch Ethan's other course on Taro about [Managing Up](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/) and [The Growth And Promotion Recipe](https://www.jointaro.com/course/the-growth-and-promotion-recipe-magic-loop/)

Follow ups:

- 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 12] - System Design

System design is a topic engineers are becoming more and more familiar with, largely due to their emerging prevalence in interviews. It's also critical for the mid-level to senior promotion. This lesson teaches you:

- Why system design is the most important technical skill that mid-level engineers need to develop to grow to senior
- The ingredients of a high-quality system design document
- How to get feedback on your system design document
- Tactics to run an effective technical review meeting

Here's the system design course: [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

Master The Behavioral Interview [Part 13] - Good Vs. Bad Questions To Ask

You're a software engineer and you have slogged through the behavioral round, answering many grueling questions. And now the interviewer opens up the floor to you: "Do you have any questions for me?". What do you do here? This lesson teaches you:

- What a good behavioral interview question to ask looks like through many examples, which you can ask word-for-word in your next behavioral interview
- What a bad behavioral interview question looks like (avoid these)
- The attributes of a high-quality question vs. a low quality question in a behavioral interview

Master The DSA Interview [Part 6] - Why Does FAANG Do This?

If data structures and algorithms aren't actually used on the job, why do Big Tech companies use these problems as a cornerstone of their interview process? This lesson teaches you:

- Why Big Tech isn't just being evil and stupid when they use data structures and algorithms problems on their interviews
- How data structures and algorithms problems can have a surprising amount of depth
- What most engineers don't understand when it comes to how FAANG rejects candidates
- How Google and Meta in particular differ from almost all other companies when it comes to hiring, which affects how their interview processes work

If you're interested in working at early-stage startups that don't ask LeetCode problems: ["How to find and connect with scrappy startups?"](https://www.jointaro.com/question/9jFuRj3UymeHsaKIzXia/how-to-find-and-connect-with-scrappy-startups/)

20 Years Of Fighting Procrastination [Part 11] - Decompose Aggressively

Decomposition is one of the most reliable habits for making progress feel easy, especially when applied daily. Here are the core points from the lesson:

- Breaking down large, ambiguous tasks into small, concrete steps helps reduce mental friction and makes it easier to start taking action
- Practicing decomposition builds leadership skills and supports team collaboration, since assigning scoped work is essential for effective delegation
- Writing down one key task the night before primes your brain to subconsciously begin planning, leading to more clarity and momentum the next morning

Grow From Senior To Staff Engineer [Part 9] - Build Technical Systems

As a staff engineer, it simply isn't enough to write standard product code. You need to write code that helps other engineers write code. This lesson teaches you:

- The mindset shift that staff engineers have made with regard to technical systems that junior to senior engineers haven't
- Why technical systems work is so impactful and deserving of staff engineer scope
- Exactly what it means to demonstrate staff level behavior with technical systems instead of senior level behavior, shown with an in-depth examples
- Common technical systems within a team that staff+ engineers are responsible for building and maintaining

DSA Crash Course [Part 34] - Zipper Lists Approach

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

> Write a function, *zipper_lists*, that takes in the head of two linked lists as arguments. The function should zipper the two lists together into single linked list by alternating nodes. If one of the linked lists is longer than the other, the resulting list should terminate with the remaining nodes. The function should return the head of the zippered linked list.
>
> Do this **in-place**, by mutating the original Nodes.
>
> You may assume that both input lists are non-empty.

```
a = Node("a")
b = Node("b")
c = Node("c")
a.next = b
b.next = c
# a -> b -> c

x = Node("x")
y = Node("y")
z = Node("z")
x.next = y
y.next = z
# x -> y -> z

zipper_lists(a, x)
# a -> x -> b -> y -> c -> z
```

```
a = Node("a")
b = Node("b")
c = Node("c")
d = Node("d")
e = Node("e")
f = Node("f")
a.next = b
b.next = c
c.next = d
d.next = e
e.next = f
# a -> b -> c -> d -> e -> f

x = Node("x")
y = Node("y")
z = Node("z")
x.next = y
y.next = z
# x -> y -> z

zipper_lists(a, x)
# a -> x -> b -> y -> c -> z -> d -> e -> f
```

```
s = Node("s")
t = Node("t")
s.next = t
# s -> t

one = Node(1)
two = Node(2)
three = Node(3)
four = Node(4)
one.next = two
two.next = three
three.next = four
# 1 -> 2 -> 3 -> 4

zipper_lists(s, one)
# s -> 1 -> t -> 2 -> 3 -> 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/>

Negotiation Course: Why Negotiation Is Extremely High Leverage

Negotiation may take a few hours of time (and a bit of uncertainty/discomfort), but the result could be life-changing for you. In a place like Silicon Valley, where engineers are highly paid, successful negotiation could easily net you 5 or 6 figures of additional income.

In addition, an increase in salary will “anchor” your compensation and the benefit will compound since raises are based on this. e.g. a 5% raise is a larger dollar value compared on a $120K salary ($6K) compared to a $100K salary ($5K).

The Steve Ballmer story when he joined Microsoft is an example of one of the largest wealth increases ever due to negotiation: his net worth today is $120B (that's $120 billion!). Even though he joined Microsoft as employee #30 in 1980, he ended up negotiating 8% equity ownership of Microsoft, a deal that made him a billionaire many times over. (Read more about [Steve Ballmer's deal here](https://www.forbes.com/sites/georgeanders/2014/09/30/long-ago-twist-yielded-ballmer-a-fortune-in-microsoft-stock/?sh=16d42b7736a5).)

The famous article from Patrick McKenzie ([patio11](https://twitter.com/patio11)) about negotiation: [Salary Negotiation: Make More Money, Be More Valued](https://www.kalzumeus.com/2012/01/23/salary-negotiation/)

Ace Your Tech Interview As A Software Engineer [Part 7] - Stronger Together

The software engineer job search is extremely exhausting. We now know that grit is the most important trait for interview success, but it's hard getting there purely on your own. This lesson teaches you:

- The big difference between knowing something and applying something
- Why finding an accountability partner is crucial for learning and making genuine progress
- A very basic (but powerful) framework you can go through with your accountability partner to push one another to greater and greater heights on a consistent basis

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.

Ace Your Tech Interview As A Software Engineer [Part 38] - Go Deeper, Follow Through

You made it! By completing this course, you have attained the necessary wisdom to avoid the many, many failure modes software engineers so often fall into when searching for a job. This video teaches you:

- Why completing this course is actually just the beginning of your job search success
- The Top 5 overall learnings from this course
- The exact difference between struggling job seekers and successful ones
- How you can follow through with the knowledge gained from this course and actually apply it to your job search

Voicing Your Problems And Frustrations Productively

Which of these are important things to remember as you are voicing your problems and frustrations?

Is the following a good way to voice a problem: I really hate how John thinks about the product. His vision does not make sense, and it will drag down the team. You can tell that he does not have enough experience.

"I really hate how John thinks about the product. His vision does not make sense, and it will drag down the team. You can tell that he does not have enough experience." - What is wrong with how this frustration is presented?

Effective communication of concerns in a one-on-one, especially with a manager, hinges on emotional intelligence and thoughtful phrasing. Expressing discontent is important, but how it’s framed can determine whether it leads to meaningful change or defensiveness.

- **Words and tone matter deeply**: It’s not about suppressing feelings, but about communicating them in a way that leads to constructive outcomes. Saying “This is holding me back” is more impactful than “I hate this person/project/org.”
- **Start with your experience**: Begin by describing how a situation makes *you* feel and the impact it's having on your work. This avoids sounding accusatory and centers the conversation on outcomes.
- **Avoid blaming language**: Statements that target others personally are rarely received well. Instead, focus on issues and processes rather than individuals.
- **Propose solutions thoughtfully**: Even if unsure, suggesting possible paths forward shows initiative. Phrasing like “One thing I was thinking about…” or “Could we try…” keeps the conversation collaborative and open-ended.
- **Frame feedback to enable support**: Managers are more able to help when you present challenges clearly and offer context. Productive expression of frustration builds trust and often leads to faster resolution.

By being candid *and* constructive, you increase the likelihood of being heard, supported, and ultimately driving the change you seek.

Maximize Your Productivity As A Software Engineer [Part 14] - Do The Hardest Thing First

When you get a tough project, it's tempting to tackle the easiest parts first because you already know how to do them, putting off the most difficult portions for later (you'll totally figure it out right?). This lesson teaches you:

- The difference between bad and good engineers when it comes to taking on a project
- Why tackling the hardest parts of a project first is effective risk management and a defining behavior of the best tech leadWhen you
- The massive team-wide benefit solving the hardest problem grants you

Maximize Your Productivity As A Software Engineer [Part 10] - Organize Your Calendar

Now we know that focus blocks are one of the most powerful weapons in a software engineer's arsenal. So how can we get them? This lesson teaches you:

- How to organize your meetings in the most efficient way
- What you should look out for when it comes to clearing space on your calendar

Master The Behavioral Interview [Part 10] - When You Don’t Have An Answer

If you're an earlier-in-career software engineer, there is a very high chance that you will get a behavioral interview question where you don't have an answer. This lesson teaches you:

- How to gracefully and immediately react when you get a behavioral interview question asking for a scenario that you have never been in before
- Backup options that you can present to the interviewer to still answer the question despite not having an answer that 100% fits

Tech Lead Blueprint 11/17 - Empathetic Leadership

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

DSA Crash Course [Part 51] - Graph Intro Lecture

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

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

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)

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.