15 SWE Years In 1.5 Hours [Part 10] - Data Structures And Algorithms

Because of Google, we all need to live in a LeetCode reality. Data structures and algorithms (DSA) are something we all love to hate, but at the end of the day, you need to master them to land a job at the world's leading tech companies. This lesson teaches you:

- Why grinding DSA is 100% worth it
- How the learning curve for DSA works (and why you shouldn't get discouraged)
- How to learn DSA properly
- The best tool to get for DSA prep
- What to do when you get stuck on a data structures and algorithms problem

To dive deeper into data structures and algorithms, follow our learning path here: [Crack The Data Structures And Algorithms Interview](https://www.jointaro.com/learning-paths/crack-the-data-structures-and-algorithms-interview/)

Becoming A Staff Engineer In Big Tech (Panel Discussion)

The journey to Staff Engineer is unique for everybody. Let’s talk about all the ways we got there! Senior Engineer is a terminal level at most tech companies.

Staff Engineer is the next level up. This is referred to as Staff at Meta/Google, or Principal Engineer at Amazon/Microsoft. ([Rahul's promotion story](https://www.jointaro.com/lesson/qvp2quodqAEWSkN7sayt/case-study-building-a-meta-internal-tool-to-empower-an-entire-org-staff-promotion-story/).)

Partial list of questions discussed:

- How do you know which problems are worth solving?
- How do you communicate to your manager that you want Staff promo? And what do you look for in a manager?
- What type of teams do you think best support growth into the Staff level?

Panelists:

- [**Zach Wilson** - Airbnb](https://www.linkedin.com/in/eczachly/)
- [**Rahul Pandey - Meta**](https://www.linkedin.com/in/rpandey1234/)
- [**Carly Taylor - Activision**](https://www.linkedin.com/in/carly-taylor-data/)
- [**Lee McKeeman - Google**](https://www.linkedin.com/in/lmckeeman/)
- [**Ryan Peterman - Meta**](https://www.linkedin.com/in/ryanlpeterman/)

See discussions about Staff Engineers on Taro: <https://www.jointaro.com/topic/staff-engineer/>

Watch the full [Senior to Staff course on Taro](https://www.jointaro.com/lesson/NE3J4vWP7BoWlNgbRtCw/becoming-a-staff-engineer-in-big-tech-panel-discussion/).

Grow From Mid-Level To Senior Engineer [Part 24] - Go Deeper: Follow Through

Start a career discussion in Taro: <https://www.jointaro.com/questions/create/>

Join Taro events: <https://www.jointaro.com/events/>

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

Related courses:

- [Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)
- [Managing Up: Build Effective Relationships With Your Boss](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/)
- [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

DSA Crash Course [Part 34] - Zipper Lists Approach

In this lesson, Alvin explores the strategy to solving the following interview problem:

> Write a function, *zipper_lists*, that takes in the head of two linked lists as arguments. The function should zipper the two lists together into single linked list by alternating nodes. If one of the linked lists is longer than the other, the resulting list should terminate with the remaining nodes. The function should return the head of the zippered linked list.
>
> Do this **in-place**, by mutating the original Nodes.
>
> You may assume that both input lists are non-empty.

```
a = Node("a")
b = Node("b")
c = Node("c")
a.next = b
b.next = c
# a -> b -> c

x = Node("x")
y = Node("y")
z = Node("z")
x.next = y
y.next = z
# x -> y -> z

zipper_lists(a, x)
# a -> x -> b -> y -> c -> z
```

```
a = Node("a")
b = Node("b")
c = Node("c")
d = Node("d")
e = Node("e")
f = Node("f")
a.next = b
b.next = c
c.next = d
d.next = e
e.next = f
# a -> b -> c -> d -> e -> f

x = Node("x")
y = Node("y")
z = Node("z")
x.next = y
y.next = z
# x -> y -> z

zipper_lists(a, x)
# a -> x -> b -> y -> c -> z -> d -> e -> f
```

```
s = Node("s")
t = Node("t")
s.next = t
# s -> t

one = Node(1)
two = Node(2)
three = Node(3)
four = Node(4)
one.next = two
two.next = three
three.next = four
# 1 -> 2 -> 3 -> 4

zipper_lists(s, one)
# s -> 1 -> t -> 2 -> 3 -> 4
```

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

Become A Debugging Master [Part 3] - Debugging Is A Premium Skill

Debugging is one of the most difficult yet valuable skills you can develop as a software engineer. Here are the core points from the lesson:

- Debugging isn’t just one skill—it involves asking sharp questions, deductive reasoning, clear communication, systems thinking, and holistic understanding
- As AI-generated “vibe coding” becomes more common, engineers who can deeply understand and fix code will become even more valuable
- Successful debugging requires patience and true technical mastery, far beyond just prompting an AI or relying on automated solutions
- Beyond fixing bugs, top engineers also prioritize which bugs matter most, combining technical problem-solving with smart decision-making for maximum impact

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.

[Distributed Systems Deep Dive] Design a KV such as Dynamo DB

This is a session on DynamoDB if you're looking to understand how to design a distributed key-value stores. We'll start with what DynamoDB is and why people are using it. Expect a run-through of its architecture and a straightforward explanation of how data gets sliced for efficiency. We'll also cover what happens when things go south and how DynamoDB keeps data consistent and up-to-date as well as the pros and cons.

If you write code and care about making it scale, this will be worth your time.\
\
**Dynamo Basics:** Understand what DynamoDB is built for and when to use it over other databases.

1. **Architecture:** Get to grips with DynamoDB's architecture - how it's built to scale effortlessly and provide consistent performance.

2. **Data Handling:** Learn about partitioning strategies that spread data across nodes effectively and replication techniques that prevent data loss.

3. **Resolving Conflicts:** Master vector clocks for resolving data conflicts in a system designed for eventual consistency.

4. **Operational Workflow:** Gain insight into the lifecycle of 'put' and 'get' operations and how DynamoDB handles data under the hood.

5. **Merkle Trees:** Understand how DynamoDB uses Merkle trees to synchronize data across distributed systems efficiently.

6. **Gossip Protocol:** Learn the workings of the gossip protocol for node communication and how it contributes to DynamoDB's robustness.

Thanks to [Alex Poon](https://www.linkedin.com/in/thealexpoon/) for leading this session!

Master The Behavioral Interview [Part 13] - Good Vs. Bad Questions To Ask

You're a software engineer and you have slogged through the behavioral round, answering many grueling questions. And now the interviewer opens up the floor to you: "Do you have any questions for me?". What do you do here? This lesson teaches you:

- What a good behavioral interview question to ask looks like through many examples, which you can ask word-for-word in your next behavioral interview
- What a bad behavioral interview question looks like (avoid these)
- The attributes of a high-quality question vs. a low quality question in a behavioral interview

Maximize Your Productivity As A Software Engineer [Part 10] - Organize Your Calendar

Now we know that focus blocks are one of the most powerful weapons in a software engineer's arsenal. So how can we get them? This lesson teaches you:

- How to organize your meetings in the most efficient way
- What you should look out for when it comes to clearing space on your calendar

Grow From Mid-Level To Senior Engineer [Part 10] - Code Review

Writing code is great, but so is reviewing code. In fact, being great at reviewing code is more impactful than being great at writing code 90%+ of the time! This lesson teaches you:

- How the writing code vs. reviewing code dynamic changes as you get to senior
- Why senior engineers tend to review more code than they write
- How senior engineers expand their code review scope while mid-level engineer code review scope tends to be more constrained with a real-life example
- The difference between a senior engineer code review comment vs. a mid-level engineer code review comment

Get better at code review with our masterclass: [\[Masterclass\] How To Do Amazing Code Review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/)

Engineer Your Ideal Tech Career [Part 15] - Role Types

Depending on what role you’ve narrowed your sights on, there are a number of things you can do in your current role to begin charting progress — from picking a specialization, to start scoping projects and reviewing code, to volunteering for mentorship opportunities and hiring.

Should you be thinking about a change soon, there are also actionable interview prep tips (and mistakes to avoid!) in this section.

Looking for mentorship from tech’s top engineers + personalized job hunt assistance and interview prep? [Formation.dev](http://Formation.dev) can provide you unlimited career coaching, technical mentorship, personalized practice, and mock interviews. Join us here: <https://formation.dev/partners/taro>

Worksheet: [Formation - Coding Your Career](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/courses%2Fslides%2FFormation%20Career%20Direction%20Worksheet.pdf?alt=media&token=f6344b78-529a-411e-a449-7a34a8d55fc8)

Grow From Mid-Level To Senior Engineer [Part 12] - System Design

System design is a topic engineers are becoming more and more familiar with, largely due to their emerging prevalence in interviews. It's also critical for the mid-level to senior promotion. This lesson teaches you:

- Why system design is the most important technical skill that mid-level engineers need to develop to grow to senior
- The ingredients of a high-quality system design document
- How to get feedback on your system design document
- Tactics to run an effective technical review meeting

Here's the system design course: [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

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.

Master The Behavioral Interview [Part 22] - Do Mock Interviews

Software engineers love working and studying solo, but this is extremely difficult with behavioral interviews. This lesson teaches you:

- Why behavioral interviews are inherently collaborative and effectively require mock interviews to master
- How to get the most value from your mock behavioral interview sessions

Ace Your Tech Interview As A Software Engineer [Part 38] - Go Deeper, Follow Through

You made it! By completing this course, you have attained the necessary wisdom to avoid the many, many failure modes software engineers so often fall into when searching for a job. This video teaches you:

- Why completing this course is actually just the beginning of your job search success
- The Top 5 overall learnings from this course
- The exact difference between struggling job seekers and successful ones
- How you can follow through with the knowledge gained from this course and actually apply it to your job search

If your job search dilemma isn't covered by this course, start a community discussion here: <https://www.jointaro.com/questions/create/>

Taro regularly hosts events to get your resume reviewed, pair up for mock interviews, and deep-dive into system design problems. You can find those events here: <https://www.jointaro.com/events/>

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

DSA Crash Course [Part 39] - Depth First Values Approach

In this lesson, Alvin explores the strategy to solving the following interview problem:

> Write a function, *depth_first_values*, that takes in the root of a binary tree. The function should return a list containing all values of the tree in depth-first order.

```
a = Node('a')
b = Node('b')
c = Node('c')
d = Node('d')
e = Node('e')
f = Node('f')
a.left = b
a.right = c
b.left = d
b.right = e
c.right = f
#      a
#    /   \
#   b     c
#  / \     \
# d   e     f

depth_first_values(a)
#   -> ['a', 'b', 'd', 'e', 'c', 'f']
```

```
a = Node('a')
b = Node('b')
c = Node('c')
d = Node('d')
e = Node('e')
f = Node('f')
g = Node('g')
a.left = b
a.right = c
b.left = d
b.right = e
c.right = f
e.left = g
#      a
#    /   \
#   b     c
#  / \     \
# d   e     f
#    /
#   g

depth_first_values(a)
#   -> ['a', 'b', 'd', 'e', 'g', 'c', 'f']
```

```
a = Node('a')
#     a

depth_first_values(a)
#   -> ['a']
```

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

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

Maximize Your Productivity As A Software Engineer [Part 14] - Do The Hardest Thing First

When you get a tough project, it's tempting to tackle the easiest parts first because you already know how to do them, putting off the most difficult portions for later (you'll totally figure it out right?). This lesson teaches you:

- The difference between bad and good engineers when it comes to taking on a project
- Why tackling the hardest parts of a project first is effective risk management and a defining behavior of the best tech leadWhen you
- The massive team-wide benefit solving the hardest problem grants you

Claiming Full Credit For Your Projects On Performance Review

- What is the project: Which features did it compose of? How does it work?
- Context behind the project:
  - Why was this project hard/interesting: Complexity of projects is especially important for more senior engineers.
  - What was the business impact: Did it lead to more revenue directly? Did it improve user experience? Was a core KPI increased?
- Role you played in the project: What value did you specifically add to the project, especially that of the deeper kind? For Big Tech companies, this is very important as projects can easily have 15+ people working on them.

Onboarding Tips Within Larger Companies

In a large company, you should expect a more formal onboarding process. However, don’t let this be an excuse to move slowly. Your goal is (still) to set up your environment and land code within a week.

Big companies will have many teams which may have slightly competing priorities. That means you need to invest in relationships and understand how the work connects between teams. Disperse and collect knowledge from around the company.

Spend some time understanding the unique terminology and culture of the company. Companies like Amazon, Meta, Google, Microsoft are large enough that they have their own set of acronyms, languages, and cultures!

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.