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

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

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

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!

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

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

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.

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

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

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

Grow From Mid-Level To Senior Engineer [Part 24] - Go Deeper: Follow Through

Start a career discussion in Taro: <https://www.jointaro.com/questions/create/>

Join Taro events: <https://www.jointaro.com/events/>

Come to Alex's Group Office Hours: <https://www.jointaro.com/p/alex-chiou/>

Related courses:

- [Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)
- [Managing Up: Build Effective Relationships With Your Boss](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/)
- [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

Bad Question vs. Good Question Example

Is the following a good question: What are the best open-source projects to work on?

"What are the best open-source projects to work on?" - How can the asker improve this question?

Is the following a good question: Any Java developers here who have worked on ML?

"Any Java developers here who have worked on ML?" - Why is this not a good question?

Is the following a good question: Does anybody know what the front-end engineering interview for Amazon looks like?

"Does anybody know what the front-end engineering interview for Amazon looks like?" - How can the asker improve this question?

Is the following a good question: Can someone recommend me resources for blockchain development?

"Can someone recommend me resources for blockchain development?" - How can the asker improve this question?

Is the following a good question: Is there anybody here who can refer me into FAANG?

"Is there anybody here who can refer me into FAANG?" - Why is this not a good question?

Asking questions is one of the most important skills for an engineer: However, so many engineers struggle with this and ask questions that are bad at getting answers. This is all even more important in the age of AI with tools like ChatGPT.

This video covers an in-depth example of a bad questions vs. a good question:

### Bad Question
*"I'm trying to load an image in my Android app, and it shows up blank. Any ideas on what's going on here?"*

Here's why this question falls short:
- It feels lazy as the asker doesn't share what they have tried already - Did they even do a Google search?
- There's no context on why they're trying to get an image to load - The impact of helping this person is unclear.
- There is 0 relevant code attached: This question forces potential helpers to ask a lot of follow-up questions to give advice.

## Good Question
The upgraded question is too long (check the video to see it), so here are the core points as to why it's better:
- The user attached everything they have tried.
- There's links to additional context if helpers reading the question want to dive deeper - Keep in mind that they're not embedded directly within the question as huge code blocks can be overwhelming.
- In general, it's very obvious that the asker put a lot of effort into the question and is respectful of everyone's time.

Related resources:
- [[Masterclass] How To Learn Quickly In Tech](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/) - The full video where this clip was taken from
- ["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/)
- [[Case Study] How Engineers Unlock Huge Impact With Artificial Intelligence (AI)](https://www.jointaro.com/lesson/gTQZbv0lmmypLPytqw5g/case-study-how-engineers-unlock-huge-impact-with-artificial-intelligence-ai/)

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

Ace Your Tech Interview As A Software Engineer [Part 29] - Don't Get Downleveled

Downleveling is something many software engineers aren't aware of when they enter the industry and immediately start idolizing FAANG. It's a brutal phenomena that absolutely needs to be accounted for during your software engineer interview job search. This lesson teaches you:

- What downleveling is and why it's so common among Big Tech companies
- How to avoid getting downleveled in the interview process, both the easy way and the hard way
- General frameworks to understand the differences between the core engineering levels of junior, mid-level, senior, and staff at Big Tech companies

To develop a much better understanding of engineering levels at top tier companies, check this out: [\[Taro Top 10\] Understanding Engineering Levels](https://www.jointaro.com/playlist/e9rjATPbSyvRPsukXiHn/)

Level Up Your Code Quality As A Software Engineer [Part 25] - Seas Of Newlines

Newlines are necessary everywhere (including this video description), but they're very much something that can get annoying fast in large quantities. This includes code. This lesson will teach you:

- The "Seas Of Newlines" messy code anti-pattern
- How to fix code that's like this and write better code instead

Level Up Your Code Quality As A Software Engineer [Part 23] - Everything In 1 Place

Monoliths and god-classes are 2 of the most common code anti-patterns, especially in Big Tech. They're extremely easy to fall into, and monolithic infrastructure is actually the right call for the vast majority of software as 99% of software is nowhere near the scale of FAANG. This lesson will teach you:

- Why the "Everything In 1 Place" anti-pattern is so damaging, not just for readability but developer productivity as well
- One of the most powerful clean code techniques: **The delegate pattern** (this is how Meta referred to it). It can go by other names, but the core concept is to understand how an interface works. Once you master this pattern, you'll be able to break up any large codebase into readable, focused, modular components. Delegates were easily the most commonly used clean code pattern back during Alex's time at Instagram. Alex goes through an in-depth example from the Taro app itself to walk you through exactly how this technique works.

If you want to learn more about Instagram's stellar engineering culture around code quality, check out this in-depth discussion: ["What do mobile testing strategies look like at top tech companies?"](https://www.jointaro.com/question/fpySzIO02aQ0sCz5N6dP/what-do-mobile-testing-strategies-look-like-at-top-tech-companies/)

The Most Common Mistake Made When Authoring Code Reviews

In this video, we focus on the **critical importance of providing context** when submitting code for review. As codebases grow in size and complexity, understanding the "why" behind a change becomes just as important as the code itself. Without clear context, reviewers are left in the dark—and teams lose valuable time and trust.

### Key Takeaways:

- **We explain the “why” behind every diff**: When submitting code, we clarify *why* the change exists, *why* we chose this approach, and *why* alternatives were rejected. This empowers reviewers to assess our choices without second-guessing or chasing us for clarification.
- **We include business, technical, and historical context**: Good diffs often explain the strategic purpose, relevant architecture, past experiments, and legacy code decisions—all of which help reviewers understand how our change fits into the larger system.
- **We reduce friction with thoughtful summaries**: A well-written diff summary is low-effort but high-impact. Taking 5–10 minutes to write it may feel like a tax, but it dramatically speeds up reviews and earns the gratitude of teammates.
- **We acknowledge that no one sees the whole system**: Using the “elephant” metaphor, we recognize that everyone sees only part of the codebase. Providing our view helps others see how our changes fit into the broader system, making collaboration more effective.
- **We write for humans, not just machines**: Code may be infinitely flexible, but humans need context to interpret it. By empathizing with reviewers and anticipating their questions, we make code review a faster, smoother, and more collaborative process.

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.