Master The Behavioral Interview [Part 10] - When You Don’t Have An Answer

If you're an earlier-in-career software engineer, there is a very high chance that you will get a behavioral interview question where you don't have an answer. This lesson teaches you:

- How to gracefully and immediately react when you get a behavioral interview question asking for a scenario that you have never been in before
- Backup options that you can present to the interviewer to still answer the question despite not having an answer that 100% fits

DSA Crash Course [Part 51] - Graph Intro Lecture

In this lecture, Alvin explains the basic structure of a graph.

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

Maximize Your Productivity As A Software Engineer [Part 19] - Eat The Frog

The first couple hours after you start work are absolutely crucial - Unfortunately many software engineers waste this crucial time, working on the wrong type of tasks. This lesson teaches you:

- What it means to eat the frog (don't worry, it doesn't involve any actual eating or 🐸s)
- Why eating the frog is so important
- The difference between junk food tasks and core tasks

Ace Your Tech Interview As A Software Engineer [Part 38] - Go Deeper, Follow Through

You made it! By completing this course, you have attained the necessary wisdom to avoid the many, many failure modes software engineers so often fall into when searching for a job. This video teaches you:

- Why completing this course is actually just the beginning of your job search success
- The Top 5 overall learnings from this course
- The exact difference between struggling job seekers and successful ones
- How you can follow through with the knowledge gained from this course and actually apply it to your job search

Maximize Your Productivity As A Software Engineer [Part 10] - Organize Your Calendar

Now we know that focus blocks are one of the most powerful weapons in a software engineer's arsenal. So how can we get them? This lesson teaches you:

- How to organize your meetings in the most efficient way
- What you should look out for when it comes to clearing space on your calendar

Figuring Out The Best Company To Join As A Software Engineer

In this lesson we talk about two strategic approaches to identifying companies where you'll thrive: following talented people in your network and ensuring cultural alignment with a company's core strengths.

- **Follow the talent you know and respect** — the tech industry is full of extremely talented people with strong integrity, and the companies they choose to join have already passed a meaningful bar; if someone you truly respect decided a company was worth their time, that's a powerful signal it's worth investigating for yourself.
- **Match your values against a company's core cultural strengths** — different companies have distinct cultural values (like Amazon's leadership principles or Netflix's emphasis on freedom and responsibility), and misalignment makes it far too easy to work hard without achieving meaningful impact or career growth, so understanding this fit upfront is critical.
- **Leverage your network to research company culture** — to discover what the culture is really like beyond the marketing materials, consult people in your network who work there or have worked there recently, and tap into communities like Taro Premium where engineers share honest insights about their experiences.

  **Related resources:**


- [\[Masterclass\] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)
- ["What's the best way to think about a team switch?"](https://www.jointaro.com/question/NwXACx0n3JniBETi3f1E/whats-the-best-way-to-think-about-a-team-switch/)
- ["What questions can I ask a potential new team?"](https://www.jointaro.com/question/dLS6KcDwKNdMDlJwYdBw/what-questions-can-i-ask-a-potential-new-team/)

Bad Question vs. Good Question Example

Is the following a good question: What are the best open-source projects to work on?

"What are the best open-source projects to work on?" - How can the asker improve this question?

Is the following a good question: Any Java developers here who have worked on ML?

"Any Java developers here who have worked on ML?" - Why is this not a good question?

Is the following a good question: Does anybody know what the front-end engineering interview for Amazon looks like?

"Does anybody know what the front-end engineering interview for Amazon looks like?" - How can the asker improve this question?

Is the following a good question: Can someone recommend me resources for blockchain development?

"Can someone recommend me resources for blockchain development?" - How can the asker improve this question?

Is the following a good question: Is there anybody here who can refer me into FAANG?

"Is there anybody here who can refer me into FAANG?" - Why is this not a good question?

Asking questions is one of the most important skills for an engineer: However, so many engineers struggle with this and ask questions that are bad at getting answers. This is all even more important in the age of AI with tools like ChatGPT.

This video covers an in-depth example of a bad questions vs. a good question:

### Bad Question
*"I'm trying to load an image in my Android app, and it shows up blank. Any ideas on what's going on here?"*

Here's why this question falls short:
- It feels lazy as the asker doesn't share what they have tried already - Did they even do a Google search?
- There's no context on why they're trying to get an image to load - The impact of helping this person is unclear.
- There is 0 relevant code attached: This question forces potential helpers to ask a lot of follow-up questions to give advice.

## Good Question
The upgraded question is too long (check the video to see it), so here are the core points as to why it's better:
- The user attached everything they have tried.
- There's links to additional context if helpers reading the question want to dive deeper - Keep in mind that they're not embedded directly within the question as huge code blocks can be overwhelming.
- In general, it's very obvious that the asker put a lot of effort into the question and is respectful of everyone's time.

Related resources:
- [[Masterclass] How To Learn Quickly In Tech](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/) - The full video where this clip was taken from
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://www.jointaro.com/question/vNE8kgpx2zdI1wACg9jA/how-do-you-overcome-the-fear-of-asking-stupid-questions-bothering-people-when-you-need-help/)
- [[Case Study] How Engineers Unlock Huge Impact With Artificial Intelligence (AI)](https://www.jointaro.com/lesson/gTQZbv0lmmypLPytqw5g/case-study-how-engineers-unlock-huge-impact-with-artificial-intelligence-ai/)

Grow From Mid-Level To Senior Engineer [Part 12] - System Design

System design is a topic engineers are becoming more and more familiar with, largely due to their emerging prevalence in interviews. It's also critical for the mid-level to senior promotion. This lesson teaches you:

- Why system design is the most important technical skill that mid-level engineers need to develop to grow to senior
- The ingredients of a high-quality system design document
- How to get feedback on your system design document
- Tactics to run an effective technical review meeting

Here's the system design course: [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

System Design Series: Taro Playlists [Part 6] - Overall Approach And Tradeoffs

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're designing systems at your job!

The tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

- When it comes to determining your overall approach, it's important to understand the priorities and values of your team/company. You can't have it all when building software; when you invest more in a certain attribute, it will generally take away from others. Here are some example attributes:
  - Execution speed
  - Feature robustness
  - Code readability
  - System scalability
  - Design and aesthetic
- Taro and very early-stage startups in general will make warped decisions as the prioritization leans extremely heavily towards execution speed. The goal is to 80/20 as much as possible when it comes to all the other attributes surrounding quality.
- Since this case study is a pretty basic CRUD play building on top of an existing model, there isn't too much complexity around the approach. However, you generally want to propose 2+ concrete approaches and the tradeoffs behind them, especially at a Big Tech company where you often have many, many options.
- Here are the technical design principles covered in the video:
  - **Single source of truth**: This is a very easy way to systems to break and have inconsistent experiences. Let's say your content object has 2 fields, a boolean of "hasLikes" and then an array of users who have liked this particular piece of content. You can either check the emptiness of the array to see if the object has likes or consult the boolean. It's extra work maintaining these 2 different representations of this information, and if they fall out of sync and 2 services/surfaces each read from a different one, things will get weird.
  - **Smart server, dumb client**: You cannot scale the user's device unless you ship them a new computer or phone. However, you can theoretically infinitely scale your server-side. This is why clients (i.e. usually front-ends) should be as dumb as possible with the back-end abstracting away as much complex logic as possible. This is especially true when your product is a mobile app as there will always be users lagging on older versions of the app - You don't want to have to make a mobile update every time you have a basic product logic change. Make your back-end protocol generic, flexible, and powerful.
  - **Be additive with data model**: This is primarily relevant with mobile apps as you will have users on older builds. If you change or remove a field, older builds will break. You can't count on your users to all update to the latest version of your app immediately.

Ace Your Tech Interview As A Software Engineer [Part 29] - Don't Get Downleveled

Downleveling is something many software engineers aren't aware of when they enter the industry and immediately start idolizing FAANG. It's a brutal phenomena that absolutely needs to be accounted for during your software engineer interview job search. This lesson teaches you:

- What downleveling is and why it's so common among Big Tech companies
- How to avoid getting downleveled in the interview process, both the easy way and the hard way
- General frameworks to understand the differences between the core engineering levels of junior, mid-level, senior, and staff at Big Tech companies

To develop a much better understanding of engineering levels at top tier companies, check this out: [\[Taro Top 10\] Understanding Engineering Levels](https://www.jointaro.com/playlist/e9rjATPbSyvRPsukXiHn/)

Level Up Your Code Quality As A Software Engineer [Part 25] - Seas Of Newlines

Newlines are necessary everywhere (including this video description), but they're very much something that can get annoying fast in large quantities. This includes code. This lesson will teach you:

- The "Seas Of Newlines" messy code anti-pattern
- How to fix code that's like this and write better code instead

Grow From Mid-Level To Senior Engineer [Part 24] - Go Deeper: Follow Through

Start a career discussion in Taro: <https://www.jointaro.com/questions/create/>

Join Taro events: <https://www.jointaro.com/events/>

Come to Alex's Group Office Hours: <https://www.jointaro.com/p/alex-chiou/>

Related courses:

- [Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)
- [Managing Up: Build Effective Relationships With Your Boss](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/)
- [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

The Most Common Mistake Made When Authoring Code Reviews

In this video, we focus on the **critical importance of providing context** when submitting code for review. As codebases grow in size and complexity, understanding the "why" behind a change becomes just as important as the code itself. Without clear context, reviewers are left in the dark—and teams lose valuable time and trust.

### Key Takeaways:

- **We explain the “why” behind every diff**: When submitting code, we clarify *why* the change exists, *why* we chose this approach, and *why* alternatives were rejected. This empowers reviewers to assess our choices without second-guessing or chasing us for clarification.
- **We include business, technical, and historical context**: Good diffs often explain the strategic purpose, relevant architecture, past experiments, and legacy code decisions—all of which help reviewers understand how our change fits into the larger system.
- **We reduce friction with thoughtful summaries**: A well-written diff summary is low-effort but high-impact. Taking 5–10 minutes to write it may feel like a tax, but it dramatically speeds up reviews and earns the gratitude of teammates.
- **We acknowledge that no one sees the whole system**: Using the “elephant” metaphor, we recognize that everyone sees only part of the codebase. Providing our view helps others see how our changes fit into the broader system, making collaboration more effective.
- **We write for humans, not just machines**: Code may be infinitely flexible, but humans need context to interpret it. By empathizing with reviewers and anticipating their questions, we make code review a faster, smoother, and more collaborative process.

Tech Lead Blueprint 11/17 - Empathetic Leadership

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

Suppress Your Instincts And Treat All Feedback As A Gift

True or false: If you get a piece of feedback, you should initially assume good intent and that it is correct.

What should be your immediate reaction when you get a piece of constructive feedback?

True or false: If you get feedback that you do not believe is 100% correct, you should just ignore it.

Which of the following are good things you can do when you get a piece of feedback that you genuinely believe is not constructive and is phrased in a harmful way?

True or false: One of the most straightforward ways to grow in tech is to just immediately incorporate every piece of feedback you get.

- **Don't be defensive at all when receiving feedback unless it is entirely incorrect.**
- If you have taken the time to find a supportive team, the vast majority of feedback you receive (95%+) will be correct and have value.
- Feedback is a gift and arguably the greatest gift you can possibly receive for your career. *One of the most common attributes among top performer engineers is that they take and apply feedback extremely well.*
- Have empathy for the feedback giver. They probably feel a bit awkward as they're unsure how you're going to receive the feedback. Make them feel comfortable after they share the feedback by thanking them immediately and earnestly.
- Write down all great feedback you receive and try to convert it into action items:
  - **Example:** "I feel like you could be more active in meetings." -> I will try to say at least 1 thing in every team meeting from now on.
- If you get feedback you genuinely believe is incorrect and hurtful:
  - Talk to your manager if you don't have a good relationship with that person.
  - If you feel comfortable enough to talk with that person directly, have a crucial conversation.

Related resources:
- ["How can I find more opportunities to grow when I'm getting very little real feedback?"](https://link.jointaro.com/TzKmgN5nLnLyXJ5G6)
- ["Everyone's telling me I'm doing great - How do I get actionable, constructive feedback?"](https://link.jointaro.com/ng6MUQy2yUfS8w4e8)
- [Effective Communication Guide - Giving Feedback](https://link.jointaro.com/VsQvnzsnJbbXUQDy6)

How To REALLY Say Thank You To Coworkers

Most software engineers struggle with building relationships and professional networking overall. One of the ways to get better at this is improving an often-neglected skill: Giving thanks. This video covers one of the most powerful ways to give thanks in the workplace.

Here are the core points:
- **Reward good work through their manager** - As an authority figure, praise coming from your manager is especially meaningful and it's a great experience when it happens. Spend effort adding weight to your feedback when you tell their manager by writing a heartfelt paragraph or telling them in person (this is really easy when you share the same manager as the peer, which is often the case). Thanking the helper directly yourself first is the first step: This manager reinforcement step is what really makes them realize, *"Wow, this person **really** wants to make sure I get rewarded for my efforts."*
- **Boost your peers' performance reviews** - At a higher level, you really earn your way into coworkers' hearts when they attribute you to a boost in their own performance rating. This is especially true at top companies like FAANG which have such a high-bar for engineer performance and good ratings are connected to very meaningful raises and promotions. If someone is helping you on a recurring basis, you can even explicitly tell their manager that you really hope they get rewarded on their performance review for uplifting you and really multiplying your impact. *Fight for the credit you ardently believe they deserve.*

Related resources:
- [Effective Communication Guide - Building Relationships](https://www.jointaro.com/lesson/488EjOLzU707WhdqMOK4/effective-communication-guide-part-3-building-relationships/)
- ["How do you network effectively within a company?"](https://www.jointaro.com/question/DwT9GtdYK9nwFV3a7jrU/how-do-you-network-effectively-within-a-company/)

What is a PIP? The Ultimate Guide To Navigating A PIP

A PIP is a **Performance Improvement Plan**. A PIP covers specific areas of performance deficiencies and sets clear expectations for what needs to happen in the future to remain employed. Think about a PIP as an ultimatum, essentially telling the employee that "Something needs to change." The employee has been deemed (whether fairly or unfairly, as we’ll see) to be missing their targets.

The PIP will outline a plan to improve the employee’s performance, along with milestones to hit over 1-3 months. The manager will document instances where your performance was lacking, pulling in quotes from colleagues, individual code reviews, or emails you may have sent (or have not) sent. A PIP can feel like a personal attack: the manager will spend hours compiling an argument "against you", explaining why you're not meeting expectations.

We’ll talk about specific strategies to use if you’re on a PIP, but for now, just remember this: **You can still have an amazing career after a PIP.**

Being on a PIP is like being on an extended interview. You have all the anxiety and judgment from a high-pressure environment, but it's actually worse: instead of starting from neutral, you're starting with a negative perception. And a multi-month interview sounds terrible.

Employees on a PIP are not allowed to switch teams. The company has concerns about whether the employee can productively contribute to the company, so they want to avoid the chaos of allowing team switches. This is unfortunate because you may just have a really poor fit with your manager.

Because of the overhead involved with a PIP, generally only medium and large companies will issue them.

The Human Resources (HR) team is involved in every PIP, which is a bad sign. The main function of HR, if not the sole function, is to protect the company’s interests, not the employees’. Once HR gets involved, and the manager has started documenting gaps in the employee's performance, clearly that indicates that there’s been a loss of trust.

This course will cover 4 phases of the PIP lifecycle:

- Before the PIP (but perhaps in the danger zone)
- Receiving the PIP within the company and deciding what to do
- Case studies of Individual Contributors (ICs) who received PIPs, along with managers who have delivered PIPs
- After the PIP -- how to ensure you have a great career even if you received a PIP

Maximize Your Productivity As A Software Engineer [Part 14] - Do The Hardest Thing First

When you get a tough project, it's tempting to tackle the easiest parts first because you already know how to do them, putting off the most difficult portions for later (you'll totally figure it out right?). This lesson teaches you:

- The difference between bad and good engineers when it comes to taking on a project
- Why tackling the hardest parts of a project first is effective risk management and a defining behavior of the best tech leadWhen you
- The massive team-wide benefit solving the hardest problem grants you

20 Years Of Fighting Procrastination [Part 13] - Your Phone Is A Menace

Your phone can be both a powerful tool and a massive productivity killer—how you manage it makes all the difference. Here are the core points from the lesson:

- To prevent unconscious distractions, keep your phone physically out of reach during deep work and turn off nearly all notifications by default
- Replace passive phone checking with active forecasting—mentally plan what you’ll do next based on the outcome of a task to stay engaged
- Use batching strategies (e.g. scheduled email checks) to reduce context switching and maintain focus
- Aim to move up the PEM framework: from Pleasure (mindless scrolling) → Engagement (being immersed in your craft) → Meaning (working toward a long-term purpose)

20 Years Of Fighting Procrastination [Part 11] - Decompose Aggressively

Decomposition is one of the most reliable habits for making progress feel easy, especially when applied daily. Here are the core points from the lesson:

- Breaking down large, ambiguous tasks into small, concrete steps helps reduce mental friction and makes it easier to start taking action
- Practicing decomposition builds leadership skills and supports team collaboration, since assigning scoped work is essential for effective delegation
- Writing down one key task the night before primes your brain to subconsciously begin planning, leading to more clarity and momentum the next morning

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.