The Framework Through Which To Evaluate Engineering Productivity

When you reflect on your day or week, two spectrums through which to evaluate how your time was spent: 

1. How much of your time was spent **reactively vs proactively**?
2. How much of your time was spent **consuming vs creating**? 

The most productive engineers (and the most senior engineers) are very proactive, and they also lean heavily on the creating end of the spectrum. That means you should spend less time passively attending meetings, and more time breaking down projects, writing code, and setting direction for your team.

It’s much harder to create content compared to consuming content. But the majority of impact as an individual or business comes from creation. As a result, the world rewards the people who are able to create high quality video/code/writing over a long period of time.

- [Reactive vs proactive as a manager](https://www.jointaro.com/lesson/VCSrWjEBu3WCaSWCn2ak/signs-of-a-bad-engineering-manager-reactive-vs-proactive/)
- [A hack to supercharge your learning when you create - the Lego Model](https://www.jointaro.com/lesson/9cVK5zsAQstbTCc1wrWx/how-the-best-software-engineers-learn-the-lego-model/)

Connect with Steve: 
- [Taro](https://www.jointaro.com/profile/aZJL3ucq9dQnscO09F4JDRkgPo72/)
- [YouTube](https://www.youtube.com/@ALifeEngineered)

Break Into Tech And Become A Software Engineer [Part 7] - The 6 Steps For A Great Side Project

In this lesson, Brian walks through six key steps for creating a meaningful and impactful side project that builds skills, credibility, and even potential business opportunities.

Brian's ["Side Project Template" Google Doc](https://docs.google.com/document/d/1H508NN2HCnnKmkRMgCg3pj_mXr3i8x3Np0jS6w4xzCs/edit#heading=h.cueymdkrqyb1).

This lesson covers:

- Starting with data or APIs to ensure your project is feasible and solves a real problem you care about
- Choosing the right front-end and back-end stack that balances familiar and new technologies while focusing on full-stack development
- Structuring your project with clear user flows, a deployment strategy, and involving real users for feedback, making your project more impressive and valuable in interviews

If you need extra help breaking into tech, join Brian's exclusive, cohort-based bootcamp (just 10 students per batch). Use this special link for $800 off: <https://www.parsity.io/taro>

Connect with Brian on LinkedIn: <https://www.linkedin.com/in/brianjenney/>

Become An Open Source Master [Part 11] - Go With The Flow

We can contribute to open source projects by either creating something new or picking up existing work. It's important to communicate with the community owner or maintainer and earn their trust. We can do this by opening discussions, being open to feedback, and starting with small, well-defined tasks.

Example strong pull request (PR) from TinyBase: <https://github.com/tinyplex/tinybase/issues/130>

Connect with James:

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

[Become A Go-To Person 3/18] Jordan's Story (Imposter Syndrome)

Dealing with imposter syndrome and getting to the senior level.

A course by [Jordan Cutler](https://www.linkedin.com/in/jordancutler1/), Senior Software Engineer at Pinterest and Author of the [High Growth Engineer Newsletter](https://read.highgrowthengineer.com/)

Part 1 [RBP] Exploring Modern React Frameworks + Setup

This lesson covers setting up a new React project using best practices. It discusses choosing the right framework, emphasizing the benefits of Next.js for its full-stack capabilities and features like routing and image optimization. The lesson also touches on the importance of TypeScript and ESLint for code quality and maintainability, and introduces the App Router as the modern approach to structuring Next.js applications.

- Florian’s free web development playlist on YouTube: <https://www.youtube.com/playlist?list=PLrnPJCHvNZuDG6BWjUFVxeWyYlve_SVJO>
- Code link: <https://github.com/codinginflow/react-best-practices/branches/stale>

Nail Your Promotion As A Software Engineer [Part 18] - Organizational Complexity

In order to get promoted to senior engineering levels and beyond, you can't just be good with code, you need to be good with people too. This lesson teaches you:

- A basic, straightforward framework to understand what the organizational complexity of your project is
- How to calculate the quantity of your organizational complexity
- How to calculate the quality of your organizational complexityIn rode

Entry-Level Engineer (L3) Describes Most Important Skill - Uriel Sejas

Uriel is a new grad engineer at Slack.

- Most important skill: understand and follow patterns in the codebase. There's likely a well-defined template or approach you can follow to complete your work. 
- Advice: take time to connect with other engineers. An engineer on a different team (build system or UI framework) can share something that otherwise would have taken hours/days to figure out.

Here's the full playlist asking engineers what the most important skill is for their level: [Asking 7 Levels Of Engineers The Most Important Skill](https://www.jointaro.com/playlist/J9Io5lDGaYUpI8vGrUyI/)

Helpful links:
- [[Masterclass] How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/masterclass-how-to-write-better-code-faster-as-a-software-engineer/)
- [How Neetcode Got Promoted From L3 to L4 (Mid-Level) Engineer At Google - Tips + Insights](https://www.jointaro.com/lesson/mP1jyI09NsCHDsi5yTEX/how-neetcode-got-promoted-from-l3-to-l4-mid-level-engineer-at-google-tips-insights/)
- Taro's top 10 to get promoted from [entry-level to mid-level engineer](https://www.jointaro.com/playlist/iBKHYpkjd0BRWWLKQG2j/)
- Taro's top 10 to get promoted from [mid-level to senior engineer](https://www.jointaro.com/playlist/AUMiBTvYUv0gcOzuu26V/)
- [Uriel on LinkedIn](https://www.linkedin.com/in/uriel-sejas/)

Code Review MUST Be Fast, Otherwise The Team Is Unhealthy

In this final segment of the video, the speakers reflect on the crucial role that **code review turnaround time** plays in engineering culture, team productivity, and developer happiness. Timely reviews are not just a technical necessity—they reflect the team’s values and operational discipline.

- **We treat code review turnaround time seriously.** Our standard should be to review diffs within *one day*, two at most. Slow feedback cycles—especially taking 4–5 days—compound and slow down overall delivery velocity.
- **We recognize code review as a gatekeeper with real power.** Since all production code must pass through this step, bottlenecks here can deeply affect morale, productivity, and team trust.
- **We advocate for clear team expectations.** When reviews consistently lag, we push for a shared SLA (Service Level Agreement) around review times, ensuring accountability and smoother planning.
- **We balance urgency with respect.** While prompt reviews are key, we also avoid pestering reviewers within minutes of submitting. Giving at least 6 hours (unless it’s urgent) is a sign of maturity and respect.
- **We proactively build good habits.** Many of us block time at the end of our day to batch and respond to review requests, which helps us maintain velocity without excessive context-switching.

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>

Master The DSA Interview [Part 14] - Clean Code

Just because you're solving a made-up problem doesn't mean that you can write messy code during a data structures and algorithms interview. This lesson teaches you:

- What most engineers don't realize when it comes to code quality, in particular with why it's easier to achieve than they think
- The types of engineers who tend to struggle with code quality
- Common messy code patterns to avoid when coding up a data structures and algorithms solution (and in general)

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

This Is What A Good Promotion Plan Looks Like

One of the most crucial ingredients for a successful promotion is a clear plan. However, the engineering career matrix that most big companies have isn't nearly enough. This video covers what a quality promotion plan looks like.

Here are the core points from the video:

- **Show the delta** - Just giving someone a concept isn't enough. Growth comes when you progress from a lower state to a higher one. To best facilitate that, you must outline exactly what that lower state and higher state are so people can understand the difference and work towards bridging the gap.
- Here's an example showing what it means to outline the delta when growing a mid-level engineer on their code review axis:
  - **Bad promotion plan:** *"Have a bigger influence in code review"*
  - **Good promotion plan:**
    - E4 (mid-level): *"You are extremely thorough catching issues within your own domain, finding architectural issues (sometimes challenging the entire diff/diff stack), performance problems, and several edge case misses."*
    - E5 (senior): *"Instead of mainly reviewing stack-specific diffs within product domains you have worked on, you review diffs across the entire stack for your org (M2+ scope). You are able to review diffs for areas that you have never worked with before, quickly absorbing the context of the diff and its surrounding ecosystem to leave genuinely insightful feedback in a relatively short period of time.”*

Related resources:

- [\[Taro Top 10\] Software Engineer To Engineering Manager (IC -&gt; M Track)](https://www.jointaro.com/playlist/oz0mnJvHHgM8NfVF7rgp/)
- [\[Masterclass\] What Software Engineers Should Look For In Their Engineering Manager](https://www.jointaro.com/lesson/oeY7ncZhzJ5NO6dij5e7/masterclass-what-software-engineers-should-look-for-in-their-engineering-manager/)
- [\[Taro Top 10\] Getting Promoted Faster In Tech](https://www.jointaro.com/playlist/eZOEUatYEe7BBAZByuha/)

Ace Your Tech Interview As A Software Engineer [Part 31] - Scout Online

It's the classic question: What can I expect for the interview for X company? Well, chances are that you aren't doing enough to find information online. This lesson teaches you:

- Why your Big Tech interview should never be a complete surprise
- The various big online sources of interview information, organized by quality
- How you should organize online interview information to extract the best insights and optimize your interview preparation

To build up your network to get insider interview advice, follow our masterclass: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/playlist/nvsMxZ9ZGIjlyaZbWqYS/)

Write A Stellar Resume As A Software Engineer [Part 19] - When You Don't Have Enough

A 1-page resume is the golden standard, and engineers usually mess up by going above that 1 page. However, what happens if you're incredibly junior and you're the opposite, having less than 1 page? This lesson teaches you:

- How to stretch your Education section on your resume
- What to do with your resume's project section when you're just a student
- Other simple tricks to make your resume longer and fill up that 1 page

Ace Your Tech Interview As A Software Engineer [Part 20] - Automated Coding Screen

Tech companies are trying to rely more and more on robots to screen software engineer job candidates out. This lesson teaches you:

- When automated coding screens appear
- What to expect when you get an automated coding screen like HackerRank
- Whether you should do automated coding screens

DSA Crash Course [Part 45] - Tree Includes Approach

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

> Write a function, *tree_includes*, that takes in the root of a binary tree and a target value. The function should return a boolean indicating whether or not the value is contained in the tree.

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

tree_includes(a, "e") # -> True
```

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

tree_includes(a, "a") # -> True
```

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

tree_includes(a, "n") # -> False
```

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

How To Be An Effective Tech Lead [Part 17] - Go Deeper: Follow Through

Congratulations on making it to the final lesson of the course! This lesson teaches you:

- The key takeaways of being an effective tech lead
- Technical items you can take on to start being a better tech lead
- Leadership items you can take on to start being a better tech lead

For further support, start career discussions in the Taro forum to get top-tier advice: <https://www.jointaro.com/questions/create/>

You can also go deeper with our related courses:

- [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [\[Course\] System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)
- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [\[Course\] Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)

Handling a PIP: The Ultimate Guide To Navigating A PIP

There are two options after a PIP: either the employee will remove all the doubts about the performance concern, or the employee will be terminated.

Your job as an employee is to judge your manager’s intentions. Your manager is the most important person in the PIP, and more generally, in your career. Many managers view the PIP as a formality before termination, and they’ve already given up on you. In that case, **you need to leave.** You don’t win any bonus points by "proving them wrong."

If the manager is responsive to your questions, provides constant feedback, and has a reasonable PIP plan, you may have a chance to succeed.

However, in the vast majority of cases, our recommendation is that you **must start looking for a** **new job.**

The biggest reason a PIP is not worth fighting is because **you want to work for people who believe in you**. This is critical for career success: you need someone who is unfailingly supportive of you, whether that's a friend, mentor, or manager. A PIP does not feel like support. In fact, it feels like the opposite. Your manager felt your performance was weak enough that they literally spent hours documenting how you fell behind, and then informed you in a legal manner.

The joke is that PIP should stand for “Paid Interview Period”, and that is honestly our recommendation for many tech workers who receive a PIP.

Here is the **PIP Evaluation Framework** in order to make the best decision once you’ve received the PIP. If 1+ of the following are true, you should **not** plan to have a long-term future at your current company.

- Your manager is uncommunicative or closed off
- The time horizon for the assigned work on the PIP is unrealistic (e.g. 1 week for a launch)
- The goalposts for the projects keep shifting
- The PIP work and your “normal duties” result in an unmanageable workload
- Your team is unsupportive

Grow From Mid-Level To Senior Engineer [Part 18] - Build A Strong Internal Network

If you have a meaningful bench of people who are willing to fight for your success, you will succeed as a software engineer. One of the simplest ways to understand seniority is that this bench grows larger and larger over time. This lesson teaches you:

- How an engineer's internal network at a company evolves as they grow from mid-level to senior, both in terms of breadth and depth
- How to expand your internal network
- The difference in peer feedback that mid-level engineers get compared to senior engineers, especially with XFN (cross-functional) partners

To dive deeper into earning trust quickly and building relationships: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

DSA Crash Course [Part 42] - Breadth First Values Walkthrough

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

Code along and test your work in the following editor workspace: <https://structy.net/problems/breadth-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 20] - Do Not Lie

The tech job market is incredibly brutal for software engineers, and this can make less ethical approaches far more appealing, including with your resume. This lesson teaches you:

- Why lying on your resume ultimately hurts you far more than it helps you
- What to do instead of lying when your resume is struggling

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.