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>

Figuring Out What Matters In A Codebase

In a large codebase, the code will follow the Pareto Principle (the 80/20 rule): 20% of the components account for 80% of the impact. So your goal as the engineer is to spend most of your time on the 20% of code that matters to the business and matters to your coworkers.

How do you figure out where that 20% comes from?

- Talk to people
- Use blames to find hotspots
- Look for patterns in code reviews
- Look at past alerts and what triggered them

Meta Case Study - Debugging A Massive Production Issue

Here we go through an example bug at Meta. Given the information, we need to figure out what kind of root cause is behind the issue. This case study shows:
- Why it's important to understand the blast radius of a bug
- How knowing the context behind a bug can help you locate the problem area
- The value of having robust analytics

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 is the effective way to understand new repository in order to make the required changes in that repo?"](https://www.jointaro.com/question/KoxB3UU2zWC9pdYU6Rx0/what-is-the-effective-way-to-understand-new-repository-in-order-to-make-the-required-changes-in-that-repo/)

Ace The ML System Design Interview [Part 4] - Data

Data is the foundation of machine learning, and a thorough discussion of data is essential in any machine learning system design interview. Here are the core points from this lesson:

- Discuss labels, features, and data set splitting, understanding the trade-offs involved in each area
- Explore various methods for generating data labels, such as human annotation, synthetic data, and LLMs, while considering the pros and cons of each approach
- Focus on high-level feature sources, providing relevant examples and selecting predictive features while avoiding sensitive topics
- Understand feature encoding techniques, such as one-hot encoding and embeddings, and their impact on model performance
- Weigh the trade-offs between cross-validation and train-validate-test splits, while considering issues like data leakage and imbalances in the data set

If you like what Ilya has to say, subscribe to his YouTube for more high-quality ML/AI career guidance: [MLEpath - YouTube](https://go.mlepath.com/taro-youtube-mlepath)

If you want hands-on support from Ilya to crack the FAANG ML interview, join his coaching program: [MLEpath - Coaching Program](https://go.mlepath.com/taro-march-25)

Level Up Your Code Quality As A Software Engineer [Part 14] - How To Handle Migrations

There is term called "promotion-driven development" where software engineers propose big refactors and migrations to look good but don't fully follow through. This is especially common in Big Tech. This lesson will teach you:

- How to do code migrations properly
- How to judge the quality of a codebase based off of its consistency and how "good, modern code" can actually be harmful to the health of the codebase overall
- The mental and operating model behind how new engineers code, which is especially important if you're a tech lead (never forget this!)

Onboarding Tips For Senior+ Engineers

As a Senior Engineer (or Staff or Principal) coming into a new company, there will be some expectation that you are bringing in domain knowledge. Your opinion can be valuable. A few ways to have immediate impact:

- Contrast how your current company operates compared to past companies
- Ask questions about why certain processes exist or don't exist

As you ramp up, remember to "**respect what came before.**" You don't want to disparage existing systems without realizing that it was best designed at the time of construction with the constraints and knowledge *at the time*.

As a senior engineer, you also need to lay the foundation for team and org-level impact. This means you invest extra time in building relationships and meeting other senior/staff/principal engineers.

Senior Engineer video from krazam: <https://www.youtube.com/watch?v=eSqexFg74F8>

How To Actually Learn Software Engineer Skills

A very common trap among software engineers is that they end up merely acquiring knowledge instead of actually learning software engineer skills. This is especially true when you're onboarding into a new team or company.

Here are the core points from the video:
- **Learn how to fish** - If you are growing as a software engineer, you want to make sure that you're actually learning the systems underneath instead of just acquiring surface-level solutions to your problems. "Receiving fish" is knowing that solution X solves your problem Y. "Learning how to fish" is understanding how solution X was crafted.
- **Get maximum value per answer** - Learning is largely absorbing support from other software engineers. When this happens, make sure to deeply understand how they arrived at their support. This can be when they give you an answer to your question or leave a comment on your pull request. *Ask follow-up questions to "download" their thought process.* It's much better to take full advantage of each interaction all in one go, so you don't need to ask them other simple questions in the future.
- **Example:** A teammate helps you debug. You can ask them the following:
  - How did you identify the breaking code?
  - Why did you choose this approach for the fix vs. others?
  - If you couldn't understand the code immediately, how did you figure out who to ask to get this understanding?

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. [Click here to watch the full thing.](https://link.jointaro.com/9sJzfDeH3JdWzZRg9)

Related resources:
- [This Is How Software Engineers Should Initially Learn](https://link.jointaro.com/hoL4o29S3YsGsR9i7)
- [Building Software For Optimal Learning Example - Login Flow](https://link.jointaro.com/BjyeKesdaZt7SrwJ8)

Get Maximum Value Per Answer

You should "Learn how to fish" instead of "receiving fish" — your goal in onboarding is to become a self-sufficient, productive engineer as quickly as possible. 

The way you do that is to ask follow-up questions when you get help and understand how you would have arrived at the solution on your own.

Bias toward asking for help earlier when you're new to a company, since you don't know what you don't know. It's better to be more annoying for the first month on the job rather than somewhat annoying for 6 months.

Senior Staff Engineer (L7) Describes Most Important Skill - Rahul Malik

Rahul is a Senior Staff Engineer at Meta.

- **Most important skill**: dealing with ambiguity and working through others. Senior Staff Engineers operate in a broad space, so they have to be independent enough to make impact without a specific problem.
- **Advice**: figure out how decisions are made. Who makes the decisions, and what is the underlying value system?

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

Helpful links:
- [SWE2 --> Principal Eng in 4 years](https://www.jointaro.com/lesson/Lvf1TDKt1R4ZJSCr9BVv/rockstar-software-engineer-story-sw2-greater-principal-in-just-4-years/)
- Taro's top 10 to get promoted from [senior to staff engineer](https://www.jointaro.com/playlist/YD8LMCSlE71VUGUbNAWM/)
- [David Pan on what makes a great tech lead](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/)
- [Rahul on LinkedIn](https://www.linkedin.com/in/rahulbmalik/)

Maximize Your Productivity As A Software Engineer [Part 7] - Get Good Sleep

Sleep is one of the first things to go when software engineers are faced with daunting workloads. Unfortunately, this is a tradeoff with disastrous consequences which doesn't even solve the problem. This lesson teaches you:

- Why most software engineers get sleep completely wrong in every possible way
- The correct perspective to have with sleep
- The many benefits of getting 8+ hours of consistent sleep every day
- How sacrificing sleep actually makes you less productive, not more

The Key To Avoiding The Performance Improvement Plan (PIP)

Getting hit with a performance improvement plan (otherwise known as a "PIP") is one of the worst things that can happen to you as a software engineer. This makes avoiding a performance improvement plan one of the most important things for you to do, especially in the currently layoff-rich economy.

Here's the core points from the video.

- Your performance review rating should never be a surprise: Regularly check in with your manager to figure out how you're trending to avoid the dreaded PIP.
- On top of asking for constructive feedback regularly, you shouldn't be afraid to ask every 2-3 months if you're on track to get the rating you want once the formal performance review happens. The clearest way this manifests is a hypothetical rating: *"Would you give me at least a \[Meets Expectations\] for my performance so far?"* This is the most powerful way you can stay in sync with your manager.
- Make it clear with your manager that you'll take any hypothetical rating with a grain of salt, so they're more comfortable giving it to you. If you're brave enough, you can even ask them to err towards the lower-end so you don't overset expectations.
- Keep your eye on the ball: Keep referencing the expectations plan you made at the beginning of the cycle and evolving it as necessary.
- Turn it up at the later end of the cycle. Humans have bad memory: It's unfair, but recency bias is huge. Try to land your bigger wins just a few weeks or months before the formal performance review process starts.

Related resources:

- ["What's the difference between a low performer software engineer and a high performer?"](https://link.jointaro.com/QHkWNXoJV5Y9VYvH9)
- ["How do I help my manager (who is also my mentor) be a better manager and mentor?"](https://link.jointaro.com/eG5c6usaJNY9wopP8)

15 SWE Years In 1.5 Hours [Part 4] - Debugging

No matter how careful you are as a software engineer, your code will always have bugs. On top of that, you will also need to spend time fixing bugs in code written by other people. This lesson teaches you:

- Why debugging is always a valuable skill (while feature development often isn't)
- How debugging forces you to develop a deeper understanding of the system
- The framework and process you need to understand in order to fix any bug

Grow From Junior To Mid-Level Engineer [Part 4] - Structuring Your Growth

Even though junior engineer to mid-level engineer is the 1st and easiest promotion, it's still a meaningful evolution with many parts. This lesson teaches you:

- The 3 core areas of improvement to grow from junior -&gt; mid-level
- The most important area to improve to make the junior -&gt; mid-level promotion
- How you should process the advice from this course

Level Up Your Code Quality As A Software Engineer [Part 19] - Code Review Feedback

If you want to grow lightning fast as a software engineer, you need code quality feedback. This is the primary goal the entire "Pull Requests" section of this course is building up towards. This lesson will teach you:

- The algorithm for leveling up incredibly quickly as an engineer, especially for junior and mid-level engineers
- How NOT to respond to code review feedback
- How to gracefully respond to code review feedback to maximize your learning and deepen relationships with your teammates by going through an in-depth example

If you want to dive even deeper into code review, check out our masterclass: [\[Masterclass\] How To Do Amazing Code Review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/)

Maximizing a Severance Package 3/9 - Termination Circumstances

Let's talk about the different circumstances where you may need a package or to try and get a severance from a company.

- Connect with [**Ethan on LinkedIn**](https://www.linkedin.com/in/ethanevansvp/)
- Taro members get a discount to join [**Ethan's Level Up community**](https://levelupwithethanevans.substack.com/taro25)

The #1 Principle To Remember When Authoring A Code Review

In this video, we discuss the most important mindset shift for code authors: **writing code with empathy for reviewers**. Code review is a collaborative act, and how we prepare and present our diffs directly impacts team productivity, trust, and code quality.

### Key Takeaways:

- **We write diffs with empathy**: The most valuable thing we can do as authors is consider how to make the review experience smoother for others. Clear, concise diffs help teammates help us faster and more effectively.
- **We respect reviewers’ time**: Reviewers choose to help us—they’re not obligated. Reviewing interrupts their own deep work and requires mental context-switching, so we express appreciation by submitting clean, readable diffs.
- **We build trust and social capital through quality**: Writing thoughtful diffs with summaries and test plans helps us gain faster approvals and earns the trust of teammates and tech leads.
- **We know we’ll be reviewers too**: As we grow in our careers, we’ll spend more time reviewing others’ code. We want our teammates to be just as thoughtful when submitting their diffs to us.
- **We lead by example**: High-quality, empathetic diffs set the cultural tone for our team. We improve the entire engineering environment by holding ourselves to the same standards we hope to receive.

Why YOU Suck At Coding Interviews - From a Senior Engineer at Uber

[Edbert Chan](https://www.linkedin.com/in/edbert-chan-18a96950/) is a senior Android engineer at Uber. He wrote the popular guide “Welcome To The Coding Interview - You Suck” freely [available here](https://docs.google.com/document/u/1/d/1eKirumpmwDWTtKCJKn2HuoQ2NavEfR41whmTyaQcio4/mobilebasic) (and [here are the slides](https://docs.google.com/presentation/d/1vce04LepxDbu7K1ZyhtjVaSXC6Z0YYS9cAjNNztbEr4/edit#slide=id.p) presented).

If you want advice from Edbert, check out his AMA here: ["I'm Edbert, Ex-Apple current Uber Infra Android Engineer. AMA!"](https://www.jointaro.com/question/ftzODE689WYHw0FHGcl1/im-edbert-ex-apple-current-uber-infra-android-engineer-ama/)

This is a presentation about the common mistakes he has observed, and what you should do instead. Edbert believes that software engineers focus too much on the code and information during interview prep, and not enough on the engineering part of software **engineering**. Engineering is more than just coding, and a good interview process will be able to judge that.

The extensive guide is filled with practical tips for job seekers to pass the modern interview process at tech companies. Edbert covers the 9 mistakes that hold people back from passing technical interviews:

- Mistake 1: Not Putting Enough Time
- Mistake 2: Interview Approach Is Inconsistent
- Mistake 3: Your Interview Practicing Is Inconsistent
- Mistake 4: Not Fixing Your Own Mistakes
- Mistake 5: Not seeing how one decision or mistake leads to another
- Mistake 6: Not Understanding Your Own Solution Before Coding
- Mistake 7: Magic Bullets
- Mistake 8: Not Being Fast Enough
- Mistake 9: Being Full of Shit

Additional resources:

- [Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)
- [\[Taro Top 10\] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [\[Masterclass\] How To Ace Your Big Tech Interview - Data Structures And Algorithms](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/)
- [\[Masterclass\] How To Ace Your Big Tech Interview - System Design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/)

How To Be An Effective Tech Lead [Part 3] - What Makes A Good Tech Lead

Good tech leads provide immense value to their teams through a large collection of ways. This lesson teaches you:

- What it means from a technical skills perspective to be a good tech lead
- How good tech leads exercise effective leadership
- The mindset tech leads must champion

System Design Series: Taro Playlists [Part 5] - Data Model

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 concrete details are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

- Always define the data model if applicable. It is the "core operating unit" of your system - Everything revolves around it. That's pretty much what CRUD is: You have some data model and the entire ecosystem revolves around manipulating it properly.
- Define the table/collection(s):
  - What is its name?
  - What does it represent? If you can include a visual aide on how it's actually rendered for the user, that makes things a lot clearer.
- Define the fields on your model:
  - What is its name/key?
  - What is its type?
  - Is it required?
  - What does it represent? This should include information on what kind of key it is (e.g. primary key) if applicable.
- Illustrate the model to make it really clear. JSON is really good at doing this as it's very readable. There are many free incredible JSON formatters online (Alex used them all the time to make project specs).

Ace Your Tech Interview As A Software Engineer [Part 10] - Order Matters

We all want to speed run our way into FAANG. The bad news is that this is almost never pans out for software engineers, and aggressively pursuing this strategy can easily lead to your downfall. This lesson teaches you:

- The true way to actually get better at interviewing and why it can't be avoided (no matter how painful it is)
- How to properly structure your job search when Big Tech is one of your goals
- The general approach you should take when it comes to applying to jobs and sequencing your interviews

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.