System Design Series: Taro Playlists [Part 3] - Defining The Requirements

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:

- It's very important for engineers to clearly understand the requirements of the product as they need to build them.
  - A common failure mode is that the proposed requirements aren't technically feasible. It's important for engineers to call this out as early as possible, which is why it's a valuable exercise for them to really lay out in the requirements in their system design doc and overall process.
  - Very senior product managers may give broad strokes in terms of what the product should do. Another reason why this exercise helps engineers is that it's actually up to them to convert the high-level points from their PM into very concrete features and requirements.
- "Jobs to be done" is a mental framework championed by Kevin Systrom, the co-founder and initial CEO of Instagram. The idea is that every product is "employed" by users to do a certain "job" in their life. This is a very important thing to understand about a product and clarifying this serves as an intermediary step towards creating concrete requirements.
- Something that's missing from this document are designs - This is because Taro has no dedicated design support at this stage. At a more mature company (which you almost certainly work at as the viewer), you would have designs at this stage in the document (it can be its own section). For front-end products, you need to put pixels on screen at the end of the day, so it's crucial for engineers to have designs to really understand the requirements and provide concrete feedback.

System Design Series: Taro Playlists [Part 2] - Sharing The Context

Core points from the video:

- Weak organizations will have product and engineering be incredibly siloed. It is far more effective when product managers and engineers work very closely together. Meta in particular has seen a lot of success by having this harmonious culture.
  - This means that software engineers should also understand why they are building something and not purely be responsible for implementation.
  - Software engineers should have an opinion on the product and work with their PMs to optimize vision and direction.
- A master spec should also have the context behind the "why" of a product and not only contain technical details.
  - The product details will often live in a separate document called a PRD (Product Requirements Document). In this scenario, you should link it in your technical spec and maybe have a paragraph summary of its contents as well.
- Capture any existing context that will affect how you build your system. This will often means that there's components that are already around in your company's ecosystem that you need to build on top of - This scenario is extremely common when building projects in Big Tech.
- Attach visual aides if you can (images, videos, gifs): It makes it far easier for project stakeholders to grok the information.
- **Context behind Taro playlists:**
  - One of the most requested feature within Taro
  - Think of it as being similar to YouTube playlists
  - We have already shipped a read-only version of playlists

For the full system design doc, you can get it by [becoming a Taro Premium member](https://www.jointaro.com/membership).

System Design Series: Taro Playlists [Part 1] - What REAL System Design Looks Like

This video is the introduction to our system design series, a vital skill for senior software engineers to succeed, especially at FAANG and Big Tech in general.

**Update:** Playlist are now shipped within Taro! Try it out and see how the system design in this video brought this feature to life by visiting the full playlist for the series here: [System Design Masterclass: Taro Playlists](https://www.jointaro.com/playlist/dChIyTQcu2Ct5VC70lki/)

Core points from the video:

- System design interviews are more analogous to your actual job than data structures and algorithms, but there are two big gaps:
  - **Overly grandiose exercises** - You will never get a technical problem on the scale of "Build all of Netflix", especially if you work at a Big Tech where you will get something much more local. Most of the biggest problems at these companies are already solved due to their maturity and plethora of software engineering talent.
  - **Time constraint** - Because interviews are time-boxed to 45 to 60 minutes, you have to do very broad strokes. In real life, system design should be much more thorough and has more steps and technical writing.
- To make this series as authentic as possible, we are going to be breaking down an actual upcoming feature within Taro: Playlists! On top of this:
  - This system design is exactly how Alex would design a system if he were still at Meta/Robinhood as a tech lead. While Taro doesn't need something this granular as a startup, this series simulates many aspects of a more mature company.
  - Alex has made a very thorough 9-page system design doc going through every aspect of the system.

[Case Study] Building XFN Alignment Across Multiple Orgs (w/ Staff Engineer Cat Chen)

[Cat Chen](https://catchen.me/) talked about his success building alignment across multiple orgs. 

Cat was working at Facebook as a Staff Engineer on the growth team. His charter to get the Android apps on app stores beyond the Play Store. (There were 10+ non-Google stores where Android apps get downloaded with some level of traffic.

Getting an app listed on a 3rd-party platform is simple – sign up as a developer on that platform; upload the Android app for review; wait for approval and launch it. Just as simple as publishing to Google Play.

**BUT it's not that simple at a company like Facebook.** Facebook lawyers wouldn’t allow Cat to accept the Terms of Service on behalf of Facebook the company. Cat didn’t have the privilege to bind Facebook into this contract and even if he did, the lawyers would certainly advise against that.

Instead of simply handing this problem to another person or org, Cat met with a director-level lawyer. Given he was on a different time zone, and in a different job function altogether, this took some legwork. The director explained the risk profile (Facebook could have unlimited downside by blindly accepting an agreement). Eventually Cat discovered a workable solution by using a contracting company to sign the legal agreement, which limits the damages that Facebook may face.

Impact of this work: 
- Successful launch of the existing Android apps
- Ability to launch other apps in the future
- Deep and positive relationship with the legal team, and Cat owned that relationship (which made him indispensable)
- **Almost zero lines of code written!**

[Connect with Cat](https://www.linkedin.com/in/catchen/)

For more resources on how to communicate, build alignment, and operate as a Staff Engineer:
- ["How do I sell the vision behind a large, org-level project?"](https://link.jointaro.com/NGCrB2ifkkpDaDe69)
- ["What's the Difference Between A Senior And Staff Engineer?"](https://link.jointaro.com/BEM2RAjPFe8Pv7826)
- [Guide to Effective Communication](https://link.jointaro.com/mP3WEd4zt5ecnupX6)

How Rahul Accidentally Got 70k Installs On An Android App

### The Story
- Before 2021, Rahul's YouTube channel was focused on Android tutorials.
- One of the tutorials he made was a simple Android app that let you set your status as an emoji. It was a pretty basic example of using Firebase.
- To make the output of the tutorial accessible, Rahul published the completed app to Google Play.
- What he didn't realize is that the app would be discovered by tens of thousands of users. After the past couple years, it has gotten 70,000+ installs with near-0 effort from Rahul.

### Learnings
- *Always publish* - So many people make projects that they then abandon or declare victory after the GitHub has gotten to a good state (even sharing this on their resume). Your code will pretty much never matter until it's fully out there in the world - If you're looking for your projects to help with job searching, recruiters are not going to care how clean the GitHub is.
- *Android distribution is extremely powerful* - Android has over 2.5 billion active users, and that number continues to grow. Due to the sheer volume of people, Android is one of the easiest platforms, if not **the** easiest platform, to publish something that gets a ton of users. There are far fewer Android apps compared to websites, so it's easier competing for Google Play search traffic vs. Google website search traffic. You only need to pay a 1-time $25 fee to publish an infinite amount of apps.

If you want to learn how to build your own side projects that get a ton of users:
- [In-depth Session On How To Come Up With Side Projects That Can Get 100k+ Users](https://link.jointaro.com/4m3CpQGgvkN3Xuem9)
- [In-depth Session On How To Grow Side Projects To 500k+ Users](https://link.jointaro.com/8QPgCkexjUjR9AA29)

How Alex Made An App That Got 80k+ Users In 1 Month

### The Story
- In summer 2016, Pokemon GO took over the world. Alex saw a need for an app to figure out where certain Pokemon were, so he and a friend quickly created a Yelp-style crowd-sourced app tying Pokemon to locations (pulled from the Yelp API). Alex worked on the Android app, and the friend owned by back-end.
- The app immediately saw immense traction, going from a few dozen to a few hundred to a few thousand (3,000+) new installs *per day* within just a week. **After less than a month, the app had been used by 80,000+ people.**
- Alex ran into copyright issues publishing the app as it used Pokemon images. Despite the app being free, ad-free, and not even asking for donations, it kept getting rejected. To hack around this, a server-side flag was created to turn off the images as the app was in review and turn them back on when the app got approved.
- Google Play eventually found out about the trick and took down the app for copyright infringement. However, the app was impressive enough at this point that Alex could include it on his resume, and it helped a lot getting interviews and giving him something to talk about during them.

### Learnings
- *Building a marketplace is extremely difficult* - A marketplace product is one that's a platform and requires a certain amount of some valuable resource in order to be useful: It's not useful on its own in a vacuum. For example, Uber needs a supply of readily available drivers to be useful. In this app's case, it needed data on Pokemon locations, which had to be provided by users.
- *Don't expect users to use the product properly* - In fact, don't expect your users to not be jerks. The app suffered a lot initially as users were uploading blatantly fake data of legendary Pokemon showing up in the wild - Legendary Pokemon hadn't even been released yet during the app's lifespan!
- *Be proactive and think through edge cases* - Zooming out from the prior point, it's just good to do this in general no matter what kind of software you're building, whether it's an entire app or a small feature on some already existing product owned by a FAANG company. Understand how things can get weird and address those scenarios accordingly.

If you want to learn how to build your own side projects, check these out:
- [[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free](https://www.jointaro.com/lesson/AI4zi759PSGn6RwIFT6f/masterclass-how-to-come-up-with-100k-users-app-ideas-you-can-build-for-free/)
- [[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)

If you're interested in the code of the Android app, Alex took the time to save it here: [https://github.com/Gear61/GO-Database](https://github.com/Gear61/GO-Database).

The Most EVIL Way To End An Interview (And How Not To Do It)

Here are the core points from the video:
- It is **never** okay to end an interview early because the candidate wasn't good enough. This is immensely disrespectful, especially for an onsite interview where the candidate carved out an entire day to do it (likely taking PTO if they are currently working).
- As an interviewer, you are also representing your company. If you do this, you are hurting your company's reputation as people talk - That candidate is very likely to tell others that your company is a horrible place to interview at.
- When this scenario happens, *the proper thing to do is to switch gears and go entirely into maximizing candidate experience* (as your goal isn't collecting signal anymore). This involves:
  - Giving them hints aggressively to help them complete the problem
  - Pair programming with them and trying to teach them - Use your interview to make the candidate a better software engineer!
  - Allocating more time for them to ask questions about the company - Try to get them excited! If you do this properly, they'll want to interview with your company again at a later time. People change - They may come back in a few years and be an absolutely incredible engineer you 100% want to hire.

Related resources:
- [Full session on being an amazing interviewer](https://link.jointaro.com/NhjenQ5vERKwRPdb9) - This is where this clip was cut out from.
- [Full 1 hour+ Masterclass On Acing Your Big Tech DSA Interview](https://link.jointaro.com/VfSeuUFiXNtKa5if7)
- [Full 1.3 hour Masterclass On Acing Your Big Tech System Design Interview](https://link.jointaro.com/Tmqs62Lw7WV4qDw59)
- [How Alex Got Into Meta With 0 Prior Leetcode Experience](https://link.jointaro.com/vaNH1hjRUhmF8ibSA)

Why Being A Good Interviewer Is So Hard

Every software engineer know what it's like to be interviewed, but few know what it's like being on the other side of the table giving the interview. It's important to understand this flipped perspective as it will help you resonate with the interviewer.

Here are the core points from the video:
- A good interviewer has 2 core goals:
  - Get signal on the candidate's abilities
  - Provide a great candidate experience
- Unfortunately, these 2 things usually conflict. In order to get good signal, the candidate often times has to struggle to solve a tough problem. Struggle is generally not associated with good experience.
- *A truly good interviewer makes it so that the candidate enjoyed their round even if they didn't pass.* This means that you need to get signal in a positive way by building the candidate up and bringing out their true skills without solving too much of the problem for them.

Related resources:
- [[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 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 Put The Interviewer On Your Side

At the end of the day, passing a software engineer interview is about convincing another person that you're competent. The best interview candidates behave in a way that naturally puts the interviewer on their side. Weak interview candidates behave in a way where the interviewer becomes their opponent. This video covers how to do the former.

Here are the core points:
- **Always be communicating** - Nobody can read minds. By regularly explaining your thought process, you are keeping your interviewer in the loop and giving them the maximum chance to fully understand you and your skill. Communication is an especially important axis for Big Tech.
- **Be very careful asking for hints** - If you haven't made a lot of progress on the problem, asking for a hint is effectively asking the interviewer to solve a good amount of the problem for you. This severely reduces the signal the interviewer gets on your abilities. *If you ask for hints too aggressively, you may be tanking your own chances.* For deep dive of the dynamics of interview hints, [check out our video here](https://www.jointaro.com/lesson/QFZxCLSuUDRYysvBBFLR/how-to-handle-hints-in-a-software-engineer-interview-without-failing/).
- **View your interviewer as a human not an obstacle** - While it's true that you need the rubber stamp from the interviewer to pass, focusing on that too much will negatively show in how you interact with and communicate with your interviewer. When you view your interviewer as another person and have empathy for their situation, you will understand what they're looking for and be much better equipped to show that signal.

Related resources:
- [[Taro Top 10] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [Effectively Learning Data Structures And Algorithms (DSA) For Software Engineer Interviews](https://www.jointaro.com/lesson/XwpMMY3ss97zOrXJQ7Xr/effectively-learning-data-structures-and-algorithms-dsa-for-software-engineer-interviews/)
- ["How can I show to a Big Tech company that I'm likely to succeed there?"](https://www.jointaro.com/question/ZpqoWC1zi3wMTXBUsS2B/how-can-i-show-to-a-big-tech-company-that-im-likely-to-succeed-there/)

How To Handle Hints In A Software Engineer Interview Without Failing

The best software engineer interview performances feel like a collaborative experience between the interview candidate and the interviewer. If an interview is going well, you will be supporting them as the interviewer and maybe giving hints. However, both sides need to be careful about how this happens.

Here are the core points from the video:
- Giving hints is tricky. There are some situations where it's good and some where it's bad.
- In general, you should lean towards giving less hints as an interviewer to maximize the signal you get.
- *Don't give hints when the candidate is desperately fishing, and they have no idea how to solve the problem.*
  - **Fishing example**: "Can we use a binary tree for this?" (they didn't explain their thought process at all prior to asking)
- Fishing questions like the one above are tricky as you can't answer them normally:
  - **If you say "Yes":** You reveal the core pattern behind the problem, solving way too much of the problem for the candidate. At this point, they have failed the question.
  - **If you say "No":** The candidate is one step closer to the core solution via process of elimination. This sets them up to keep fishing until you say "Yes".
- When the candidate is fishing, say something like, *"How do you feel about it? If it makes sense, we can try building it out."* Flip the question back to them and push them to think through it more.
- Give hints to bridge small gaps. If the candidate is 90%+ of the way there, just give them the hint so everyone can move on.
  - A common scenario here is that the candidate has almost all of the solution working minus some trivial 1-liner. You are losing signal by having them struggle on this trivial piece and not working on other, larger problems. In this case, just give them the 1-liner.

Related resources:
- [[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 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/)

5 Offers w/ FAANG Companies As A New Grad: Details + Lessons

In 2014, Rahul graduated from Stanford with a BS and MS in Computer Science. He received new grad Software Engineer offers from 5 companies: 
1. Facebook
2. Twitter
3. Microsoft
4. Google
5. Square

This video outlines the exact details of the offers, and models out the increase (or decrease) in value of those offers 8 years later, in 2022. The total compensation of the offers range from $174K/year to $262K/year, and those numbers go a lot higher if you factor in stock appreciation.

If you want to better understand how compensation works in top tech companies, first watch [this video](https://link.jointaro.com/819tdsqwJj4VnaEC6).

[Masterclass] How To Choose A Good Company And Team As A Software Engineer

Choosing the right company (or team) is one of the highest leverage decisions you'll make in your career, so it's worth doing some reflection!

It’s all about your priorities

- Figure out what’s important to you and what’s not. Create a stack-ranked list of all of these and work backwards from the top 2-3 to figure out the best opportunities for you
- People don’t realize how many angles there are to this. Here’s all the ones from the presentation: *Compensation, work-life balance, company prestige, supportiveness of team, growth opportunities, stability, maximum outcome (risk), remote work, product space, company ethics, technical space, level/title, benefits, location*

Supportiveness and overall quality of the team are often underrated

- It’s really hard to grow and have a healthy work life without this
- If you like your manager/teammates and you feel like you’re regularly learning/being challenged by them, deeply cherish that. People underestimate how hard it is to find an environment like this. Even in a prestigious company like Big Tech, this is difficult to find.

Big Tech vs. Startups

- At the end of the day, it’s all about your risk tolerance - Startups can have insane monetary/promotion outcomes, but they also might collapse the next year.
- In a vacuum: Start off at a Big Tech company to build a good foundation and then switch into smaller companies to have more scope/ownership

Some things you should NOT spend time on:

❌ Don't focus on how much you liked (or did not like) the people in the interview process. The recruiter/interviewer is NOT representative of your life at the company. Instead, focus on trends of the people joining the company, rather than individual data points.

❌ Don't spend time looking at the financials of the company. Even if you do decide to dig into the numbers, there's a good chance you'll screw up the interpretation -- humans have a really hard time with exponential growth.

Learning the quality of a team

- Talk to engineers/ICs if you can - The manager will inherently be biased towards their own team as they are often goaled on hiring
- Make sure that the team has a healthy oncall process and fast code review iteration

Related resources:

- [\[Masterclass\] What Software Engineers Should Look For In Their Engineering Manager](https://www.jointaro.com/lesson/oeY7ncZhzJ5NO6dij5e7/masterclass-what-software-engineers-should-look-for-in-their-engineering-manager/)
- [“How can you tell if a large public company is going in the right direction?”](https://www.jointaro.com/question/TrlweQQ7DveTnYBP9VUH/how-can-you-tell-if-a-large-public-company-is-going-in-the-right-direction/)
- [“What does it mean to not have enough scope to be promoted?”](https://www.jointaro.com/question/bJuagPwOEEy5vkcXKkqh/what-does-it-mean-to-not-have-enough-scope-to-be-promoted/)
- [“What should I look for in a new team in terms of growth?”](https://www.jointaro.com/question/i2bOMPrqaRc0NUZ7918F/what-should-i-look-for-in-a-new-team-in-terms-of-growth/)
- [Presentation Slides](https://docs.google.com/presentation/d/1S_kULq5zzVLkcoKy0bKJ2IHSrjL3s2VbOLe8p1TQJ7s/edit?usp=sharing)

[Case Study] Maximizing SWE Growth: Ownership and Specialization At Startups

**Huge** thanks to [Henry Prior](https://www.linkedin.com/in/henryprior/) for joining us and sharing his perspective and insights!

This was a *massive* session, so here are just some of the highlights:
- **Henry's core learning**: Bias towards action. You aren't really going to truly understand what is and what isn't fruitful to you until you just start trying things.
- **Story #1** - At his first startup job, Henry found a project to upgrade from Tensorflow 1 to 2. This ended up moving the metric he cared about, but he found out later that the business impact wasn't great. The company's clients were non-technical and didn't really care about the company's model being ultra-accurate.
- **Story #2** - Found a reinforcement learning project at his next company where he did all the modeling on his own and worked closely with an infra engineer to ship. The work was very complex and had huge impact, saving ~25 hours per week in Data Scientist cycles. He got massive recognition from the company, and this project was a big part of his move to senior.
- You have a lot of autonomy in early stage startups. Take advantage of this and actively look for large problems to solve, doing so as early as the interview process. It's not like Big Tech where you are generally given a good amount of direction on what to do (at least until you get to staff).
- *It's in your best interest to be completely authentic when interviewing with a startup.* It's not like Big Tech where you're putting on a facade to meet their interview requirements. A startup might not be the right for you due to a lack of work in your interest area: Big Tech in contrast has a little bit of everything.
- *If you're going to get into machine learning, you should understand the underlying math first.* This puts you in a much better position to work on the modeling part of ML vs. the more tertiary tasks like data wrangling. The math is a combination of probability/statistics, linear algebra, and calculus.
- **You can't study your way to being good at system design.** Resources like books and blog posts help, but system design is something you very much have to get good at by doing. Instead of just leaping into the code, start planning out your tasks and doing technical writing. From there, share your material with your team and get feedback.

Related resources:
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/yzWgzTF4WFzfXjS29)
- ["Does it make sense for me to choose a specialization like ML? If so, what's the impact?"](https://link.jointaro.com/jV34Jz7cJqQv2MpD8)

How Do Effective Engineering Leaders Help Their Teams Achieve More?

3 questions engineering leaders ask to increase the impact of their team without burning the midnight oil: 

1. What parts of this project are most critical? Who is most important for success? 
2. Can I optimize/shortcut some part of this project? 
3. Can I propose scope reductions for this project? 

Rachel also talks about the iron triangle often used for project management (time, scope, cost).

For more resources on engineering leadership:
- [This Is Why Most Engineering Managers Are Terrible](https://www.jointaro.com/lesson/4NJbAn0uTDUPfYfa859V/this-is-why-most-engineering-managers-are-terrible/)
- [[Masterclass] What Software Engineers Should Look For In Their Engineering Manager](https://www.jointaro.com/lesson/oeY7ncZhzJ5NO6dij5e7/masterclass-what-software-engineers-should-look-for-in-their-engineering-manager/)
- [[Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta](https://www.jointaro.com/lesson/X8vpfJooDpsX915ouC00/case-study-becoming-a-tech-lead-again-in-just-1-month-after-joining-robinhood-from-meta/)

What Advice Do You Have For Women (And Allies) In Tech?

There are not enough women software engineers. Rachel talks about the importance of sponsorship for career advancement, being ok with discomfort, and using employee resource groups (ERGs) to find community + support.

For allies (those in positions of privilege), acknowledge contributions from women and call out their good work if it's not getting noticed. 

Rachel also discusses how to evaluate a company's priorities around diversity and inclusion.

For more wisdom from Rachel, [here's her Taro playlist](https://link.jointaro.com/Cm5rJk4RJTkWhhnq7).

How To Quickly Understand Company Culture - Airbnb Example

Culture is more than what people say. It's about how things get done in the company. The best way to ramp up on a company's culture is to observe what people do and talk to as many people as possible when you first join.

Rachel also talks about the 2 unique aspects of Airbnb's culture: 
1. Mission-driven (as opposed to tech, sales, or founder driven)
2. Incorporating the best of different companies

If you want to learn more about how to understand an org/company and build up influence within it, here's some related resources:
- ["How do I sell the vision behind a large, org-level project?"](https://link.jointaro.com/ESa5WJyk682iwqJt9)
- ["How can I build up more influence in an org?"](https://link.jointaro.com/GVYFUhx46N2QWVeZ7)

How To Find Your Path Among The Countless Paths In Tech

As an early-career engineer, it can be overwhelming to figure out what technology to learn and which domain to dive into. In this video, Airbnb Director of Engineering [Rachel Zhao](https://www.linkedin.com/in/rachelzhao/) walks through the framework you can use to find your path.

The key to finding your passion is: 
1. Explore and refine. Give yourself some time + space to try adjacent areas.
2. Reflect on the various activities you do: What sparks joy? Think about both technical and non-technical activities.

If you want to learn more about this topic:
- [Figuring Out The Best Company To Join As A Software Engineer](https://www.jointaro.com/lesson/Nqs0U6rt2qFyXKSZurTh/figuring-out-the-best-company-to-join-as-a-software-engineer/) - The former VP of Engineering of unicorn startup Mixpanel shares his thoughts here.
- [This Is How Software Engineers Should Initially Learn](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/) - This video covers how earlier-in-career engineers mess up their learning.

English Communication Is The Most Important Skill For Immigrant Engineers

The field of engineering is filled with immigrants. Silicon Valley is famously built from the creativity and hard work of immigrants around the world (China, India, Israel, and much more).

If English is your 2nd (or 3rd) language, only or mostly speaking your native language at work will hold back your career. Rachel talks about her misconception that communication skills weren't that important, and how to improve your speaking + writing.

If you want to get better at communication, check out our course: [\[Course\] Clear Communication For Software Engineers](https://www.jointaro.com/course/clear-communication-for-software-engineers/)

This thread is helpful too: ["How to improve my communication?"](https://www.jointaro.com/question/omak9oOT4NJE9dhKeMZi/how-to-improve-my-communication/)

What's the Difference Between A Senior And Staff Engineer?

The mark of someone who is NOT ready to be a staff engineer: Asking what needs to happen to get to staff.

A staff engineer should identify problems worth solving, and then get buy-in across the org to solve the problem.

- Despite each staff engineer's journey being different, there's still an opportunity to learn from the examples of other promotion cases. Here's an example from Rachel's days at Yelp with a talented staff engineer:
  - Google announced an algorithm change for SEO ranking, which would favor websites with better mobile friendliness.
  - An engineer on a feature team recognized that this would hurt Yelp and brought it up very proactively.
  - They drove a proposal and broke down the problem with several domain experts in the organization.
  - It took a while, but they were able to ship a quality, long-term solution.
- Instead of just looking at "what" new problem to solve, there's also opportunity for very senior engineers to breakdown the "how" to accomplish a large, ambiguous problem and get to staff.

If you enjoyed this video, you can watch all of Rachel's other Taro videos here: <https://www.jointaro.com/topic/rachel-zhao/>

For more resources on getting to staff:

- ["How can I come up with big initiatives, especially those at a Staff level?"](https://www.jointaro.com/question/c3LcBDXEcxA85y9jlFjz/how-can-i-come-up-with-big-initiatives-especially-those-at-a-staff-level/)
- ["For a Staff engineer at a Big Tech company, what should their first 3-6 months look like?"](https://www.jointaro.com/question/X8QYtxzD7SXdzMfcnBiX/for-a-staff-engineer-at-a-big-tech-company-what-should-their-first-3-6-months-look-like/)
- ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://www.jointaro.com/question/3QIJhAT4loA7n1hSfCuw/how-do-i-come-up-with-innovative-impactful-ideas-and-bring-them-to-my-team/)

Rachel's Career Story: Waterloo, Yelp, Airbnb

To check out Rachel's excellent tech career advice, you can find the [full playlist here](https://link.jointaro.com/EFUYvmLHzenKQLRp6).

Rachel moved to Canada in high school, and then attended the University of Waterloo where she picked up programming for the first time. 
- She did various internships as part of the co-op program, and her first job out of college was at Yelp. 
- After 9 years at Yelp, Rachel had become a Director of Engineering there.
- Since 2020, Rachel has been an Engineering Lead at Airbnb, heading up the search product there.

**Rachel's core learning**: The times where you're uncomfortable and struggle are the times you learn the most. Stay calm and embrace the more difficult times in your career - When you view these situations as a growth opportunity, that's how you come out of them stronger than you were before.

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.