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

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

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

Quitting a PIP: The Ultimate Guide To Navigating A PIP

You got the PIP, and you made the difficult (or maybe not-so-difficult) decision to quit. You’ll soon be off to greener pastures, but there is a strategy around leaving the company that is critical to get right.

Once you've decided to leave your company, your priority should shift to optimizing your professional and financial prospects. Most companies will provide a severance package to employees who are laid off or terminated. A severance package is the *compensation that an employee receives when they leave a company*.

While companies may care (at least a tiny bit) about the well-being of their employees, generosity is **not** the primary reason that businesses provide severance. In exchange for severance, companies will require you to sign certain documents to protect the business:

- **Non-disparagement** so you agree not to speak poorly about the company in public. The company protects their business interests by maintaining relationships and reputation.
- **Invention assignment** so there is no theft of intellectual property (IP) or source code.
- **Other agreements** such as not suing the company or not poaching employees for a set amount of time.

The Human Resources (HR) team will want your agreement on these terms, which means **you have leverage**. The asks from these companies are not too onerous, which means it doesn't cost much to agree -- very few employees end up suing their former employer anyway.

### Severance checklist

Here is the "severance checklist", the most common dimensions on which you can negotiate:

- Salary

- Health insurance (COBRA payments)

- Last day of employment

- Equity vesting acceleration

- Outplacement services

Remember, **you only get what you ask for**. Since you're on your way out anyway, it's fine to get rejected when asking for more. If you express your concern and headache from the termination ("*I just moved my family here from out of state*"), companies are often willing to meet you halfway for things like:

- Your last day of employment
- Extending and paying for health insurance for several additional months
- Accelerating the next vesting date by a few weeks

Finally, we present a "goodbye checklist":

- Contact info for relevant colleagues

- How will this be communicated to the team?

- What will your employer disclose to a future employer?

- What’s the “cooldown period”?

**Relevant links**:

- [The Key Insight Behind Negotiation](https://www.jointaro.com/lesson/YliP9kVbd1zym9kmv9Gg/the-key-insight-behind-negotiation/)
- [\[Masterclass\] Understanding And Optimizing Your Pay In Tech](https://www.jointaro.com/lesson/gk408yBIV2fa5RjVR213/masterclass-understanding-and-optimizing-your-pay-in-tech/)
- [Amazon VP talks about negotiating a severance package](https://www.linkedin.com/feed/update/urn:li:activity:7161390728533741568/)

**Discussions**:

- [Does severance package get reduced in subsequent rounds of layoffs?](https://www.jointaro.com/question/FIFJWOVz2ILICZ0dOLqy/does-severance-package-get-reduced-in-subsequent-rounds-of-layoffs/)
- [Severance in companies tied to tenure?](https://www.jointaro.com/question/9nzrgmga50Dn0UEIH6Ad/severance-in-companies-tied-to-tenure/?revalidate=true)

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

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

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

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.

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

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

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!

20 Years Of Fighting Procrastination [Part 8] - Do Work When You're Working

When engineers say they’ve been “working all day,” that time often includes distractions, shallow tasks, or unnecessary overhead. To truly be productive, you have to focus on high-leverage, distraction-free work. Here are the core points from the lesson:

- Real productivity comes from deep work—uninterrupted, focused effort on cognitively demanding tasks—not from staying busy or checking email 50+ times a day
- Recognize and minimize "startup costs" like syncing code, building the app, and reviewing changes, so you can spend more time in the value-generating loop of building and debugging
- Block off long stretches of time for deep work rather than relying on scattered 30–45 minute sessions that get consumed by overhead
- Automate or script repetitive setup tasks (e.g. syncing and builds) to reduce friction and start meaningful work faster each day
- Prioritize difficult, ambiguous tasks early—they often influence downstream work, and avoiding them leads to fake progress and missed deadlines

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

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>

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)

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

Grow From Mid-Level To Senior Engineer [Part 8] - Fill In The Gaps

Senior engineers solve fundamentally different problems compared to mid-level engineers. This lesson teaches you:

- The expectation for senior engineer mindset and behavior when problems arise in a project they're working on
- The types of problems that mid-level engineers tend to avoid
- The types of problems that senior engineers uniquely solve compared to more junior engineers

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

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

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.