Uplevel Your 1:1s

1:1s are the bedrock for the budding corporate relationships you are entering into:

Three principles for effective 1:1s (see [Rahul's YouTube video on the topic](https://www.youtube.com/watch?v=ADWkkJtZna4)):

- Pursue awkward 1:1s
- Go beyond status updates
- Write down takeaways

For important people, you should **never** run out of things to talk about. Here's a starting point for what to discuss: 

- Reflect on what’s going well and not going well for you
- Reflect on what’s going well and not going well for the team (and team priorities)
- Ask for opportunities or resources
- Give feedback or ask for feedback
- Brainstorm
- Career/performance review planning

[Case Study] Building An App With 1,000,000+ Users To Get Into Facebook

If you want to hear an in-depth \~30 minute breakdown of Alex's entire journey getting the Facebook offer, watch our video here: [How Alex Got Into Meta With 0 Prior LeetCode Experience](https://www.jointaro.com/lesson/ZYiTbN21FsqFxFdpwt5a/how-alex-got-into-meta-with-0-prior-leetcode-experience/)

To learn more about how to build effective side projects, check out these resources:
- [[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free](https://www.jointaro.com/lesson/AI4zi759PSGn6RwIFT6f/masterclass-how-to-come-up-with-100k-users-app-ideas-you-can-build-for-free/)
- [[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)
- ["How Long to Crank Out a Decent Side Project?"](https://www.jointaro.com/question/QA6lCGdPpwAd3xRrpjZ7/how-long-to-crank-out-a-decent-side-project/)
- [How Alex Made An App That Got 80k+ Users In 1 Month](https://www.jointaro.com/lesson/GlSjjLhuUdHt5drq3l5F/how-alex-made-an-app-that-got-80k-users-in-1-month/)
- [Presentation slides](https://docs.google.com/presentation/d/1MJU_LPnfc_QEu7386eSFvIbopG2VVUE3lTzkA458bYU/edit?usp=sharing)

If you want to dive deeper into the Random Name Picker app:
- [Download it on Google Play](https://play.google.com/store/apps/details?id=com.randomappsinc.studentpicker)
- [GitHub Source Code](https://github.com/Gear61/Random-Name-Picker)

Ace Your Tech Interview As A Software Engineer [Part 14] - Referrals

Having a current employee put you into their hiring pipeline via a referral is one of the most powerful ways to level up your job search. However, referrals are often misunderstood by software engineers. This lesson teaches you:

- The 2 different types of referrals and which one is better (spoiler: engineers usually struggle getting the better one)
- The massive difference between *weak referrals* and *strong referrals*
- Why you are more special than you realize and how you can leverage that to get more strong referrals
- How to approach professional networking properly to cultivate huge amounts of strong referrals over time

To help you get strong referrals, check out our networking course: [Networking Guide: Build Deep Relationships Quickly In Tech](https://www.jointaro.com/course/networking-guide-build-deep-relationships-quickly-in-tech/)

15 SWE Years In 1.5 Hours [Part 13] - The Secret To Growing Fast

Getting better isn't about which AI tool you use or what books you read or even which company you work for. How fast you improve comes down to one fundamental skill that most people struggle with. This lesson teaches you:

- Why feedback is the fuel for rapid engineer growth
- How many engineers respond incorrectly when it comes to getting feedback
- The right mentality to have when it comes to feedback overall
- Why an incorrect piece of feedback can actually be a good thing

Effective Communication Guide [Part 6] - Communicating In A Remote World

- What is lost in a remote work environment when it comes to communication?
  - **Volume:** A lot of ad-hoc communication ("water cooler chats") can't happen anymore.
  - **Depth of presence:** When you're on a video call, it's mainly just your face that's visible. In an in-person meeting, especially 1 on 1 meetings, your entire body is visible, which lets you express a lot more via your body language.
- **If you're comfortable, have video on during calls** - Use your facial expressions to really show that you're listening and truly hearing what the other person or people have to say.
- **Book 1 on 1s very aggressively** - 1 on 1 meetings are the core building block behind strong relationships. In an in-person environment, you will build relationships naturally through other means like team lunch, but since those are lost in a remote environment, you need to lean on 1 on 1s far more.
- **Get really good at technical writing** - In a remote world, especially with teams distributed across multiple time zones, a lot more communication has to happen asynchronously.
  - Project updates are very important in particular. It's much harder to stay aligned when everyone is apart.
  - If you aren't already, try to write a project update for your work every 2 weeks or more.

Ace Your Tech Interview As A Software Engineer [Part 28] - How Much LeetCode Should I Grind?

If you're this deep in the course, you now know that grinding 1,000 LeetCode problems doesn't lead to a Google hiring manager magically appearing on your doorstep with a fresh offer letter in hand. This lesson teaches you:

- Why data structures and algorithms are more damaging to the overall health of a job search than software engineers realize
- Exactly how over-indexing on data structures and algorithms and LeetCode completely destroys the job search of many software engineers
- The framework you should apply on whether you should be grinding LeetCode

DSA Crash Course [Part 36] - Want To Learn More DSA With Alvin?

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

Top System Design Interview Mistakes [Part 15] - Don't Ask For Too Much Permission

In this lessons, we address a common mistake, especially among junior engineers - Asking for too much permission. This often stems from a lack of confidence and a desire to avoid making decisions. Here are the core points:

- We often encounter candidates who, after discussing various options for solving a problem, defer decision-making to the interviewer

- Instead, we should make decisions ourselves. We can evaluate the options based on their trade-offs and choose the best one

- By taking ownership and driving the design, we demonstrate strong decision-making skills

- While it’s important to ask clarifying questions, we should avoid relying too heavily on the interviewer for directional guidance. Instead, we should proactively drive the conversation and make decisions that address the key issues.

If you need extra help with your system design interview, [Formation.dev](https://formation.dev/partners/taro) can provide you hands-on, personalized support. Join us here: <https://formation.dev/partners/taro>

Making Every Single Meeting You Have Effective

What do you absolutely need to do with every single meeting in order to make it effective?

What is the most important question you should be asking yourself constantly during a meeting?

Setting clear goals for every meeting ensures focus, alignment, and efficiency. Rather than drifting through discussions, this mindset helps make the most of everyone's time.

- **Define the meeting goal upfront**: Whether the goal is to build a relationship, align on a decision, or explore a specific topic, clarify it before stepping into the meeting.
- **Hold the goal in mind throughout**: Actively track whether the conversation is moving toward the intended objective—even as you engage in real-time dialogue.
- **Course-correct if needed**: If the meeting strays off-topic or stalls, use the goal as a guidepost to refocus the discussion or adjust expectations.
- **Reflect afterwards**: Evaluate whether the meeting achieved its intended outcome. If not, determine what adjustments can improve the effectiveness of future meetings.
- **Build the habit**: With consistent practice, goal-oriented thinking during meetings becomes second nature, enhancing both productivity and influence.

Don't Be Naive When Networking - Understand That You'll Get Burned

One of the main ways to grow your tech career is by building relationships. However, a lot of software engineers struggle immensely with this, dismissing the entire craft as "playing politics". This video explains why that mentality is toxic and how you should set up your mindset instead.

Here are the core points:
- **Every company will have politics** - What separates the good companies from the bad ones is that the good ones have a moderate amount of politics while the bad ones have an overwhelming amount of politics. If you're going to any decently sized company, you will have to do understand how to interact with people and get them to like you. It is near impossible to get to senior levels without being able to do this.
- **Professional networking is just like "real life"** - There isn't a huge difference between building work relationships and making personal friends and dating. The core principles behind establishing relationships and earning trust are the same both inside and outside of work.
- **Not every relationship will work out** - Similar to personal relationships, you will often times invest into people who won't return the favor. *Don't let that turn you off from the idea of networking as a whole.* Growing as a software engineer is a marathon filled with ups and downs. Don't let a few toxic coworkers or poor synergy partnerships tear you down.

Related resources:
- [[Masterclass] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/how-to-build-deep-relationships-quickly-in-tech-12172022/) - The full video where this clip was taken from
- [Effective Communication Guide - Building Relationships](https://www.jointaro.com/lesson/488EjOLzU707WhdqMOK4/effective-communication-guide-part-3-building-relationships/)
- ["How do I achieve my goals for this half when XFN is not communicating effectively?"](https://www.jointaro.com/question/Z1MwZ4GOA4XxxZd9ff5n/how-do-i-achieve-my-goals-for-this-half-when-xfn-is-not-communicating-effectively/)

Course Introduction: The Ultimate Guide To Navigating A Performance Improvement Plan (PIP)

You’ve probably heard about a PIP, a Performance Improvement Plan. You might be in danger of one, you’re going through one right now, or you’re about to join a company with a widespread PIP culture.

There’s no getting around it: **PIPs are scary.** Receiving a PIP means that there is a perceived deficiency in your performance, and something needs to change. It’s obvious why you might feel tremendous anxiety or fear around a PIP: your job is at stake.

Simply put, **a PIP is one of the most stressful things you can go through as a tech employee**. 

A quick online search reveals tons of discussion in forums about PIPs. It’s easy to get the impression that a PIP is a hopeless situation, and anyone who is unfortunate enough to receive one should simply give up. This is simply not true: whether you’re on a PIP or not, there is a path forward.

The objective for this course is to provide a structured way for you to identify what you can (and should) do to get the best outcome for yourself.

I’m Rahul, the course instructor. I’ve been an engineer at various-sized companies for a decade before I left to start Taro. I was an Engineering Manager and Staff Engineer at Meta (Facebook for the OGs), and before that I worked on Android at Pinterest. I graduated from Stanford with a Bachelor’s and Master’s degree in Computer Science, and my first job after graduation was founding engineer at a failed startup. 

In researching this course, I talked to dozens of engineers who have received PIPs, along with several managers who have delivered PIPs to their reports. You’ll hear some of their stories in the section dedicated to case studies (from companies like Amazon, Meta, Pinterest, MassMutual, and MongoDB). What became clear from chatting with so many employees is (1) there’s far too much stigma around a PIP and (2) there’s not enough support for people who have received one. This course aims to change that.

In addition, we’ve combined our own personal experience with dozens of hours of online research (we mostly ignored anonymous trolls in forums…).

I’ll occasionally refer to engineers throughout this course, but pretty much all the content is applicable to any type of tech worker (Product Manager, Data Scientist, Designer, etc). Software Engineers are not the only job function that must deal with a PIP!

Final note: my goal with this course it to be hyper-practical; this should be useful to you. I’ll be sharing best practices that have worked for many tech workers, but we can’t cover exact details across all companies in all geographies. I’m not an employment lawyer and I have never worked in Human Resources. You may want to get consultative help if your situation is unique. 

Connect with Rahul: 

- [Taro](https://www.jointaro.com/p/rahul-pandey/)
- [LinkedIn](https://www.linkedin.com/in/rpandey1234/)
- [YouTube](https://youtube.com/rpandey1234)

Read more about PIPs: 

- <https://jointaro.com/topic/performance-improvement-plan>
- <https://www.jointaro.com/blog/breaking-down-the-tech-company-mark-of-death-the-pip/>

PIPs and Interviews: The Ultimate Guide To Navigating A PIP

The PIP is as big a deal as you make it out to be. This is the key insight as you interview at other companies: **Don’t share information** **that hurts you.** 

In the same way that you wouldn’t share your previous salary or your compensation expeditions in the interview, you also shouldn’t share past performance struggles. You don’t get points for transparency. The thinking should be that you only share information if it helps you with the job interview. In particular, you should *never mention that you got PIP-ed*.

Instead, use neutral phrasing like “*I’m super excited about this company. I deeply resonate with the mission and people.*” Or *“The previous role wasn’t a good fit”*

Level Up Your Code Quality As A Software Engineer [Part 20] - Code Comment Caches

Code comments can be immensely helpful, but they can be incredibly damaging to a codebase if used incorrectly (which this course will cover even more later on down the line). This lesson will teach you:

- Why engineers will try the very weird "code comment cache" anti-pattern
- The importance of Git, GitHub, and version control platforms in general
- How to not be lazy and properly deal with code that isn't necessary now but may be useful later

DSA Crash Course [Part 20] - Sum Numbers Recursive Approach

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

> Write a function *sum_numbers_recursive* that takes in an array of numbers and returns the sum of all the numbers in the array. All elements will be integers. Solve this recursively.

```
sum_numbers_recursive([5, 2, 9, 10]); # -> 26
```

```
sum_numbers_recursive([1, -1, 1, -1, 1, -1, 1]); # -> 1
```

```
sum_numbers_recursive([]); # -> 0
```

```
sum_numbers_recursive([1000, 0, 0, 0, 0, 0, 1]); # -> 1001
```

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

[Masterclass] How To Work Better With Your Engineering Manager

Your engineering manager (EM) is easily the most important figure in your professional life, and how you manage your engineer &lt;-&gt; EM relationships across your various teams and companies will largely dictate how much career growth you have. The tricky part is that all of this is very hard, and if you don't do it properly, you can end up working against your manager instead of with them.

As always, the masterclass covers a *ton* of ground, so here's the Top 5 points:

- **Engineering management is a very hard job** - EMs are completely slammed with meetings and are constantly making hard decisions (e.g. *"Who do I hire and fire?"*). The first step towards fostering a healthy relationship here is having empathy for the natural difficulty behind their role.
- **It's up to YOU to leverage your manager** - Don't expect your manager to solo-carry you by proactively identifying all your issues and handing you the perfect growth plan on a silver platter. Nobody can read minds, and nobody cares about your personal growth more than you. Treat your manager as a resource, similar to how a front-end application treats an API. The API will never come to you - It's up to you to call it with the proper parameters to achieve the result you want.
- **Be extremely visible** - Be default, assume that your EM has 0 clue what you're doing, not out of malice but because they're swamped most of the time. cc your manager on important communications to keep them up-to-date with your biggest accomplishments and blockers. Add them as optional on meetings. Use your 1 on 1 to share crucial wins and status updates.
- **Maintain an ongoing dialog about performance** - Your performance review rating should never be a (negative) surprise. Ask every couple months for your manager to give you a hypothetical rating (make it clear that you will take it with a massive grain of salt). Don't let your fear of these awkward, transparent conversations lead to you getting put on an unexpected PIP.
- **Frame promotion as a mutual benefit** - It is not the manager's job to grow their engineers and get them all promoted; this is actually literally impossible in the current economy. It's the manager's job to make sure that their engineers are consistently shipping impact. This means that you must be extremely careful framing your promotion in a way where it's clear that your goal is to expand your impact and further empower the team, not to get more money and a higher title (it's totally fine to want these, they just have to be very far away from front and center).

Related resources:

- [Having The Proper Mentality For Manager 1 on 1s](https://www.jointaro.com/lesson/sIm7s54ILdBQmpCtKFtb/having-the-proper-mentality-for-manager-1-on-1s/)
- [1 on 1s Are The Time To Be Awkward](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/)
- ["How do I create a growth plan with my manager/mentor and what should it include?"](https://www.jointaro.com/question/BG4rWlnWQamBFI9ujCni/how-do-i-create-a-growth-plan-with-my-managermentor-and-what-should-it-include/)
- ["How do I give critical feedback to my manager?"](https://www.jointaro.com/question/VeGFF3JbpstS3Av5jpHB/how-do-i-give-critical-feedback-to-my-manager/)
- [\[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/)
- [Presentation Slides](https://docs.google.com/presentation/d/1zS7GJQmpZRS-fo-ZiiV5cHjdat9gHStPFVnA0awlFM0/edit?usp=sharing)

How to Crack System Design Interviews - Part 2: Clarifying Requirements

In a system design interview, the first step is gathering requirements, focusing on how users will interact with the system. Here's how we approach this:

- **Understand user needs:** We consider the basic functions users will need, such as applying filters, viewing original images, and deleting images.
- **Confirm and prioritize:** We check with the interviewer to ensure we've captured all the key requirements and prioritize the most important ones.
- **Identify trade-offs:** We analyze potential trade-offs, such as image quality versus storage needs, and quantify them whenever possible.
- **Set realistic expectations:** We avoid aiming for perfection and instead focus on creating a practical design that meets the core requirements.
- **Provide concrete examples:** We use real-world examples to illustrate our understanding of system design concepts and demonstrate our ability to make informed decisions.

[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.

[Masterclass] How To Stop Writing Messy Code As A Software Engineer

It's 10x easier to write messy code instead of good, clean code. The hard part is that unless you have good role models, it's extremely difficult to learn how to write quality code. If you're a software engineer going through this struggle, this masterclass is for you.

Here are the core points from the video:
- **There's no such thing as objectively "clean" code** - A lot of engineers treat code quality as something to "solve" where after they learn the best tech stack/database/framework, they can just plug that in everywhere and win. That's simply not how software works. The reason why writing truly great code is hard is because it's all about the context and nuance. Code that's good in one codebase can be horrible in another.
- **It's all about the user experience (UX)** - At the end of the day, the end-user doesn't care about your code quality. Most end-users have never read a single line of code in their life. The end-user simply wants a good UX, which means that if you need to write code that's a little messy to uphold good UX, you should do that.
- **Feel the pain of your bad code** - True learning comes from struggle, and if you really want to stop writing messy code, you need to see your own code break and struggle. Go outside of the happy flow and dogfood your own products and features aggressively. Read your old code every once in a while and see how horrible it was - If you groan then, that's a good sign of growth.
- **Break down your tasks** - A marquee trait of bad software engineers is that they jump straight into the coding, write a gigantic messy commit, and get demolished in code review. To prevent that, proactively decompose your tasks into smaller ones where each one is ideally 1-3 commits or a few days of work. This lets you come up with an actual plan for the task and invite your teammates' feedback at an earlier stage in development (i.e. before you write much or any code). For an in-depth guide on software decomposition, check out the discussion here: ["How do I make software less overwhelming?"](https://www.jointaro.com/question/YseMPDw538jhyS1MWlTs/how-do-i-make-software-less-overwhelming/)
- **Write clean pull requests (PRs)** - It doesn't matter if the code in your PR is bad as long as it's "dressed" well and optimized for your teammates to leave good feedback (which will make your code good!). Write atomic commits, have a real PR title, attach a thorough context section + test plan, and proactively call out tricky areas. Learn how to do all that with the following video and its related resources: [One Diff, One Thesis - What Every Code Review Should Be Like](https://www.jointaro.com/lesson/3NAbmgiaY3IpvayNIoVl/one-diff-one-thesis-what-every-code-review-should-be-like/)

Related resources:
- ["How to Learn/Practice Clean Code, particularly by oneself?"](https://www.jointaro.com/question/6DcTkiS9UJhDkQz1HIAL/how-to-learnpractice-clean-code-particularly-by-oneself/)
- ["How to upskill effectively, especially with the software design aspect?"](https://www.jointaro.com/question/JALOyWIOCo7UXIMLlUz3/how-to-upskill-effectively-especially-with-the-software-design-aspect/)
- [[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/)
- [[Masterclass] How To Do Amazing Code Review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/)
- [Presentation slides](https://docs.google.com/presentation/d/106NsN9Z9QNvZR_-LMaiVu2rT8Kro_4YwXS44j-rNLXk/edit?usp=sharing)

Become An Open Source Master [Part 4] - Open Source Terminology: Projects, Repos, Issues, PRs

We'll focus on GitHub, a popular platform for open-source software, to understand key terms and concepts.

- Projects and repositories (repos) are the core units of open-source projects on GitHub.
- You can view source code, metadata, and community activity within a repository.
- Issues are used to report bugs or request features, while pull requests propose code contributions.
- Pull requests are reviewed and discussed by the community before being accepted into the project.

Connect with James: 

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

Ace Your Tech Interview As A Software Engineer [Part 22] - Behavioral Interviews

Behavioral interviews are omnipresent across software engineer interviews. They are also excellent at filtering out problem candidates. This lesson teaches you:

- When you can see behavioral interviews
- What the purpose of behavioral interviews is
- Why software engineers often underappreciate and underrate behavioral interviews, leading to their failure
- Why behavioral interviews are the *most important interview round in any hiring loop*
- The 3 core principles you should always have in mind when answering a behavioral interview question

To master the behavioral interview, follow the resources here: [\[Taro Top 10\] Behavioral Interviews](https://www.jointaro.com/playlist/IPFmEPUhAmizNe9ZUWV5/)

Alex's blog post about behavioral interviews: [Software Engineer Interview Guide - Behavioral Questions](https://www.jointaro.com/blog/software-engineer-interview-guide-part-2-behavioral-questions/)

The Defining Trait Of Mediocre Software Engineers With Debugging

One of the main differences between a low-performing software engineer and a high-performing software engineer is that the high-performer looks for true solutions to bugs instead of hacky ones like the low-performer does. Don't suppress the symptoms when fixing bugs - Treat the root cause as well.

This video is a clip from our debugging masterclass. You can watch it here: [[Masterclass] How To Become A Debugging Master And Fix Issues Faster](https://www.jointaro.com/lesson/ioR6WzamAIUTpySLAr7o/masterclass-how-to-become-a-debugging-master-and-fix-issues-faster/)

Related resources:
- [[Case Study] Solving A Multi-Million $$ Instagram Bug](https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/case-study-solving-a-multi-million-dollardollar-instagram-bug/)
- ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://www.jointaro.com/question/QhqQQGrDgFjZbqohpKe0/how-can-i-become-more-independent-and-better-at-unblocking-myself-with-tricky-technical-issues/)
- ["What would you do, if you get a better solution purpose after PR?"](https://www.jointaro.com/question/PqxeNMxwHKsWYyWVyEbZ/what-would-you-do-if-you-get-a-better-solution-purpose-after-pr/)

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.