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

The Biggest Benefit Of Working At Big Tech - Learning Proper Engineering Skills

We all know how powerful Big Tech is when it comes to its top-of-market compensation and resume power. However, there is a much bigger long-term benefit these prestigious companies have when it comes to software engineers.

Here are the core points from the video:
- **Big Tech is stellar at teaching proper engineering** - You simply can't reach 100 million+ users without being great at software engineering. These companies have the experience and history to show software engineers how things should be done.
- **You will be pushed to be better** - Big Tech invests billions in hiring the absolute best tech talent in the world. In order to ship quality products at scale, these engineers push each other constantly to do the right thing. When you work at Big Tech, you become a part of this process and peer pressure.
- Here are just some of the ways this learning manifests:
  - Thorough release process with staged rollout and deep analytics
  - Code review where you get tons of comments on how to improve
  - Great internal tooling showing you what parts of the engineering experience can be made seamless

Related resources:
- ["How do I get better at building Large scale systems without working directly on such projects?"](https://www.jointaro.com/question/k9MR0UBCtVXvyZrOdPLw/how-do-i-get-better-at-building-large-scale-systems-without-working-directly-on-such-projects/)
- ["How to Learn/Practice Clean Code, particularly by oneself?"](https://www.jointaro.com/question/6DcTkiS9UJhDkQz1HIAL/how-to-learnpractice-clean-code-particularly-by-oneself/)
- ["What are the best resources to learn system design in a structured way?"](https://www.jointaro.com/question/SeCsb4IRTijs2hg4XHxo/what-are-the-best-resources-to-learn-system-design-in-a-structured-way/)

Master The Behavioral Interview [Part 19] - Cultural Values

Culture fit is real. A lot of tech companies have toxic culture and don't vet for it properly, but that doesn't change the fact that culture fit is extremely important to running a healthy engineering organization. This lesson teaches you:

- Why cultural values are important
- What you should do to effectively study and internalize the cultural values of a company you are interviewing with
- How to weave a company's cultural values into your behavioral interview answers through an example with Alex for his Meta interview

If you're curious as to how Meta's engineering culture works: ["Is sprint planning and agile not a thing at Meta?"](https://www.jointaro.com/question/tB7borE2AWb1KcuFEcon/is-sprint-planning-and-agile-not-a-thing-at-meta/)

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

How To Know If You’re Doing Well

Your goal while onboarding is to connect your work to the bigger picture of what your team/org/company is working on, and build your own ideas around priorities.

**Signs that you're helping people**:

- Are you adding value? Are you able to help people newer than you?

- Are you able to improve the onboarding process and get feedback from coworkers about the changes you're making?

- Are you able to understand and contribute to code reviews?

**Signs that you're not doing well**: 

- You're not engaging with people on the team
- You're not getting assigned any work of value, even when you propose ideas
- You need constant support for the work you're doing

Maximizing a Severance Package 5/9 - Preparing Your Case

Let's talk about how to prepare your case to maximize your severance package.

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

Ace Your Tech Interview As A Software Engineer [Part 24] - System Design

System design is another common interview type, particularly among Big Tech companies. Unlike the notorious data structures and algorithms, system design is something you actually do on the job. This lesson teaches you:

- When to expect system design rounds during the interview loop
- What kinds of engineers get system design questions
- What you should be doing when getting a system design question
- What a proper system design diagram looks like

To master the system design interview, check out these resources:

- [\[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/)
- [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)
- [\[Taro Top 10\] System Design](https://www.jointaro.com/playlist/MFc9JT0tZSmOwbuKC2C7/)

Grow From Senior To Staff Engineer [Part 15] - Why Have Archetypes?

Growing from junior (L3) to senior (L5) is largely foundational. This stops being the case when you get to staff. This lesson teaches you:

- What staff engineer archetypes are and how they help conceptualize the path to staff
- How to quickly and easily understand what each staff engineer archetype does
- A framework you can use to learn from the staff engineers in your team, particularly with what archetype they embody

Learn more about Talk & Observe: 

- Rahul's dedicated YouTube video: <https://www.youtube.com/watch?v=VV0nvusnqT4> 
- From the onboarding course: <https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/the-talk-and-observe-framework/>

Master The Behavioral Interview [Part 25] - Go Deeper: Follow Through

To find events like mock interview meetups: <https://www.jointaro.com/events/>

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

Start a discussion in the Taro Forum and get incredible career advice: <https://www.jointaro.com/questions/create/>

Go through case studies by level to understand the expectations at each one: [\[Taro Top 10\] Understanding Engineering Levels](https://www.jointaro.com/playlist/e9rjATPbSyvRPsukXiHn/)

Take these courses as well:

- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [\[Course\] Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)

**UPDATE:** We have shut down Taro Networking as a feature. Sorry for the inconvenience 🙏

Nail Your Promotion As A Software Engineer [Part 17] - Technical Complexity

In order to get promoted, especially to senior levels and beyond, you need to work on technically complex problems. But here's the tricky party: How can you as a software engineer determine if a problem has enough technical complexity? This lesson teaches you:

- A simple framework to determine the technical complexity of a task
- The classic system design principal of *"Dumb client, smart server"* and how it relates to technical complexity
- How product and infra teams differ when it comes to their scope and how it affects promotion

The Hardest Part Of Peer Feedback: Giving Them Constructive Criticism

- When the feedback prompt asks you for what your peer can improve on, it is *not* asking you what your peer is doing poorly. If you see your peer doing something toxic/negative, you should give them that feedback *immediately*. Don't wait 6-12 months until performance review season to drop this giant ball on them.
- The *real* question behind this prompt is: "How can your peer expand their scope?". This often times involves something they're already doing well that they can do even better and expand to achieve even greater impact.
- This question will be much easier to answer once you have a deep understanding of engineer levels as a lot of this feedback will be around what you think your peers can do to reach the next level.
- Example: Your peer is very passionate about automated testing and always pairs their landed code with robust test coverage. You suggest that they push to spread this behavior across the entire team with an overall testing initiative.

Rack Up Small Wins

A promising sign for a new employee is if they can have a quick win, no matter how small. This means you want to avoid ambiguous or complex projects.

Ideas for quick wins:

- Share something your learned
- Update docs and tell people about it (not to brag, but to invite feedback)
- Improve wikis by adding screenshots: e.g. a screenshot or video of the setup flow
- Fix a "papercut," e.g. a misspelling in the code or a minor bug

Notice that many of the ideas above don't even involve committing code!

Talk link: [Don't Walk Away from Complexity, Run! (Venkat Subramaniam)](https://www.youtube.com/watch?v=d6CYdTOLW8I)

System Design Series: Taro Playlists [Part 7] - How Can Things REALLY Break?

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

- You should *always* think about "How can we cause a SEV?" when you're planning out system design for any substantial project or task.
  - **Context:** SEV = Severity, which is the term Meta, Robinhood, and many other companies use to describe a really bad product event.
  - This is one of the purest and most critical manifestations of proactive thinking, which is one of the trademark attributes of a competent senior+ engineer and tech lead. SEVs are events that seriously set back your organization or even your entire company if they're something you have to react to as opposed to catching them early.
- This "anti-SEV" thinking is *especially* relevant for Big Tech where the stakes are much holder due to regulatory constraints, increased media presence, and a massive scale of users.
  - It's also far harder to do this well at Big Tech due to a greater range of ways things can break.
  - However, if you can do this well, you will add a tremendous amount of value to your team. This is why pretty much all senior and staff engineers at FAANG and FAANG-equivalent companies have really developed this skill.
- Here are the ways a SEV can happen from the video (these are all vectors Alex dealt with at Meta as well):
  - **Users not playing nice** - You should never assume that users will put in proper inputs or even not want to harm other users. Most major tech products have some sort of multiplayer component, so it's important to be vigilant here.
  - **Bad auth context** - This means that users are able to carry out actions on behalf of other users. This can happen either intentionally (i.e. the acting user is malicious) or accidentally (e.g. the user has multiple accounts on your service and switching between them cleanly is broken).
  - **Incorrect backporting** - "Backporting" is the process of making things work on older builds of your software. This is *very* relevant for mobile engineers as there will always be a good amount of users on older builds, especially if your product is used by people in regions with lower internet.

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 going through the system design process at your job!

Become An Engineer Influencer [Part 1] - What Is An Engineer Influencer?

An engineer influencer is an engineer who builds an audience on social media and uses that to kickstart their future startup or business.

Examples include:

- [Rahul Pandey](https://www.youtube.com/c/RahulPandeyrkp) - ex-Meta engineer, who leveraged his 60k followers on YouTube to launch Taro, a career-mentoring app that got into YCombinator

- [Gergely Orosz](https://twitter.com/GergelyOrosz) - ex-Uber engineering manager, who used his Twitter following to grow his paid newsletter "The Pragmatic Engineer" to 140k readers in 18 months

- [Daniel Vassallo](https://twitter.com/dvassallo) - ex-Amazon engineer, who grew his following to 130k followers on Twitter and now teaches a highly successful cohort based class called "Portfolio of Small Bets"

Each of these engineer influencers focused on building their social media following first.

This helped them build credibility, expand their network, and guarantee them a distribution channel for their future product.

Connect with Michael:

- LinkedIn: <https://www.linkedin.com/in/michael-lin-tech/>
- Twitter: [https://x.com/\_michaellin](https://x.com/%5C_michaellin)
- Newsletter: <https://www.michaellinwrites.com/>

Effective Communication Guide [Part 6] - Communicating In A Remote World

- What is lost in a remote work environment when it comes to communication?
  - **Volume:** A lot of ad-hoc communication ("water cooler chats") can't happen anymore.
  - **Depth of presence:** When you're on a video call, it's mainly just your face that's visible. In an in-person meeting, especially 1 on 1 meetings, your entire body is visible, which lets you express a lot more via your body language.
- **If you're comfortable, have video on during calls** - Use your facial expressions to really show that you're listening and truly hearing what the other person or people have to say.
- **Book 1 on 1s very aggressively** - 1 on 1 meetings are the core building block behind strong relationships. In an in-person environment, you will build relationships naturally through other means like team lunch, but since those are lost in a remote environment, you need to lean on 1 on 1s far more.
- **Get really good at technical writing** - In a remote world, especially with teams distributed across multiple time zones, a lot more communication has to happen asynchronously.
  - Project updates are very important in particular. It's much harder to stay aligned when everyone is apart.
  - If you aren't already, try to write a project update for your work every 2 weeks or more.

DSA Crash Course [Part 15] - Pair Product Walkthrough

In this lesson, Alvin walks through the python implementation for the *pair_product* problem.

Code along and test your work in the following editor workspace: <https://structy.net/problems/pair-product?language=py>

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

How to Crack System Design Interviews - Part 3: Building The Basic Design

After gathering requirements, we move on to creating a basic design for the system. This allows for flexibility and gives the interviewer insight into our strengths and areas for growth. Here's how we approach this stage:

- **Request-driven design:** We let the flow of requests through the system guide our design choices, identifying necessary components and databases along the way.
- **Leverage existing technologies:** We utilize familiar technologies and design patterns, treating them as black boxes that can be explored further if the interviewer wishes.
- **Maintain a balanced level of detail:** We provide a high-level design without being too vague, mentioning specific technologies and protocols where appropriate.
- **Expose relevant APIs:** We identify the necessary APIs for the system and consider whether multiple services and databases are needed.
- **Offer multiple options:** We demonstrate our understanding of trade-offs by suggesting multiple technologies or protocols and discussing their potential benefits and drawbacks.

[Gaurav Sen](https://www.linkedin.com/in/gkcs/) has conducted 1000s of system design interviews while working at Uber and building his [YouTube channel](https://www.youtube.com/@gkcs) to 500K+ subscribers. His platform [InterviewReady](https://interviewready.io/?_aff=JOINTARO) combines video explainers, live Zoom classes, and an automated System Design Judge.

Level Up Your Code Quality As A Software Engineer [Part 17] - Share The Context

Software engineers often have this flaw where they assume that everyone somehow automatically knows what they're doing and the nuances of the spare they're operating within. This often extends to their published pull requests. This lesson will teach you:

- The ingredients behind a high-quality context section on a pull request
- A simple tactic to greatly expedite your pull requests, build respect amongst your team, and get better feedback (hint: It's not just your teammates who can review your code)
- Exactly what a stellar context section looks like with an incredibly detailed, broken down example. This is a trademark sign of high-performing mid-level and senior software engineers

Truly Mastering A Data Structures And Algorithms Problem  - 2 Sum Example

Why is the following not a good way to remember the solution to 2 Sum?
        
def twoSum(self, nums, target):
    required = {}
    for i in range(len(nums)):
        if target - nums[i] in required:
            return [required[target - nums[i]],i]
        else:
            required[nums[i]] = i

Why is [Look for the difference and use a HashSet] a great way to remember the solution to 2 Sum?

What more general higher-level learning principle is also exercised alongside the proper mastery of data structures and algorithms problems?

Data structures and algorithms are a core part of FAANG software engineer interviews, and they're seemingly the bane of every software engineer's existence. However, so many software engineers don't learn these concepts properly.

Here are the core points from the video:
- In this example, we cover 2 sum, a classic data structures and algorithms problem that many companies use on phone screens. Here's how to learn it properly:
  - **Bad:** Memorizing all the code behind the optimal implementation.
  - **Good:** "Look for the difference and use a HashSet."
- All DSA problems will have this core insight that "unravels" the entire thing. Once you find and truly understand this insight, the implementation should flow naturally.
- This is also a sign of higher learning via "thinking in terms of abstractions". Your brain is a lot more powerful if it is able to take something more singular and high-level and convert it into the nitty gritty. Memorizing everything at the lowest level simply isn't scalable.

Related resources:
- [[Masterclass] How To Ace Your Big Tech Interview - Data Structures & Algorithms](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/how-to-ace-your-big-tech-interview-data-structures-and-algorithms-7172021/) - This is the full video this clip is taken from
- [[Masterclass] How To Ace Your Big Tech Interview - System Design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/how-to-ace-your-big-tech-interview-system-design-1162021/)
- [How Alex Got Into Meta With 0 Prior Leetcode Experience](https://www.jointaro.com/lesson/ZYiTbN21FsqFxFdpwt5a/how-alex-got-into-meta-with-0-prior-leetcode-experience/)

How to Crack System Design Interviews - Part 6: Mock Interview

This video demonstrates a system design interview for analyzing Snapchat filter usage. We are tasked with designing a system to track and analyze filter usage data for executives and product managers. Here's what we do:

- **Gather requirements:** We clarify the scope of the system, including the number of filters, their dynamic nature, and the desired metrics (daily, weekly, monthly usage, and potentially hourly breakdowns).

- **Design the system:** We propose a write-heavy system with separate read and write paths to optimize performance. The write path handles incoming events from users, while the read path aggregates and transforms data for querying.

- **Consider scalability:** We discuss sharding and using a write-optimized database like Cassandra to handle the high volume of incoming events.

- **Address data aggregation:** We explore using Apache Spark to process and aggregate data based on time and user demographics, storing the results in a database like DynamoDB.

- **Differentiate query types:** We propose separate APIs for common, pre-aggregated queries and custom queries, acknowledging the potential latency differences between the two.

[Gaurav Sen](https://www.linkedin.com/in/gkcs/) has conducted 1000s of system design interviews while working at Uber and building his [YouTube channel](https://www.youtube.com/@gkcs) to 500K+ subscribers. His platform [InterviewReady](https://interviewready.io/?_aff=JOINTARO) combines video explainers, live Zoom classes, and an automated System Design Judge.

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.