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)

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

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.

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

What is a PIP? The Ultimate Guide To Navigating A PIP

A PIP is a **Performance Improvement Plan**. A PIP covers specific areas of performance deficiencies and sets clear expectations for what needs to happen in the future to remain employed. Think about a PIP as an ultimatum, essentially telling the employee that "Something needs to change." The employee has been deemed (whether fairly or unfairly, as we’ll see) to be missing their targets.

The PIP will outline a plan to improve the employee’s performance, along with milestones to hit over 1-3 months. The manager will document instances where your performance was lacking, pulling in quotes from colleagues, individual code reviews, or emails you may have sent (or have not) sent. A PIP can feel like a personal attack: the manager will spend hours compiling an argument "against you", explaining why you're not meeting expectations.

We’ll talk about specific strategies to use if you’re on a PIP, but for now, just remember this: **You can still have an amazing career after a PIP.**

Being on a PIP is like being on an extended interview. You have all the anxiety and judgment from a high-pressure environment, but it's actually worse: instead of starting from neutral, you're starting with a negative perception. And a multi-month interview sounds terrible.

Employees on a PIP are not allowed to switch teams. The company has concerns about whether the employee can productively contribute to the company, so they want to avoid the chaos of allowing team switches. This is unfortunate because you may just have a really poor fit with your manager.

Because of the overhead involved with a PIP, generally only medium and large companies will issue them.

The Human Resources (HR) team is involved in every PIP, which is a bad sign. The main function of HR, if not the sole function, is to protect the company’s interests, not the employees’. Once HR gets involved, and the manager has started documenting gaps in the employee's performance, clearly that indicates that there’s been a loss of trust.

This course will cover 4 phases of the PIP lifecycle:

- Before the PIP (but perhaps in the danger zone)
- Receiving the PIP within the company and deciding what to do
- Case studies of Individual Contributors (ICs) who received PIPs, along with managers who have delivered PIPs
- After the PIP -- how to ensure you have a great career even if you received a PIP

Tech Lead Blueprint 11/17 - Empathetic Leadership

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

Becoming A Staff Engineer In Big Tech (Panel Discussion)

The journey to Staff Engineer is unique for everybody. Let’s talk about all the ways we got there! Senior Engineer is a terminal level at most tech companies.

Staff Engineer is the next level up. This is referred to as Staff at Meta/Google, or Principal Engineer at Amazon/Microsoft. ([Rahul's promotion story](https://www.jointaro.com/lesson/qvp2quodqAEWSkN7sayt/case-study-building-a-meta-internal-tool-to-empower-an-entire-org-staff-promotion-story/).)

Partial list of questions discussed:

- How do you know which problems are worth solving?
- How do you communicate to your manager that you want Staff promo? And what do you look for in a manager?
- What type of teams do you think best support growth into the Staff level?

Panelists:

- [**Zach Wilson** - Airbnb](https://www.linkedin.com/in/eczachly/)
- [**Rahul Pandey - Meta**](https://www.linkedin.com/in/rpandey1234/)
- [**Carly Taylor - Activision**](https://www.linkedin.com/in/carly-taylor-data/)
- [**Lee McKeeman - Google**](https://www.linkedin.com/in/lmckeeman/)
- [**Ryan Peterman - Meta**](https://www.linkedin.com/in/ryanlpeterman/)

See discussions about Staff Engineers on Taro: <https://www.jointaro.com/topic/staff-engineer/>

Watch the full [Senior to Staff course on Taro](https://www.jointaro.com/lesson/NE3J4vWP7BoWlNgbRtCw/becoming-a-staff-engineer-in-big-tech-panel-discussion/).

Negotiation Course: Misconceptions Around Negotiating

Given how taboo money + compensation is, there are unsurprisingly many misconceptions about negotiation. Here are 3 common lies you may have heard about negotiation:

**Myth #1**: *"Your offer will get rescinded if you negotiate."* Companies will never rescind your offer for simply negotiating if you do it in good faith and you're not lying about it. Once you’ve gotten to the offer stage, the company has invested many hours of time evaluating you, so it'd be irrational for them to withdraw the offer simply because you're curious about the compensation package.

**Myth #2**: *"Negotiation makes you look cheap."* In fact, quite the opposite. Negotiating effectively shows that you're a high-value candidate, and that you understand the value you're bringing to the company. 

**Myth #3**: *"Someone will get less if you get more."* This is not how tech job offers work. The technology industry (at least the VC-backed companies that employ the majority of people) is focused on rapid growth. These companies are generally more concerned about growth rather than trying to save money through small compensation adjustments.

File all this under fake news!

DSA Crash Course [Part 26] - Sum List Approach

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

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

```
a = Node(2)
b = Node(8)
c = Node(3)
d = Node(-1)
e = Node(7)
a.next = b
b.next = c
c.next = d
d.next = e

# 2 -> 8 -> 3 -> -1 -> 7
sum_list(a) # 19
```

```
x = Node(38)
y = Node(4)
x.next = y

# 38 -> 4
sum_list(x) # 42
```

```
z = Node(100)

# 100
sum_list(z) # 100
```

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

Suppress Your Instincts And Treat All Feedback As A Gift

True or false: If you get a piece of feedback, you should initially assume good intent and that it is correct.

What should be your immediate reaction when you get a piece of constructive feedback?

True or false: If you get feedback that you do not believe is 100% correct, you should just ignore it.

Which of the following are good things you can do when you get a piece of feedback that you genuinely believe is not constructive and is phrased in a harmful way?

True or false: One of the most straightforward ways to grow in tech is to just immediately incorporate every piece of feedback you get.

- **Don't be defensive at all when receiving feedback unless it is entirely incorrect.**
- If you have taken the time to find a supportive team, the vast majority of feedback you receive (95%+) will be correct and have value.
- Feedback is a gift and arguably the greatest gift you can possibly receive for your career. *One of the most common attributes among top performer engineers is that they take and apply feedback extremely well.*
- Have empathy for the feedback giver. They probably feel a bit awkward as they're unsure how you're going to receive the feedback. Make them feel comfortable after they share the feedback by thanking them immediately and earnestly.
- Write down all great feedback you receive and try to convert it into action items:
  - **Example:** "I feel like you could be more active in meetings." -> I will try to say at least 1 thing in every team meeting from now on.
- If you get feedback you genuinely believe is incorrect and hurtful:
  - Talk to your manager if you don't have a good relationship with that person.
  - If you feel comfortable enough to talk with that person directly, have a crucial conversation.

Related resources:
- ["How can I find more opportunities to grow when I'm getting very little real feedback?"](https://link.jointaro.com/TzKmgN5nLnLyXJ5G6)
- ["Everyone's telling me I'm doing great - How do I get actionable, constructive feedback?"](https://link.jointaro.com/ng6MUQy2yUfS8w4e8)
- [Effective Communication Guide - Giving Feedback](https://link.jointaro.com/VsQvnzsnJbbXUQDy6)

System Design Series: Taro Playlists [Part 8] - Breaking Down The Work And Timeline

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 are doing a system design 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:

- Something Alex forgot to mention in this video is the "POCs" section, where POC = "Point of Contact".
  - Big projects will usually have a lot of stakeholders, so having this "people map" is very helpful for any project stakeholder to know who to direct their questions to for a certain aspect of the project (which are often about the timeline/milestones).
  - This small, humble section is *especially* relevant at FAANG/Big Tech where the range of responsibility holders is almost always huge for major projects.
- Decomposing work and breaking big projects down into smaller tasks is helpful for so many reasons:
  - It allows you to estimate the project far more accurately by increasing clarity.
  - It creates "swim-lanes" for more junior engineers as they now have smaller, clearer chunks of work as opposed to this giant, hulking ambiguous cloud of a project.
  - It makes it easy to understand project as you can now break clusters of tasks into groups and attach a milestone to each group.
- Don't just decompose the work: Try to sequence it into a logical order as well. For example, if you're building a CRUD feature, you probably want to prioritize the "Create" part as that's what everything stems from.

How To REALLY Say Thank You To Coworkers

Most software engineers struggle with building relationships and professional networking overall. One of the ways to get better at this is improving an often-neglected skill: Giving thanks. This video covers one of the most powerful ways to give thanks in the workplace.

Here are the core points:
- **Reward good work through their manager** - As an authority figure, praise coming from your manager is especially meaningful and it's a great experience when it happens. Spend effort adding weight to your feedback when you tell their manager by writing a heartfelt paragraph or telling them in person (this is really easy when you share the same manager as the peer, which is often the case). Thanking the helper directly yourself first is the first step: This manager reinforcement step is what really makes them realize, *"Wow, this person **really** wants to make sure I get rewarded for my efforts."*
- **Boost your peers' performance reviews** - At a higher level, you really earn your way into coworkers' hearts when they attribute you to a boost in their own performance rating. This is especially true at top companies like FAANG which have such a high-bar for engineer performance and good ratings are connected to very meaningful raises and promotions. If someone is helping you on a recurring basis, you can even explicitly tell their manager that you really hope they get rewarded on their performance review for uplifting you and really multiplying your impact. *Fight for the credit you ardently believe they deserve.*

Related resources:
- [Effective Communication Guide - Building Relationships](https://www.jointaro.com/lesson/488EjOLzU707WhdqMOK4/effective-communication-guide-part-3-building-relationships/)
- ["How do you network effectively within a company?"](https://www.jointaro.com/question/DwT9GtdYK9nwFV3a7jrU/how-do-you-network-effectively-within-a-company/)

DSA Crash Course [Part 40] - Depth First Values Walkthrough

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

Code along and test your work in the following editor workspace: <https://structy.net/problems/depth-first-values?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/>

Ace Your Tech Interview As A Software Engineer [Part 16] - FAANG Or Bust (And Why It’s Dumb)

Software engineers have a deep obsession with "FAANG" often treating it as the Holy Grail of career goals. Unfortunately, this often leads to job searching failure. This lesson teaches you:

- How software engineers greatly underestimate the difficulty of getting into Big Tech and how they should believe and act instead
- Why FAANG companies are generally averse to hiring non-senior candidates
- The many reasons why going to Big Tech later in your career is good for you
- The path most engineers have to take in order to break into FAANG (and why that's perfectly fine!)

If you want to learn more about FAANG and Big Tech:

- [\[Taro Top 10\] Breaking Into FAANG](https://www.jointaro.com/playlist/roKqDHgxu4C5CioEFpJY/)
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://www.jointaro.com/question/KWXIrFIR1EIJsvdOdo7u/whats-the-difference-between-big-tech-and-startups-in-terms-of-learning-and-growth/)

Write A Stellar Resume As A Software Engineer [Part 9] - I Know (Suck At) Everything

When it comes tech stacks on your resume as a software engineer, less is usually more. This lesson teaches you:

- What employers are looking for when it comes to an engineer's technical skills on their resume
- Why it's dangerous to put a bunch of technical terms (i.e. keyword stuffing) on your resume
- A simple framework to determine whether or not you should put a technical term (programming language, library, domain) on your resume

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

Make Sure To Do This To Get Full Credit For Your Work

On top of doing the work, what else do you need to do in order to get full credit for what you are doing?

True or false: It is bad to give more public status updates for your project as it will come across as looking for attention.

Why should you not feel icky when you are properly broadcasting the status of your project?

Core points:
- *You don't get credit automatically for doing good work, especially if you work in a large company.*
- It is vital that you bring visibility to your work and claim credit for jobs well done in project updates, meetings, and other more public avenues.
- You may feel "icky" for sharing status updates - Don't! If your work is truly important, than it's worth sharing about and keeping the team in the loop. If you don't feel like your work is important, then you have a separate problem you need to address.
- Use project updates to thank others! Treat it as a mechanism to build social capital.

Related resources on how to write concise, impressive project updates:
- ["How can a painfully introverted person increase their visibility and promote themselves?"](https://link.jointaro.com/3XHsUifABjyN3Tq98) - From a SWE intern at Google
- ["How to get more visibility on work?"](https://link.jointaro.com/aQUHxnsNAJVcRgth6) - From a junior engineer [E3] at Meta

Become An Open Source Master [Part 7] - Improve Something You Use

The video advises that we should start by finding a project that we're passionate about, rather than aiming for the biggest or most well-known ones.

- **Choose projects that you already use or are familiar with**, as this gives you a head start in understanding the project's goals and potential areas for improvement.
- **The dependency graph on GitHub can help you identify potential projects** by showing the dependencies of projects you're already working on.
- **Consider contributing to smaller or medium-sized projects by companies**, as these can offer valuable learning experiences and opportunities to build relationships with professional developers.
- **Contributing to open source can lead to career opportunities**, as demonstrated by the example of Sophie Alpert and her work on the React project.

Article shown by Sophie Alpert: [Using React to speed up the Khan Academy question editor](https://sophiebits.com/2013/06/09/using-react-to-speed-up-khan-academy)

Connect with James:

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

Why Team Selection Is So Critical

We open by explaining that choosing the right company or team is one of the highest-leverage decisions we can make in our software engineering careers.

Here are the core points from the lesson:

- We use the “bus on a highway” analogy to show that company choice determines how far we can go; our personal effort only determines where we sit on that bus.
- Even if we perform exceptionally, joining a stagnant or declining company limits our long-term trajectory, while joining a fast-moving, hyper-growth company can accelerate our career dramatically.
- Real-world examples like Marin Software versus Google illustrate how picking the right “bus” can either stall or amplify career outcomes, independent of our individual contributions.

Ace The ML System Design Interview [Part 3] - Big Picture Design

A strong big-picture system design is crucial for success in machine learning system design interviews. It's not about drawing a perfect diagram immediately, but about demonstrating an understanding of the system's components and their interactions. Here are the core points from this lesson:

- Identify the inputs and outputs of the system during the alignment phase to establish a foundation for building the diagram
- Start with the user and the service, then progressively add components, especially those involving machine learning, to illustrate the flow of data and processes
- Break down machine learning components beyond a single "ML system" box to show the different stages and types of models involved
- Include essential infrastructure elements, such as feature stores, to demonstrate a comprehensive understanding of the system
- Iterate on the diagram, adding or modifying components as a deeper understanding of the problem and its requirements develops

If you like what Ilya has to say, subscribe to his YouTube for more high-quality ML/AI career guidance: [MLEpath - YouTube](https://go.mlepath.com/taro-youtube-mlepath)

If you want hands-on support from Ilya to crack the FAANG ML interview, join his coaching program: [MLEpath - Coaching Program](https://go.mlepath.com/taro-march-25)

Nail Your Promotion As A Software Engineer [Part 11] - Step 0: Establish Yourself

So many software engineers want to move up the career ladder as soon as possible, but they're way too hasty when it comes to seriously thinking about promotion. This lesson teaches you:

- The embarrassing failure mode to avoid with bringing up promotion
- How to know if you have established yourself as a rock-solid performer
- How long you should generally wait before asking about promotion

To dig deeper into becoming a high performer, check this out: ["What's the difference between a low performer software engineer and a high performer?"](https://www.jointaro.com/question/nMxx2EMVIlJbl1oK4SGu/whats-the-difference-between-a-low-performer-software-engineer-and-a-high-performer/)

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.