This Is What Most Companies Get WRONG About Promotion

- 2 types of promotion:
  - **Strong companies:** Already functioning at the next level
  - **Weak companies:** Mastery of current level + long tenure
- In the best tech companies, each level is fundamentally different from the previous one. This is why promotion is lagging there: You need to be functioning at the next level consistently for 3-6 months before getting promotion.
- The goal is to avoid the Peter Principle: Getting promoted to higher and higher levels until you are completely incompetent. When levels are truly meaningful, it's really easy to be doing great at your current level and then be struggling to survive at the next one.

Ace Your Tech Interview As A Software Engineer [Part 21] - Recruiter Screen

Having a recruiter talk to you is one of the most common ways tech companies start the interview process for software engineers. Here's the thing: These recruiter screen ones can be surprisingly tricky for many software engineers. This lesson teaches you:

- When recruiter screens happen
- How difficult recruiter screens can be, how often software engineers fail them, and why many software engineers are terrible at them (when they really shouldn't be)
- What to expect in a recruiter screen so you can pass it with ease

Quick Tips To Get Higher Quality Code Reviews Faster

In this segment, we focus on how to **ramp up effectively and build trust through proactive code review habits**. By learning from past diffs, referencing previous work, and anticipating reviewer questions, we strengthen both our code and our relationships with teammates.

### Key Takeaways:

- **We study past code reviews to ramp up faster**: Reviewing recent diffs helps us identify codebase hotspots and learn how experienced teammates structure context, write test plans, and address feedback.
- **We reference prior diffs to preempt questions**: When making similar changes, we compare our approach to earlier ones (especially from tech leads) and explain why we took a different route—saving reviewers from needing to ask.
- **We proactively comment on our own code**: By flagging areas we’re unsure about and inviting feedback up front (e.g., naming choices or design alternatives), we guide reviewers toward the most relevant parts and show that we care about quality and collaboration.
- **We show respect for reviewer input**: Code review isn’t just about getting approval—it’s about listening. Ignoring thoughtful feedback undermines trust. We strive to acknowledge and incorporate suggestions to create a positive, team-first review culture.
- **We demonstrate maturity through initiative**: These habits—referencing historical context, asking for help, and valuing reviewer input—aren’t just tactical. They signal leadership and self-awareness, accelerating our growth and reputation on the team.

System Design Series: Taro Playlists [Part 9] - Thinking Into The Future

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 system design tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

- Products are rarely shipped in isolation: You will almost always iterate on them in the future, extending them and adding new features.
- You should always take some time to think into the future for your project. The amount of time you take will vary a lot based on situation, but it generally plays out like this across company types:
  - **Smaller companies and startups**: Spend less time as goal is to ship, and it's unclear if the company will survive to even iterate.
  - **Big Tech/FAANG**: Spend a lot of time as these companies need to think long-term to maintain their massive market presence.
- When coming up with future iterations during your system design, order them by likelihood of doing and level of priority.
  - Spend more time thinking through the scenarios at the upper end of the list and incorporate them into your system design if they are very likely to be done in the next couple months.
  - Your goal is avoid a scenario where you need to extend your system shortly after it's launched, but it's so brittle and fragile that you would need to rewrite huge swaths of it to accommodate the new use-cases.
- However, this is a failure mode on the opposite extreme and that is being unreasonably forward thinking and over-engineering your system as a result. Making a protocol more generic and scalable almost always takes more time.
- When building systems or services, seriously think about the assumptions you are making.
  - Will the input this API takes in always be in this format and have certain fields?
  - Will this hard-coded if-statement start blocking valid control flows in the future?

Amazing Pull Request Example - Showing The Context

In this video segment, we highlight a real-world example of a **high-quality code review** that demonstrates how providing strong context can dramatically improve the review process. This example reinforces the idea that well-documented pull requests reduce friction and foster better collaboration.

### Key Takeaways:

- **We showcase an exemplary pull request**: Submitted by a community member to the Tech Career Growth app, this PR included everything a reviewer needs—clear references, detailed explanations, and strong rationale.
- **We value clear linkage to issue tracking**: By referencing the related GitHub issue, the diff immediately communicates *why* it exists and what it’s solving—eliminating ambiguity.
- **We appreciate front-loaded context**: The PR offered an in-depth explanation of the author’s approach and alternatives considered, allowing us to understand the logic behind each code decision before even reading the code.
- **We reduce review overhead with context**: This kind of thoughtful diff saves time, prevents unnecessary back-and-forth, and lets reviewers dive straight into meaningful feedback.
- **We encourage others to learn from good examples**: We’re sharing this PR and slide deck so our community can use it as a model for writing better pull requests and improving team productivity.

**Here's why this pull request is great:**

- Has the relevant context behind why this PR exists and what it does
- Goes through the considered approaches to the problem and why the current one was chosen
- Links relevant resources that helped write the code

You can find the pull request that is shared in the video here: <https://github.com/Gear61/tcg-android-archive-and-feedback/pull/19>

How to Crack System Design Interviews - Part 7: System Design Scorecard

This video explains how candidates are evaluated and scored in system design interviews at large tech companies. We learn about the scorecard used to assess performance across five key parameters:

- **Problem Scope:** This includes listing and clarifying product requirements, discussing user interactions and expectations, and considering system scale.

- **Technical Design:** This involves making appropriate design choices, leveraging design patterns, and demonstrating knowledge of relevant technologies.

- **Scalability:** This encompasses designing a system that can handle increasing amounts of data and traffic.

- **Reliability:** This involves ensuring the system is fault-tolerant and can handle failures gracefully.

- **Communication:** This includes effectively conveying ideas, actively listening to the interviewer, and incorporating feedback.

Each parameter is scored from 0 to 5, with a total score ranging from 0 to 25. A higher score indicates a stronger candidate, and the acceptable score range varies depending on the target seniority level.

[Gaurav Sen](https://www.linkedin.com/in/gkcs/) has conducted 1000s of system design interviews while working at Uber and building his [YouTube channel](https://www.youtube.com/@gkcs) to 500K+ subscribers. His platform [InterviewReady](https://interviewready.io/?_aff=JOINTARO) combines video explainers, live Zoom classes, and an automated System Design Judge.

[Case Study] Hypercharging Your Growth At Early Startups (w/ Staff Engineer Seed Zeng)

[Click here for the presentation slides](https://docs.google.com/presentation/d/1ZocNUZJL-feWAKoucVLUcaVxix2Xa1udEL4KpgQRBTo/edit?usp=sharing).

There are a *ton* of great points covered in this session, so we'll only share our Top 5:
- **Startups have massive scope** - In an early-stage startup, there is always an infinite supply of hard, technically deep problems. This allows you to have a lot of freedom choosing an opportunity that works well for you and build up a wide breadth of important skills. This is almost always *not* the case in Big Tech - [Check out this expert career advice on the difference between Big Tech and startups when it comes to learning](https://link.jointaro.com/n57gbTWERveGTQuM9).
- **Don't say "I'm not qualified to work on this"** - The best software engineers are able to adapt to any situation their team faces and add value regardless of what framework or tech stack is needed. In order to do that, you must first flip this fearful mentality. [Here's our masterclass on how to learn quickly in tech](https://link.jointaro.com/S2h95sJvRU8Utjj6A).
- **Don't be afraid to make mistakes** - Recovering from a mistake is one of the most powerful ways to learn, and startups will generally have more tolerance for mistakes as stakes are lower compared to a more mature, massive public company where product issues can make the news. [Here's our advice on how to maximize your growth from mistakes](https://link.jointaro.com/THof1u97Z5t1ovCr9).
- **80% of the journey is just showing up** - Seek out important, complex situations and run towards them instead of away from them, especially with production issues. If you're earlier-in-career, you can learn a lot simply by being a participant in fixing these fires; from there, you can make yourself a core driver more and more. [Here's our advice on how you can be more independent debugging tricky technical problems](https://link.jointaro.com/xE8oMpCaDYjuMhCg7).
- **It's all about the people** - Your career growth is largely a product of the people you surround yourself with, and this is especially true in a startup where the team is small, bonds are deep, and everybody knows each other. [Here's our advice on how to network effectively within a company](https://link.jointaro.com/Hr1nr53D7sfQAEv3A).

To see (and hear) more from Seed:
- [Connect with him on LinkedIn](https://www.linkedin.com/in/seedzeng/)
- [Check out his podcast "Superposition"](https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkLnBvZGJlYW4uY29tL3N1cGVycG9zaXRpb25zaG93L2ZlZWQueG1s?sa=X&ved=0CAMQ4aUDahcKEwjot6up4Zf7AhUAAAAAHQAAAAAQAQ&hl=en)

Related resources:
- [Session #6 - Maximizing SWE Growth: Ownership and Specialization At Startups](https://link.jointaro.com/2ZevbN54MPZPTocH8)
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/n57gbTWERveGTQuM9)

Engineer Your Ideal Tech Career [Part 3] - What Drives You?

In this video, we explore the major areas of motivation for individuals in their career, and give you an opportunity to reflect on which resonates most with you.

Try to lean one way or the other on your worksheet vs. selecting a rating right in the middle!

We cover being driven by:

- Mission
- Technical Work
- Team

Looking for mentorship from tech’s top engineers + personalized job hunt assistance and interview prep? [Formation.dev](http://Formation.dev) can provide you unlimited career coaching, technical mentorship, personalized practice, and mock interviews. Join us here: <https://formation.dev/partners/taro>

Worksheet: [Formation - Coding Your Career](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/courses%2Fslides%2FFormation%20Career%20Direction%20Worksheet.pdf?alt=media&token=f6344b78-529a-411e-a449-7a34a8d55fc8)

Maximize Your Productivity As A Software Engineer [Part 21] - Verify Your Foundation

Work and life are deeply interconnected, despite how much we want this to not be the case. If your personal foundation isn't there, it's hard to get anything done working a mentally-intensive job like software engineer. This lesson teaches you:

- How it's possible to implement literally all the advice from this course and still not be productive
- What to do if you're stuck in a productivity rut that you just can't get out of
- The ingredients behind a healthy personal foundation

Learn more about how to have good work-life balance here: [\[Taro Top 10\] Work-Life Balance](https://www.jointaro.com/playlist/JNCZ1vbRF3NwsOQCqblt/)

DSA Crash Course [Part 87] - Outro

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

Meta Manager Case Study: The Ultimate Guide To Navigating A PIP

This was an Engineering Manager at Meta who has put 20+ employees on PIPs throughout their career.

- PIPs come from a mismatch of a “square peg, round hole”

- PIPs should never be a surprise. PIPs get discussed with the skip manager and HR

- Designed to be achievable with effort

- Across 20+ PIPs, has never had anyone continue employment

- **Advice**: “Clarity is more important than agreement”

CRUCIAL Ingredient For Senior Engineer Performance: Assembling A Feedback Team

Here are the core points from the lesson:

- Be deliberate about who you request performance review feedback from: Don't just go through your half or year without a plan here and just request feedback from those you happened to work closely with at the end.
- Work backwards from how you want to be perceived at the end of the performance review cycle. Figure out the picture of your performance you want to paint and come up with the bench of peers who can paint that picture for you. From there, strive to build deep relationships with those peers (for advice on how to do that, here's [our course on Effective Communication](https://www.jointaro.com/course/effective-communication-for-engineers/)).
- Make sure that feedback isn't duplicated: You don't want to waste your peers' time by having them write effectively the same thing about you.

Grow From Mid-Level To Senior Engineer [Part 15] - What's The Plan?

The best engineers act proactively instead of reactively, and this is critical for successful project execution. This lesson teaches you:

- The evolution in ownership of a project when it comes to a mid-level engineer vs. a senior engineer
- What a good project plan looks like

Check out the system design course for an excellent example of a master spec document: [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

20 Years Of Fighting Procrastination [Part 10] - The Simple Playbook For Sleep

Sleep is often underestimated, yet it’s one of the most powerful levers for improving productivity, health, and mental clarity. Here are the core points from the lesson:

- Sleep has greater long-term health impact than alcohol or smoking, and chronic deprivation leads to worse mood, lower energy, and reduced cognitive function
- Treating yourself as “a good sleeper” and following a consistent wind-down routine (e.g. reading, brushing teeth early, reflecting on the next day) can drastically improve sleep quality
- Physical activity, especially group-based with accountability, helps regulate sleep and creates natural productivity deadlines
- Even small efforts like 10–15 minutes of movement or consistent pre-bed rituals can create compounding benefits for both rest and output

Tech Lead Blueprint 2/17 - Course Structure

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

15 SWE Years In 1.5 Hours [Part 5] - Succeeding In School

Most software engineers start off their journey in tech by getting a university degree. However, most students don't leverage their time in school optimally. This lesson teaches you:

- The most valuable asset you get from school (hint: it's not good grades)
- Why school isn't very effective at teaching you how to do software engineering in the real world
- What you should do instead to enhance your technical skills instead of purely focusing on getting good grades

Master The Behavioral Interview [Part 9] - The Interviewer Isn’t You

One of the biggest mistakes software engineers make during behavioral interviews is not having empathy. This lesson teaches you:

- A crucial way to understand the goal of a behavioral interview
- How a lack of empathy leads to immediate tactical failure in behavioral interviews
- How you can use empathy to take in a non-confusing way

Manager 1 on 1s Are A Litmus Test For Seniority

True or false: In tech, operating at senior levels means that you are driving more, if not most, of the conversation in your manager 1 on 1s.

Why do senior employees tend to drive more of the conversation in manager 1 on 1 meetings?

One-on-one meetings evolve as career levels advance. A key sign of professional growth is taking ownership of these conversations and using them to drive impact.

- **Initiative reflects seniority**: If recent one-on-ones are led primarily by a manager with direction and feedback, it's likely an early-career dynamic. As experience grows, the expectation shifts toward independently setting priorities.
- **Ownership of agenda is critical**: A senior-level contributor brings a clear agenda to one-on-ones, proactively using the time to align on strategy, surface blockers, or present ideas—not just receive instructions.
- **Setting direction is the goal**: Defining one’s own work and outlining what to focus on next are hallmarks of operating at a senior level. The more someone guides the conversation, the more they demonstrate leadership and self-management.

A Huge Way Companies Reward You For Joining - Signing Bonus

This video explains the role of signing bonuses in tech compensation, particularly how they’re used by companies to stay competitive and how candidates should evaluate them carefully when reviewing offers.

- **Signing bonuses are one-time cash payments** intended to sweeten a job offer and help a company stand out among competing opportunities.
- **Unlike base salary and equity, signing bonuses are not banded**, meaning they can be more flexible and generous—sometimes reaching up to $175K–$200K for top-tier roles at big tech firms.
- **Because signing bonuses are tied to retention**, they’re typically prorated over time. If the full amount is paid upfront and the employee leaves early, a portion must usually be repaid.
- **Most signing bonuses are structured around a one-year commitment**, but some companies now split them over two years, spreading risk and encouraging longer retention.
- **It's important to read the fine print**, especially around repayment terms and payout schedules, since these details can affect real take-home compensation and decision-making.

DSA Crash Course [Part 41] - Breadth First Values Approach

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

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

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

#      a
#    /   \
#   b     c
#  / \     \
# d   e     f

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

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

#      a
#    /   \
#   b     c
#  / \     \
# d   e     f
#    /       \
#   g         h

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

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

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

If you need additional support taking these DSA skills and actually applying them, take [**Alvin's**](https://www.linkedin.com/in/alvin-zablan-b73a92117/) *complete* data structures and algorithms course on [**Structy**](https://structy.net/?utm_source=taro). You can try out the concepts yourself in their interactive code editor and learn advanced DSA patterns like stack exhaustive recursion.

Use [**this link to get 20% off**](https://structy.net/purchase?promo_code=taro20) the entire Structy DSA learning experience.

Follow Alvin on LinkedIn: <https://www.linkedin.com/in/alvin-zablan-b73a92117/>

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.