Top System Design Interview Mistakes [Part 9] - Don't Draw Random Boxes

In this video, we discuss a common mistake in technical interviews: drawing random boxes without considering the bigger picture. Here are the key points we cover:

- Candidates often create isolated components without thinking about how they connect
- We provide an example contrasting a disorganized approach with a more thoughtful one
- Our recommended approach: Trace through data flows and user perspectives
- The goal is to think like an engineer: Identify the right problems before proposing solutions
- **Our main advice:** Don't just draw random boxes, trace data flow to uncover key system challenges

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>

Clear Communication For SWEs [Part 1] - Welcome And Course Overview

Hi everybody, I'm Ryan, and in this course, we'll cover the foundations of clear communication, practical exercises, advanced techniques, and how to adapt as a software engineer. By the end, you'll be equipped to communicate effectively within your team and with other builders. Expect to understand core elements of clear communication, develop a good communicator mindset, and master practical communication structures. Tailor your messages for different audiences and apply these techniques immediately. Join me on this journey to enhance your communication skills!

Connect with me on LinkedIn: <https://www.linkedin.com/in/ryan-wiens/>

Write A Stellar Resume As A Software Engineer [Part 10] - Fancy Formats

Creativity is great, and it's a very important skill for software engineers. However, the resume is not a medium for creativity to thrive. This lesson teaches you:

- Why "creative", fancy resume formats are really bad for a tech resume, shown through a very eccentric example
- The principles to follow for a great resume format
- What a resume with an optimal format looks like with a real-life example

If you need inspiration for your resume format, you can use Alex's template as a template. Download it here: [Alexander Chiou Resume.docx](https://docs.google.com/document/d/1NnAx2jYkRTMCQwbdDPPqSj1Fwxkahda-/edit?usp=sharing&ouid=109380646850979301783&rtpof=true&sd=true)

Write A Stellar Resume As A Software Engineer [Part 4] - 1 Resume To Rule Them All

Writing tons of different resumes is one of the easiest ways to waste time and overwhelm yourself on the software engineer job search. This lesson teaches you:

- Why you should only have 1 resume, especially if you're an earlier-in-career engineer
- Why "full-stack" engineer is often a trap for more junior engineers
- How to figure out the 1 resume you should write
- What to do if you really can't write just 1 resume (i.e. how to break the tie)

Grow From Mid-Level To Senior Engineer [Part 17] - Meetings

Every tech company needs a ton of meetings in order to function. The tricky thing is that a lot of software engineers are introverts, so they have trouble participating in meetings, especially when they're more junior. This lesson teaches you:

- The differences between junior, mid-level, and senior engineers when it comes to meeting presence
- The difference in types of meetings mid-level engineers participate in vs. those of senior engineers
- How meeting ownership shifts as engineers grow from mid-level to senior
- Tips to run an effective meeting which is an efficient use of time

To dive deeper into how to run a good meeting: ["What are some thoughts on maintaining good meeting hygiene?"](https://www.jointaro.com/question/CModSkZ4LWzw9bdaiakt/what-are-some-thoughts-on-maintaining-good-meeting-hygiene/)

Grow From Mid-Level To Senior Engineer [Part 3] - At A Glance: Mid-Level Vs. Senior

What exactly does it mean to be a mid-level engineer vs. a senior engineer? What's the gap? This lesson teaches you:

- What it means at a high-level to be a mid-level engineer vs. a senior engineer
- The types of projects mid-level engineers work on vs. a senior engineer
- The ownership and scope difference between a mid-level engineer vs. a senior engineer
- The difference in organizational complexity between mid-level engineers and senior engineers

Master The Behavioral Interview [Part 12] - Double Dip

Software engineers and people in general don't realize how incredibly powerful questions can be when you ask the right ones. This lesson teaches you:

- How the best questions that you can ask in a behavioral interview actually help you pass on top of extracting useful team selection information
- What the 2 core failure modes are when it comes to you asking the interviewer questions

How To Influence Your Team Without Authority

Huge thanks to [Ryan Kuck](https://www.linkedin.com/in/ryan-kuck/) for leading this session!

Have you had amazing idea with clear data to support it, but it was rejected? In this event we will talk about why that might have happened, and suggest alternate strategies for next time.

Spoiler alert: We use computers to reach millions/billions of users, but we are very different from computers ourselves. Presenting the best data to another person can actually backfire, unless it is coming from a place of shared goals/values and trust. It isn’t logical, but it is human nature. If you explain a better idea than I presented, and you even have rock solid evidence, I no longer am thinking about the user or our business impact but rather about how I just don’t want to “be wrong”.

Come to this event with your stories of challenges and successes of influencing your engineering team!

To dive deeper, check out these resources:

- [**"How do I lead without authority?"**](https://www.jointaro.com/question/BWv3hFSELbn59mXJbkNB/how-do-i-lead-without-authority/)
- [**\[Course\] Effective Communication For Engineers**](https://www.jointaro.com/course/effective-communication-for-engineers/)

Nail Your Promotion As A Software Engineer [Part 19] - Depth Of Contribution

Just because you got a meaty, high-impact project doesn't necessarily mean that you'll get rewarded a lot for it when it comes to your promotion case. This lesson teaches you:

- Why volume of code contribution often doesn't correlate with the depth of your contribution and the credit you receive
- How to figure out if your project contributions had lots of depth
- Concrete examples of hard tasks that have great depth and are greatly rewarded for in promotion cases

Ace Your Tech Interview As A Software Engineer [Part 7] - Stronger Together

The software engineer job search is extremely exhausting. We now know that grit is the most important trait for interview success, but it's hard getting there purely on your own. This lesson teaches you:

- The big difference between knowing something and applying something
- Why finding an accountability partner is crucial for learning and making genuine progress
- A very basic (but powerful) framework you can go through with your accountability partner to push one another to greater and greater heights on a consistent basis

Level Up Your Code Quality As A Software Engineer [Part 23] - Everything In 1 Place

Monoliths and god-classes are 2 of the most common code anti-patterns, especially in Big Tech. They're extremely easy to fall into, and monolithic infrastructure is actually the right call for the vast majority of software as 99% of software is nowhere near the scale of FAANG. This lesson will teach you:

- Why the "Everything In 1 Place" anti-pattern is so damaging, not just for readability but developer productivity as well
- One of the most powerful clean code techniques: **The delegate pattern** (this is how Meta referred to it). It can go by other names, but the core concept is to understand how an interface works. Once you master this pattern, you'll be able to break up any large codebase into readable, focused, modular components. Delegates were easily the most commonly used clean code pattern back during Alex's time at Instagram. Alex goes through an in-depth example from the Taro app itself to walk you through exactly how this technique works.

If you want to learn more about Instagram's stellar engineering culture around code quality, check out this in-depth discussion: ["What do mobile testing strategies look like at top tech companies?"](https://www.jointaro.com/question/fpySzIO02aQ0sCz5N6dP/what-do-mobile-testing-strategies-look-like-at-top-tech-companies/)

Level Up Your Code Quality As A Software Engineer [Part 20] - Code Comment Caches

Code comments can be immensely helpful, but they can be incredibly damaging to a codebase if used incorrectly (which this course will cover even more later on down the line). This lesson will teach you:

- Why engineers will try the very weird "code comment cache" anti-pattern
- The importance of Git, GitHub, and version control platforms in general
- How to not be lazy and properly deal with code that isn't necessary now but may be useful later

Principal Engineer (L8) Describes Most Important Skill - Pong Eksombatchai

Pong is a Principal Engineer at Pinterest.

- **Most important skill**: technical communication. As a Principal Engineer, you can't have sufficient impact on your own. Effective technical communication enables you to work through others and advise other teams on the recommended technical path. 
- **Advice**: model the behavior and culture you want. A Principal Engineer is, by default, a role model for the team and org, so their actions set the tone.

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/)
- [Pong on LinkedIn](https://www.linkedin.com/in/chantat-eksombatchai-268142b8/ )

[Case Study] How to Quit Your Job The Right Way (w/ ex-Netflix TL Michael Lin)

[Michael](https://www.jointaro.com/profile/Ab2xedZA7RhROW0wo9wBHIJbAsX2/) famously [quit his $450,000 job at Netflix](https://www.jointaro.com/blog/why-i-quit-a-450k-engineering-job-at-netflix/), and asked for (and received) a severance package in the process! If you're thinking about quitting your job, consider these points **before** leaving: 

### Timing is important
- It’s better to leave on the 1st of the month than the 31st because employee benefits renew on a monthly basis.
- If you leave on the 1st, it’s like getting a full extra month of benefits. 
- But if you leave on the 31st, your benefits may end the next day.

### Quitting is a trade-off
- You’re weighing that the negatives of staying outweigh the negatives of losing out on income.
- If you have to cut vacations, move away from loved ones, and say no to social events, then those negatives may outweigh the negatives of your job.

### Act with urgency
- If your career is not going the right way, take action quickly.
- If you stay an extra two years at a job you wanted to leave and did this over five jobs in your lifetime, that’s ten years of your life spent doing work you never wanted to do.

---------
- Connect with Michael on [LinkedIn](https://www.linkedin.com/in/michael-lin-tech/)
- Subscribe to [Michael's newsletter](https://michaellin.substack.com/)

Related questions: 
- ["Should I request a voluntary layoff to my manager?"](https://www.jointaro.com/question/FnInc1bJ3AUJBz0grFyj/should-i-request-a-voluntary-layoff-to-my-manager/)
- ["Should I quit to prep for interviews?"](https://www.jointaro.com/question/Cno3oaZkvUu7BPLhHB7g/should-i-quit-to-prep-for-interviews/) from a Data Engineer

[Part 2] Software Engineer Onboarding: Learn the Workflow

To make the hard work easier, learn the workflow and process first.

**A big mistake new engineers make**: they dive in directly to a project and start landing code/landing impact. You goal is be curious about the testing and deployment procedures, along with the workflows and processes. One way to do this is to deliberately pick the simplest possible bugs and code changes to make, so you can exercise the workflow. 

- [Use Code Review Feedback For Hypergrowth](https://www.jointaro.com/lesson/aBRgdYpUfnUpoyWG4qZC/use-code-review-feedback-for-hypergrowth-meta-prodigy-engineer-story/)
- [How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/how-to-write-better-code-faster-as-a-software-engineer-11192022/)

This is part 2 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 3 of the masterclass here](https://www.jointaro.com/lesson/7l4Nr4hQf8Pv8zfGZwh4/part-3-software-engineer-onboarding-understand-tactical-decisions/)
- [Go back to part 1 of the masterclass here.](https://www.jointaro.com/lesson/IYZRmwp33E3TBeFQFr9c/part-1-software-engineer-onboarding-embrace-your-lack-of-knowledge/)

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.

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.