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>

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

Maximize Your Productivity As A Software Engineer [Part 9] - Focus Blocks

Context switching is one of your biggest enemies as a software engineer. This lesson teaches you:

- What a focus block is
- Why getting back into coding is so difficult, especially at Big Tech
- The power of focus blocks with involved tasks, particularly with writing code

20 Years Of Fighting Procrastination [Part 6] - The #1 Way To Create Accountability

When motivation fades, there's a simple yet powerful way to regain momentum—build accountability into your workflow. Here are the key ideas from the lesson:

- Social pressure is more powerful than self-discipline alone, making accountability partners or group settings highly effective for staying on track

- Benefits of accountability include learning from others, drawing inspiration, and getting called out when you're making excuses or losing focus

- Tactics include going into the office, joining virtual co-working platforms, setting review checkpoints, or scheduling deadlines—even artificial ones—to create external motivation and structure

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

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.

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

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

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

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.

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

[Part 1] Software Engineer Onboarding: Embrace Your Lack of Knowledge

Don't be afraid to NOT know something. Ask questions.

When you first join a team, there's a lot that you don't know, and that's ok!! No one expects you to know the codebase, the context, and the structure within your new role. Your goal is to gain context through your questions. 

- [Asking Questions Is NOT A Sign Of Weakness](https://www.jointaro.com/lesson/YIL3iK8fmSwhWP0PASqe/asking-questions-is-not-a-sign-of-weakness/)
- [Overcoming Imposter Syndrome - You Have Much More Value Than You Realize](https://www.jointaro.com/lesson/dTSdd4ozp298jH3glvnx/overcoming-imposter-syndrome-you-have-much-more-value-than-you-realize/)
- [How To Find A Good Team With Career Growth Opportunities](https://www.jointaro.com/lesson/UGIUC9zaGccK0tOarBri/how-to-find-a-good-team-with-career-growth-opportunities/)
- [Alex's Guide to Effective Communication](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)

This is part 1 of a 4 part series from Daniel about how to **most efficiently** and **most effectively** onboard into a new team or company. What should you spend your time doing in the first few months of joining, and how should that change based on your level? 

This masterclass covers this topic from the perspective of Daniel Tomko, a 20 year Big Tech veteran. Daniel spent 11 years at Microsoft and 8 years at Meta in various senior IC and management positions. 

- [Go to part 2 of the masterclass here](https://www.jointaro.com/lesson/jr0iHuUCGW5lCdBndEpO/part-2-software-engineer-onboarding-learn-the-workflow/)
- Connect with Daniel Tomko on [LinkedIn](https://www.linkedin.com/in/danieltomko/)
- Check out the [Formation.dev discount](https://www.jointaro.com/perks/) for Taro Premium members

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

Effective Communication Guide [Part 7] - Finale + How You Can Learn More

- Zooming out, good communication is about *building positive energy*. Sharing feedback to help someone improve, empathizing with people's struggles, giving heartfelt thanks - These all generate positive energy.
- If you're feeling angry or frustrated, take some time to calm down and collect your thoughts, especially if you want to share that in a more public setting. After you've done this, then you can share your problems in a constructive way.
- This series just barely scratches the surface when it comes to communication. Just keep practicing and you'll get better!

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

The #1 Tried And True Tool For DSA Interviews

Related resources:

- [\[Taro Top 10\] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [\[Taro Top 10\] Finding A Tech Job](https://www.jointaro.com/playlist/E6R0wVJ5EyCfVnVrlfno/)

Become A Debugging Master [Part 3] - Debugging Is A Premium Skill

Debugging is one of the most difficult yet valuable skills you can develop as a software engineer. Here are the core points from the lesson:

- Debugging isn’t just one skill—it involves asking sharp questions, deductive reasoning, clear communication, systems thinking, and holistic understanding
- As AI-generated “vibe coding” becomes more common, engineers who can deeply understand and fix code will become even more valuable
- Successful debugging requires patience and true technical mastery, far beyond just prompting an AI or relying on automated solutions
- Beyond fixing bugs, top engineers also prioritize which bugs matter most, combining technical problem-solving with smart decision-making for maximum impact

Ace Your Tech Interview As A Software Engineer [Part 6] - Having The Right Mentality

A lot of software engineers actually have all the necessary skills to pass the interview - They just choke when the time finally comes. Why is that? Well, let's dive into why. This video teaches you:

- The terrible unhealthy mentality software engineers often have going into tough tech interviews, particularly with top companies like FAANG
- What mentality you should have instead to unlock your full potential and why it's hard to ascend to this level of mental clarity
- How having the right mentality greatly improves your interview performance, far more than any amount of preparation ever can

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.