[Masterclass] How To Become A Debugging Master And Fix Issues Faster

There will always be bugs, and this only becomes more and more true as your product gets bigger. In this video, we go deep into the often underrated software engineer skill of debugging.

Here are the core points:
- **Bugs are a source of growth** - So many engineers see having to fix issues as merely frustration, an obstacle getting in the way of their feature work. This is a toxic mentality to have that holds back your growth. Feature work isn't the only way to move a product forward, and at the end of the day, your team has to come together to uphold the integrity of its systems. Being a champion in that process is a powerful way to get to senior+ levels.
- **Do your research** - When you get a bug, don't just dive in and start mucking around in the code. Figure out the exact repro steps and go through the flow multiple times to really get it. Detail the blast radius by understanding attributes like when the issue popped up, how many users it affected, and what versions of your software experience the problem. Spend at least 15-30 minutes expanding the context behind the bug.
- **Understand the end-to-end flow** - Every outcome in software is a series of steps: When there's a legitimate bug, it simply means that one (maybe several) of those steps are now broken. Before you start seriously debugging, build up this mental model of the overall ecosystem behind the bug - Ask your teammates if you need help with this. This mental model will serve as the foundation of your debug process.
- **Maintain a debug diary** - Document every step of your journey as you're debugging. This will prevent you from trying the same hypothesis twice and makes it much easier for you to hand off the bug if necessary. This context will allow the new person to easily "download" everything you did and pick up where you left off. This writing will also help you a lot come performance review time when you want to claim credit for the fix.
- **Retrospect** - An ounce of prevention is worth a pound of cure. After every bug resolution, do some amount of thinking around how you can prevent similar issues from cropping up in the future. This is especially important with massive bugs that inflicted a lot of damage. In those scenarios, write-up a post-mortem and discuss it with your team.

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 root cause bugs faster?"](https://www.jointaro.com/question/PSv7aYI70VwaDsoRgMyW/how-can-i-root-cause-bugs-faster/)
- ["I'm trying to fix a P1 bug, but some relevant code is owned by another team. Unsure about ownership and how to proceed."](https://www.jointaro.com/question/ZRneLgwmrM2JLCrGn5Rz/im-trying-to-fix-a-p1-bug-but-some-relevant-code-is-owned-by-another-team-unsure-about-ownership-and-how-to-proceed/)

If you want to become a better coder in general, check out our masterclass here: [[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/)

Here's Why You're Doing Interview Prep WRONG

Most people do very shallow interview prep that doesn't actually help them learn. Lists like Blind 75 and Leetcode 75 are not enough to truly master the technical interview for Big Tech companies. 

In this video, Daniel proposes the "proper" way to master the coding / DSA interview so that you can walk into interviews and feel more confident. There are no shortcuts and no memorization -- instead, it's about going beyond the solution for a problem, and then understanding the nuances and process to get the right answer.

- Connect with Daniel on [LinkedIn](https://www.linkedin.com/in/danieltomko/)
- Checkout Formation as part of [Taro Perks](https://www.jointaro.com/perks/)

Relevant Taro content: 
- [Effectively Learning Data Structures And Algorithms (DSA)](https://www.jointaro.com/lesson/XwpMMY3ss97zOrXJQ7Xr/effectively-learning-data-structures-and-algorithms-dsa/)
- [Struggling With DSA? Don't Worry, That's Healthy!](https://www.jointaro.com/lesson/SPWYdMAu5XQX8ds9MxXc/struggling-with-dsa-dont-worry-thats-healthy/)
- [Masterclass on DSA interviews](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/how-to-ace-your-big-tech-interview-data-structures-and-algorithms-7172021/)

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

Properly Learning From Software Engineers More Senior Than You

True or false: What is built by a very senior engineer is more important than how they built it.

When observing very senior engineers, what should you look for to properly learn from them?

True or false: At the top tech companies, the very senior engineers make 5-10x more than their very junior counterparts because they work 5-10x harder than they do.

Which are good examples of questions you can ask when understanding a very senior engineer's behavior?

True or false: At the top tech companies, you are told less and less what to do as you grow more senior, working on more ambiguous projects while having greater freedom to choose what you work on.

As a junior software engineer, it can be daunting understanding the senior and staff engineers on your team. This video covers the mindset shift to make to start leveling yourself from properly observing them, achieving career growth without these engineers having to formally mentor you.

Here's the core points:
- **Observe more senior teammates' behavior** - Principal engineers will usually have 10x the impact of a junior engineer. They don't get there by working 10x as hard - We all have the same 24 hours in a day. Instead of asking yourself *what* these great engineers are getting done, ask yourself, "*How* do these engineers get stuff done?". Marveling over their much larger impact won't get you anywhere - You start really learning from these engineers when you start breaking down the path they took to achieve that impact.
- Here are more specific axes to observe:
  - **Communication** - How do these engineers share status updates and rally the team around their ideas?
  - **Direction** - How do they prioritize projects and select the best ones?
  - **Quality** - How do these engineers protect the sanctity of launches? What kind of feedback are they leaving in code review? What good habits do they have when they submit code? How do they facilitate system design discussions?

Related resources:
- ["What's the core insight behind quick growth?"](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/)
- ["How do you get the most out of mentorship?"](https://www.jointaro.com/question/IbuZydz0QzsVVqESVaxQ/how-do-you-get-the-most-out-of-mentorship/)

An Autistic Journey To Google Staff Engineer [L6] From Software Analyst - By Lee McKeeman

[Lee McKeeman](https://www.linkedin.com/in/lmckeeman/) is an autistic software engineer with quite an incredible journey: Across a whopping ~20 years of experience, Lee has worked at Amazon (where he was an engineering manager and bar raiser), Meta, and now Google.

Lee's career story is super long (watch the video to get the full picture), so instead, we're sharing some of the great learnings from Lee here:
- **School doesn't actually teach you software** - University is generally rooted in theory and overly abstract exercises, leaving you with a very basic raw coding foundation. While that certainly has value, it's not enough to make you capable of doing actual software engineering, especially in a team environment.
- **Debugging is a critical skill** - Lee started off as a software analyst, which was a role that was much more focused on diving deep and fixing issues as opposed to churning out new features. The experience Lee got here was extremely valuable and continued paying dividends across his career, even after he transitioned to SWE.
- **Help others and keep an open mind** - Everyone works in different ways and will be comfortable/uncomfortable in situations that don't match that of others. This includes the neurodivergent population like autistic people, those with ADHD, and more. Be a true teammate by being understanding and accepting of these differences. Assume good intent, and if you aren't sure how you can best support a teammate, just ask them!

To learn more from Lee, you should 100% connect with him on LinkedIn where he writes some of the best posts (and comments) on the entire platform: [Lee's LinkedIn](https://www.linkedin.com/in/lmckeeman/)

Here's some of the incredible wisdom Lee has shared on Taro:
- ["What does it mean to not require handholding anymore?"](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/)
- ["How to Balance Responsibilities: Prioritizing Personal Work vs. 'Glue Work' in a New Team Environment."](https://www.jointaro.com/question/9NL4LP40xHy5sgGMvsmB/how-to-balance-responsibilities-prioritizing-personal-work-vs-glue-work-in-a-new-team-environment/)
- ["Can someone elaborate on "always treating feedback as a gift"?"](https://www.jointaro.com/question/4DoEnMIq2ISadfAJuwp9/can-someone-elaborate-on-always-treating-feedback-as-a-gift/)
- ["What do career levels structure in big tech company look like? What are the responsibilities for each level?"](https://www.jointaro.com/question/qV5oikdcgs4GWmGeousX/what-do-career-levels-structure-in-big-tech-company-look-like-what-are-the-responsibilities-for-each-level/)

How To Find A Good Team With Career Growth Opportunities

Not every team will have the scope you need to get to the next level, especially at FAANG and Big Tech. If you're looking to get to senior engineer levels and beyond, here's what to look out for in a team:
- **Past launches** - If the team has frequent, meaningful launches from the past year, it's likely this will continue.
- **Healthy balance of levels** - You want folks more senior than you to learn from and folks more junior than you for you to mentor and work through.
- **Strong engineering manager track record** - In particular, see who they have been able to get promoted. If there are examples of senior and staff engineers grown organically within the team, that's another good sign.

This clip was taken from our team selection masterclass. You can watch it here: [[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/)

Related resources:
- ["What should I look for in a new team in terms of growth?"](https://www.jointaro.com/question/i2bOMPrqaRc0NUZ7918F/what-should-i-look-for-in-a-new-team-in-terms-of-growth/) - Question from a Google L4 engineer
- ["How do I find a good team that sets me up for the mid-level -> senior level promotion?"](https://www.jointaro.com/question/oHJWlzm1qdHUZx66moaT/how-do-i-find-a-good-team-that-sets-me-up-for-the-mid-level-greater-senior-level-promotion/) - Question from an Amazon SDE 2
- ["What does it mean to not have enough scope to be promoted?"](https://www.jointaro.com/question/bJuagPwOEEy5vkcXKkqh/what-does-it-mean-to-not-have-enough-scope-to-be-promoted/)

Rachel's Career Story: Waterloo, Yelp, Airbnb

To check out Rachel's excellent tech career advice, you can find the [full playlist here](https://link.jointaro.com/EFUYvmLHzenKQLRp6).

Rachel moved to Canada in high school, and then attended the University of Waterloo where she picked up programming for the first time. 
- She did various internships as part of the co-op program, and her first job out of college was at Yelp. 
- After 9 years at Yelp, Rachel had become a Director of Engineering there.
- Since 2020, Rachel has been an Engineering Lead at Airbnb, heading up the search product there.

**Rachel's core learning**: The times where you're uncomfortable and struggle are the times you learn the most. Stay calm and embrace the more difficult times in your career - When you view these situations as a growth opportunity, that's how you come out of them stronger than you were before.

The Crucial First Step To Building Relationships That Everyone Misses

Many people in tech are bad at professional networking, and the reason is simple: They're being too selfish. If you want to build a professional network that is truly useful to you, you must strive to put yourself in the other person's shoes.

Here's the core points from the video:
- **Understand their incentives** - Everyone in the professional world is looking out for something: Nobody works purely for the sake of working. When you're working within a company environment, *this is usually what they're rewarded for in their performance review*. When you're asking for something, it's easy to get caught up in what *you're* looking for and how this other person can help *you*. The key to effective interpersonal communication is to flip that mentality and use your empathy to figure out *how you can help them instead*.
- **Alex's Instagram Misalignment Story**
  - Back in 2018, Instagram cofounders Kevin Systrom and Mike Krieger parted ways with Instagram and Facebook overall. This left a power vacuum with no clear "wing" of the company to drive the overall direction.
  - During this time, Alex was working on Instagram Ads. After the cofounders left, his team tried to ship a project to make the main action button on ads much bigger. Their A/B test showed that the new variant earned far more revenue.
  - The new CEO of Instagram, Adam Mosseri, shot the idea down, citing that it was too tacky. He then declared a design lockdown across all of Instagram stating that all new Instagram features needed to meet Instagram's user design standards.
  - This changed the incentives between designers and engineers at Instagram. Designers were now more focused on upholding the aesthetic integrity of Instagram and less so on shipping projects. On the other hand, engineers were still laser-focused on shipping.
  - *The engineers who best succeeded during this transitory period were those who worked together with the designers and championed their goals.* These engineers were willing to incorporate design polish and didn't immediately dismiss it as a threat to their timelines.

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
- [9-Part Effective Communication Master Series](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)
- ["How do I ask XFN partner for help to make progress in the project?"](https://www.jointaro.com/question/OCUrjUM8axEIOJkSKhZp/how-do-i-ask-xfn-partner-for-help-to-make-progress-in-the-project/)

"How did you decide to quit your job and make a startup?" - 9/13/2022

If you're interested in starting your own startup, check out our curated playlist for it here: [[Taro Top 10] Entrepreneurship And Tech Startups](https://www.jointaro.com/playlist/ArtlSzF17v7cad1K6TJG/)

- Alex has wanted to start his own thing for a while - Ever since his side projects started getting serious traction in 2015-2016 (25,000+ users each).
- The initial goal with [Tech Career Growth Community](https://www.linkedin.com/company/techcareergrowth/) wasn't to make a business out of it. The pandemic was happening and people were suffering - We just wanted to help people.
  - Tech Career Growth then grew beyond Rahul's and Alex's wildest imaginations.
  - This made them start thinking what they could accomplish if they worked on it full-time instead of part-time.
- For Alex, there are the core reasons why he decided to make the jump back in early 2022:
  - **Diminishing returns on "preparing" to make a startup** - He had the 0 to 1 experience from doing side projects and building Course Hero's Android apps from scratch. Meta was great helping him build soft skills.
  - **Tech Career Growth taking off** - Alex had more fun working on this community than working his full-time job at Robinhood (which is saying something as he *really* enjoyed working at Robinhood!).
  - **Getting into an incubator** - In late 2021, Alex and Rahul got into OnDeck, which gives the old YC deal of 125k for 7%.
  - **Life timing** - Alex is 30 as of the publishing date of this video, and creating a startup only gets harder as you age due to increasing responsibilities outside of work.

If you're interested in how Alex published ~30 apps that got ~3 million users combined, check these out:
- ["Finding a mobile app idea - How to do it?"](https://www.jointaro.com/question/KJ4VXh6rUhKbWeiJoRDe/finding-a-mobile-app-idea-how-to-do-it/)
- [[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/)

Lastly, here's a great discussion on how hard startups are compared to leveling up at a "traditional" job: ["Career advancement or building a startup? Which one is harder?"](https://www.jointaro.com/question/EquWmWjZhqiiujyltreJ/career-advancement-or-building-a-startup-which-one-is-harder/)

How To Figure Out If An Engineering Manager Is Good

This segment emphasizes how to make informed decisions when evaluating a potential team or engineering manager, especially in scenarios like internal transfers or team matching at large companies. Rather than relying solely on the perspectives of hiring managers, it's essential to dig deeper and gather honest insights.

- **Recognize incentive misalignment**: Engineering managers are incentivized to grow their team, so their portrayals may be overly positive. Rarely will a manager openly admit that a team has significant issues.
- **Talk to individual engineers**: Engineers, especially those who’ve been on the team for a while, tend to be more honest about both the strengths and challenges of the team. Speaking with two to three engineers—including the tech lead—can offer a well-rounded perspective.
- **Attend a team meeting if possible**: Observing how a team interacts in real-time reveals power dynamics. Red flags include a manager dominating the conversation or cutting off team members, indicating possible micromanagement.
- **Tap into your network**: For a broader view of the company or org, talk to trusted contacts about engineering culture and how managers are evaluated. These insights are rarely available through public sources.
- **Build long-term relationships for deeper intel**: Sensitive, nuanced feedback usually only surfaces when mutual trust exists. Superficial networking isn’t enough—invest in meaningful relationships to access the full truth about potential teams.

Don’t Do THIS Kind of Code Review - Healthy vs Unhealthy Comment Example

In this segment, we explore a crucial cultural principle in code review: **“You are not your code.”** The way we give feedback deeply influences team trust, learning, and psychological safety. Our goal isn’t to be “right”—it’s to help each other grow and to build a healthy, collaborative engineering culture.

### Key Takeaways:

- **We critique code, not people**: Everyone—from interns to staff engineers—writes imperfect code. We give feedback without attacking the author, always assuming good intent and shared goals.
- **We use empathy-driven language**: Ending comments with a question mark (“Have you considered…?”) or using tentative language (“This might miss an edge case…”) keeps feedback constructive and opens the door to discussion, not defensiveness.
- **We avoid destructive comments**: Terse feedback like “Did you even test this?” not only fails to help—it can demoralize authors and harm team culture. Being “right” is meaningless if it alienates collaborators.
- **We model humility, especially as senior engineers**: Seniority should amplify empathy, not authority. Even if we're confident, we acknowledge the possibility we're wrong and focus on dialogue, not dominance.
- **We prioritize helpfulness over harshness**: Great reviewers point to specific issues, offer reasoning, and invite collaboration. They focus on moving the work forward—not “winning” a debate.

By reviewing with empathy, humility, and clarity, we turn every code review into an opportunity to strengthen our team and elevate everyone’s craft.

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.

The Talk & Observe Framework

This framework ([Talk & Observe](https://www.jointaro.com/blog/talk-and-observe-a-framework-for-engineering-onboarding/)) captures the two most important ways you’ll learn as a new engineer.

1. **Talk** with various people on the team to learn what they do and what you need to know.

   1. To add more structure to this conversation, follow the advice from Boz (CTO at Meta): [Career Cold Start Algorithm](https://boz.com/articles/career-cold-start)

   2. Ask people’s priorities and what concerns they have.

2. **Observe** how others operate at the company by studying the artifacts of their work. As engineers, we naturally have tons of markers to our progress.

   1. Look at code commits, comments on code reviews, design docs, calendar blocks, team meeting notes, etc.
   2. Spending 10-15 minutes to observe ("*stalk*") every person on your team will reveal tons of insight. For example, someone may say that project A is the top priority, but all their time is spent on project B -- this mismatch is an opportunity for you as the new person.

[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

What's Often Overrated When Choosing Your Next Job

Here are the attributes we've generally seen software engineers prioritize too much when weighing career opportunities:
- **Product space** - This usually manifests as pursuing a tech trend (like VR or NFTs). Of course, if you're legitimately passionate about the space, go for it, but seriously ask yourself if you would be in this space if it wasn't regularly talked about.
- **Technical space** - Similar to product space, you can follow trends here. Choose a stack that you're legitimately passionate about, which also has the support network you need (very important for junior engineers). The risk with cutting-edge technology is that it often doesn't have a lot of mature teaching resources behind it (it's cutting edge for a reason).
- **Level/title** - Promotion is a decent and concrete career goal earlier on, but don't go to bad companies to maximize your title. At the end of the day, your level and title are just strings next to your name.
- **Compensation** - Money is genuinely important in almost all cases, but what a lot of people don't realize is that very high pay often comes with a catch (usually work-life balance). Try treating this as a lagging indicator - If you're genuinely growing fast as a software engineer, you will eventually
land an opportunity that is top-of-market (as you deserve).

This clip was taken from the following masterclass: [[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/)

Related resources:
- ["How should I think about levels when it comes to evaluating jobs and in my career overall?"](https://www.jointaro.com/question/siBFn9WmU204N6D0IRHZ/how-should-i-think-about-levels-when-it-comes-to-evaluating-jobs-and-in-my-career-overall/)
- ["I feel like senior engineers tend to focus on a specific area. How can I pick a specialization that's still relevant in 5-10 years?"](https://www.jointaro.com/question/xFEhcvfbJ2P0pYzZ4r6f/i-feel-like-senior-engineers-tend-to-focus-on-a-specific-area-how-can-i-pick-a-specialization-thats-still-relevant-in-5-10-years/)

How Managers Split Their Time Between High/Medium/Low Performers

David Pan (former VP of Engineering) talks about how he managers should split their time between high, medium, and low performers.

David argues that managers should **spend the majority of their time with high performers**, as they are the ones who are most likely to drive the team's success. However, David also argues that managers should not neglect medium and low performers, as they can still contribute to the team's success with the right support.

- 📈 **For high performers**, managers should focus on providing opportunities for growth and development. 
- 🙂 **For medium performers**, managers should provide feedback and coaching. 
- 😔 **For low performers**, managers should provide support and resources to help them improve their performance. If their poor performance is sustained, they should be removed from the team to avoid negative impact on the rest of the team.

High performers typically do 80% of the work, while medium performers do 30% of the work. That means the low performers are contributing -10%!

Related resources:
- ["How to manage a team towards high performance?"](https://www.jointaro.com/question/O8vtGxsrwZebiSSlOlRd/how-to-manage-a-team-towards-high-performance/)
- ["How does Stack Ranking work (at FAANG) and how can I be proactive at a base level?"](https://www.jointaro.com/question/lScy3l2NPIrWvRuHOjcF/how-does-stack-ranking-work-at-faang-and-how-can-i-be-proactive-at-a-base-level/)

What Makes Up Total Compensation (TC) In Tech And Which Parts Matter

This video outlines the most important components of compensation in the tech industry and emphasizes how to assess and prioritize them effectively—especially when evaluating job offers or planning a negotiation.

- **Total compensation (TC)** typically includes base salary, equity, and bonuses, but many companies also add less impactful perks like free meals, fitness stipends, or game rooms.
- **The most meaningful and negotiable parts of compensation** are base salary, equity (like RSUs), and signing bonuses. These are the components with the greatest financial impact and room for movement in offer discussions.
- **Perks like catered lunches or company offsites** may sound appealing but usually amount to minor financial value—typically just a few hundred dollars a month—and shouldn’t drive decision-making.
- **Benefits such as 401(k) matching and paid time off** can be substantial, especially at top-tier companies, but are generally standardized and not negotiable between candidates.
- **When evaluating an offer**, focus on the components that both materially affect take-home pay and can be influenced during negotiation: base, bonus, and especially equity.

The Best Programming Languages For Interviews

- Try to use a more concise language like Python if possible. This is because interviews, DSA rounds in particular, are a precise time management exercise.
- However, if you are *very* familiar with a certain language, use that. The exception is if that language is very verbose like C.
- Avoid the trap of using a rarer, "fancier" language. It may cost you time to explain, and if you aren't actually that knowledgeable in it, you may get called out.

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

A Framework For Integrating AI Into Your Workflow

> **AI will not replace you. A person using AI will.**

This [tweet](https://twitter.com/svpino/status/1610984481342771200) was seen 5M times because it captures a transformation that will happen in the workplace over the next 5 years.

This video covers a practical framework to apply AI tools like ChatGPT, Bard, or Github Copilot to become more productive in your job.

The goal for many of us is to become the mythical **10x engineer** – they have 10x as much impact as their peers. These engineers do exist, but they don’t write 10x more code or fix 10x more bugs. Instead, they understand the concept of leverage, which manifests in two ways.

- Take a challenging problem, and solve it in a 10x or 100x better way
- Make 10 or 100 people around you more productive

Shreyas Doshi has a [framework called LNO](https://www.aakashg.com/2022/02/01/lno-framework-for-product-managers/) to identify where you should spend your effort:

- *Leverage (L)* tasks are tasks that have huge consequences and you should do a great job.
- *Neutral (N)* tasks are tasks that are important, but don't have a big payoff. You should do a good job.
- *Overhead (O)* tasks are tasks that are a tax on your time. You should just get it done.

Let's go through an example in each bucket:

In the **leverage** bucket is creating the design or architecture for the project. This is high leverage not only because architecture is inherently difficult to change, but it’s also an important trust-building exercise.

- Ask AI to identify what could go wrong with your general approach and then add that as a discussion.
- Ask AI to summarize documents related to what you’re trying to build
- Ask AI to solve the problem and then sanity-check. The results here won’t always be good, but at least you should be able to explain why you’re choosing one path over the other.

Some coding tasks are in the **neutral** bucket. AI gives us the opportunity to dramatically speed up how long some coding tasks take.

- Use tools like Copilot to write boilerplate code much faster
- Instead of having to go to StackOverflow, you can get answers inline
- Ask for things like regexes or how to do something in idiomatic Kotlin

Finally, there are tasks in the **overhead** category that AI can help minimize

- The classic example is writing your performance review – you’re not actually having any business impact.
- I recommend every engineer has a [brag document](https://www.jointaro.com/lesson/QVqPkuCvplbHSqBWtKJX/make-your-promotion-case-easy-keep-a-brag-journal/) of what they did throughout the half or year. Then you need to massage all your work into whatever template your company uses.

With the rise of AI, asking good questions is more important than ever. Artificial Intelligence cannot read your mind (at least not yet 😅), so the quality of your question dictates the quality of your response. Learn more about asking good questions with our course: [\[Course\] Ask Great Questions That Get Great Answers Quickly](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/)

Maximize Your Productivity As A Software Engineer [Part 3] - Finding The Best Things To Work On

If you have gone through this course in order, you now know that working on the right things is far more important than merely working on things faster. So how do yo figure out the best things to work on in your organization? This lesson teaches you:

- How to identify the optimal opportunities within your space
- A formula to classify tasks and projects by quality and stack rank them
- What you need to do with your prioritized tasks, particularly with your manager

To dive even deeper into this topic: ["How to figure out what the most important projects are?"](https://www.jointaro.com/question/CgCPA60bDDHoOteN7Lmb/how-to-figure-out-what-the-most-important-projects-are/)

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.