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.

Make Sure To Set This Up With Your Manager To Ace Your Performance Review

- Work with your manager to figure out which peers you should request feedback from at the end of the cycle: They may already have a bunch of peers in mind!
- Once you figure out these key peers, talk with them upfront about your goals, especially if they're ambitious and you're gunning for promotion. Work with them early to build this relationship, especially if they're more senior.

[Part 3] Meta Intern Success Series - Onboarding Efficiently

- Onboarding is arguably the most important part of your internship as it sets the foundation and tone for your entire software engineer internship.
- Set up a 30 to 45 minute meeting with your intern manager (IM) ASAP, so they can explain the codebase to you at a high-level (i.e. a component level).
- Make sure you have a recurring 1:1 meeting with your IM, which should be a weekly 30 minutes. Your IM should set this up for you, but in case they don't, you can work with them to set it up.
- You will get 2-5 onboarding tasks to work on across the first ~2 weeks. The purpose of these is to familiarize yourself with the codebase.
- Aim to put out your 1st diff by the end of Week 1. If you're doing this around the end of Week 2, you're really behind.
- Ask a ton of questions and learn to ask high-quality questions. Don't be afraid of "over-asking" questions: If you're polite while asking questions and attaching great context to them, you will be fine no matter how many questions you ask.
- Use Work Chat DMs to ask for help aggressively during this period as it's vital for you to become productive within the codebase very quickly

Related resources:
- [Asking Effective Questions That Get Great Answers Quickly](https://link.jointaro.com/E8eaKmMpZcKWNGkbA)
- ["How can I learn a large codebase fast as an intern?"](https://link.jointaro.com/L8tXjWah6ycdNpNf7)
- [There Is No Such Thing As A Stupid Question](https://link.jointaro.com/F4p3fL4eHqp5GXti7)

The Engineering Manager "Partner In Crime": The Tech Lead

This video explains the essential partnership between an engineering manager and a tech lead in high-performing engineering teams. It emphasizes how effective delegation, complementary strengths, and role clarity between the two can drive both team productivity and individual growth.

- **Strong engineering managers have a “partner in crime” tech lead**: Effective managers often work alongside tech leads who handle the majority of technical responsibilities, allowing the manager to focus on team support, operations, and growth.
- **Clear level pairing by role**: At Facebook, there’s often a leveling alignment—e.g., M0 managers paired with L5 (senior) engineers, M1s with staff (L6), and M2s with senior staff (L7)—ensuring balanced responsibility and decision-making.
- **EMs stay hands-off but connected**: Engineering managers are expected to stay informed on technical topics but are not expected to be hands-on with code or architecture decisions.
- **Tech leads drive technical execution**: Responsibilities like leading engineering meetings, driving design reviews, setting development processes, and ensuring engineering culture are primarily handled by the tech lead.
- **Shared mentorship responsibility**: While managers typically mentor through one-on-ones, tech leads also provide mentorship, especially for junior and mid-level engineers. This dual support system ensures continuity and growth even when the manager is unavailable.

Your Great Engineering Manager Will Eventually Leave You 🥺

Even when a highly capable and supportive engineering manager is found, the relationship often has a built-in expiration date. This video explains why strong EMs tend to move up quickly and what that means for their reports. Here are the core points from the lesson:

- **Great EMs focus on long-term growth**: A strong manager prioritizes their engineers' success, fostering an environment that supports both team and individual development.
- **Fast career growth is common for top EMs**: Exceptional managers are often promoted quickly, typically within 1–2 years, due to their high impact and leadership abilities.
- **Promotion changes reporting structure**: When promoted to senior engineering manager, EMs typically move from directly managing engineers to managing other managers, altering team dynamics.
- **ICs often lose direct access**: Most engineers will start reporting to a new manager, while their original EM becomes a “skip-level” manager—only senior ICs may continue reporting directly.
- **Disruption of strong relationships**: The transition can be disheartening for ICs who thrived under the original EM, especially when that connection was key to their growth.

Performance Bonus Explainer With Meta Senior Software Engineer [E5] Example

This video breaks down how **performance bonuses** work in the tech industry, focusing on their structure, key variables, and real-world examples—especially from companies like Facebook. It underscores how these bonuses are a significant portion of total compensation and are both performance- and timing-sensitive.

- **Performance bonuses are calculated using a base percentage** tied to level and salary, and then adjusted by two multipliers: individual performance and company performance.
- **Company performance multipliers vary**, often based on metrics like revenue or stock performance. For example, Facebook’s company multiplier was 90% in late 2017, despite its historically strong track record.
- **Individual performance multipliers** reflect how well someone met expectations (e.g., "meets all" equates to 100%), and strongly influence the final bonus amount.
- **Bonuses are only paid if still employed at payout time**, meaning even working a full half-year won't earn a payout if the person leaves before the bonus distribution date.
- **Payout examples help contextualize the numbers**: a senior engineer at Facebook with $62K eligible earnings, a 15% target bonus, and multipliers of 1.0 (personal) and 0.9 (company) would receive about $8,300—paid out roughly two months after the performance period ends.

Becoming A Legendary Meta Coder: The Story of the First E7 Code Machine

There are many complex ways [**to get to staff and beyond**](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/why-have-archetypes/), but one of them is actually quite straightforward (at least at Meta): *Just write more code than everyone else by a **staggering** amount.*

That's exactly what [**Michael Novati**](https://www.linkedin.com/in/michaelnovati/) did to get to Staff \[E6\] at Meta and eventually Senior Staff \[E7\]. Since Michael was early Facebook, there actually wasn't a Staff Engineer archetype at the time to capture the way he was adding immense value to the company. So they added it! Thanks to Michael, there is now a formal "Code Machine" archetype in the official Meta internal wiki.

Michael will be breaking down:

- His story about how he became Meta's first incredibly senior "Code Machine" engineer
- The most impactful projects he worked on
- How he managed his time effectively to write so many diffs.

At the end, we'll have time for Q&A where you can ask Michael questions about topics like:

- How he grew so quickly and crafted such an extraordinary career
- What the early days at Meta were like
- Different ways to create a unique brand for yourself, your work, and your career

If you need extra help breaking into top tech companies like FAANG, [**Formation.dev**](http://Formation.dev) is here to provide you hands-on, personalized support. Join Michael and the rest of the awesome team at Formation here: [**https://formation.dev/partners/taro**](https://formation.dev/partners/taro)

20 Years Of Fighting Procrastination [Part 7] - Just One Thing

Become A Debugging Master [Part 4] - Where To Find Bugs

Finding and fixing bugs proactively is one of the most underrated ways to accelerate your growth as an engineer. Here are the core points from the lesson:

- Great engineers don’t wait for bugs to be assigned—they actively hunt for them through QA reports, user feedback, crash logs, dashboards, and on-call alerts
- Proactively surfacing and solving bugs builds trust, reduces last-minute surprises, and makes you a more reliable and promotable team member
- Attending SEV (severe incident) reviews, learning from outages, and applying those lessons is a major career hack for fast growth
- Engineers can approach bugs at different levels of ownership, from simply reporting them to fully owning the investigation, fix, and communication
- Creating scope by finding and fixing high-priority bugs—even without being asked—can dramatically accelerate your career trajectory and reputation

Build Deep Relationships Quickly In Tech [Part 3] - The #1 Rule Of Networking

Many engineers struggle with networking as they don't fundamentally understand how it's supposed to work. This lesson teaches you:

- The #1 rule of networking and how not following it completely messes up your social circle
- A very tactical, mathematical framework from which to view networking
- How giving more than you take creates an infinite amount of value
- Why you're not a "loser" for being benevolent and kind
- The pain and toxicity of being in a fake network, which many engineers are a part of
- The powerful benefits of being in a true network

Come Up With 500k+ User Project Ideas [Part 3] - The Key To A Great Project Idea

Most engineer resume projects are half-baked school projects or wrappers around basic tutorials, lacking the necessary continuity to be impressive and get users. This lesson teaches you:

- The #1 cause of death with engineer side projects
- The key that every good side project idea needs to even have a chance of being successful
- What it means for a side project idea to satisfy that key, explained with a concrete example showing the inspiration behind Alex's Random Name Picker app, which has over 1.1 million users

DSA Crash Course [Part 87] - Outro

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

Master The DSA Interview [Part 27] - How FAANG DSA Rounds Work

A big part of being prepared for a data structures and algorithms interviews is having a clear general idea of what problems are going to be asked. This lesson teaches you:

- What LeetCode problem difficulties mean
- What kinds of data structures and algorithms questions are asked in FAANG phone screen (screening) interviews
- What kinds of data structures and algorithms questions are asked in FAANG onsite (final round) interviews
- The common trap you must avoid when preparing for FAANG data structures and algorithms interviews, depending on where you are within the interview process

Master The DSA Interview [Part 7] - Regularly Be Talking

There is far more to a data structures and algorithms question than simply being able to code up a solution. This lesson teaches you:

- Why consistent communication is critical for data structures and algorithms interviews, especially at top companies
- How much silence is too much in an data structures and algorithms interview
- How bad vs. good engineers solve technical problems in general

Top System Design Interview Mistakes [Part 13] - Identifying Key Issues

In the final segment of the system design series, we focus on the importance of driving the design of your system during interviews. In this video, we cover how to identify key issues. Here's the video's core points:

- Avoid following a rigid structure. For example, don't just jump into a data model or architectural diagram without considering the unique requirements of the system you're designing, such as group messaging dynamics
- Actively ask clarifying questions to understand the requirements better. This helps in identifying and addressing key issues specific to the problem, rather than sticking to a generic approach
- Tailor your approach based on the specifics of the problem. If dealing with a unique system, like a group messaging app, adapt your design to handle unique challenges, such as managing multiple notifications from a single message
- Lead the discussion by probing into requirements and challenges. This ensures that your design addresses the most critical aspects of the problem

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>

[Become A Go-To Person 2/18] What Industry Experts Say

A course by [Jordan Cutler](https://www.linkedin.com/in/jordancutler1/), Senior Software Engineer at Pinterest and Author of the [High Growth Engineer Newsletter](https://read.highgrowthengineer.com/)

Maximize Your Productivity As A Software Engineer [Part 23] - It's A Never Ending Marathon

With the meteoric rise of the Internet, software engineers are constantly bombarded by magical success stories where other engineers rose almost instantly to the top. However, reality is rarely that smooth and simple. This lesson teaches you:

- What successful career paths actually look like, even among the world's best engineers
- How productivity naturally trends across your life
- What to do when you're facing a serious lack of productivity that seems unfixable

[Timeless Career Advice] Intro & Agenda

Over the last decade, I grew from an Individual Contributor Software Engineer to a Senior Director running multiple engineering teams at a Fortune 1 Company.\
\
My teams and I built Tech for a business unit with over $35 Billion in annual revenue.\
\
Before this, I was an early employee at a Startup, and I built eCommerce, personalization, and growth marketing tech that helped us go from 0 revenue to over a billion in sales in 1 year. Then that startup ([Jet.com](http://Jet.com)) got acquired for $3.3 Billion.

**This is the 1:1 with your Engineering Manager you should've had**.

Connect with Louie:

- SmallBets community: [**https://smallbets.com/?utm_source=taro**](https://smallbets.com/?utm_source=taro)
- Newsletter: [**https://newsletter.memesmotivations.com/**](https://newsletter.memesmotivations.com/)

Grow From Mid-Level To Senior Engineer [Part 22] - Instagram Ads Survey Cleanup Workstream

See something, say something: You'll be surprised at how much opportunity you can find by championing this mentality, including to senior levels. This lesson goes through:

- The weird organizational dynamic that led to a bunch of senior scope existing "for free" but easy to ignore as a junior or mid-level engineer
- The simple but powerful trick Alex used to turn several smaller issues into a senior-level project
- How Alex continued to deepen the impact of this survey cleanup workstream by digging deeper and doing the right thing
- The learnings from this case study that you can apply to your day-to-day to find senior scope

Grow From Mid-Level To Senior Engineer [Part 21] - Instagram Ads Testing Tool

Sometimes being a little selfish can help you tremendously when finding senior scope as it did in this case study. This lesson goes through:

- The problem Alex was solving with Instagram ads internal testing, particularly with mobile engineers
- How Alex came up with a very simple solution to the testing problem (far simpler than senior engineer technical complexity)
- How Alex scaled both himself and his basic Instagram ads testing tool
- The learnings from this case study that you can apply to your own day-to-day at work to find senior scope

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.