How To Actually Learn Software Engineer Skills

A very common trap among software engineers is that they end up merely acquiring knowledge instead of actually learning software engineer skills. This is especially true when you're onboarding into a new team or company.

Here are the core points from the video:
- **Learn how to fish** - If you are growing as a software engineer, you want to make sure that you're actually learning the systems underneath instead of just acquiring surface-level solutions to your problems. "Receiving fish" is knowing that solution X solves your problem Y. "Learning how to fish" is understanding how solution X was crafted.
- **Get maximum value per answer** - Learning is largely absorbing support from other software engineers. When this happens, make sure to deeply understand how they arrived at their support. This can be when they give you an answer to your question or leave a comment on your pull request. *Ask follow-up questions to "download" their thought process.* It's much better to take full advantage of each interaction all in one go, so you don't need to ask them other simple questions in the future.
- **Example:** A teammate helps you debug. You can ask them the following:
  - How did you identify the breaking code?
  - Why did you choose this approach for the fix vs. others?
  - If you couldn't understand the code immediately, how did you figure out who to ask to get this understanding?

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. [Click here to watch the full thing.](https://link.jointaro.com/9sJzfDeH3JdWzZRg9)

Related resources:
- [This Is How Software Engineers Should Initially Learn](https://link.jointaro.com/hoL4o29S3YsGsR9i7)
- [Building Software For Optimal Learning Example - Login Flow](https://link.jointaro.com/BjyeKesdaZt7SrwJ8)

Asking Questions Is NOT A Sign Of Weakness

Believing that asking questions and requesting help is a sign of weakness is easily one of the biggest misconceptions among onboarding software engineers and just people in general. If you believe this, you are simply holding back your career.

Here are the core points from the video:

- **Nobody knows everything** - And because of this, asking questions is a fundamentally human experience. There will always be some corner of the ecosystem that you don't know, and this is especially true when you work at FAANG / Big Tech, even if you're very tenured there.
- **Liberally pursue support** - This is especially true when you're earlier-in-career or new to a team or company. As long as you're polite, humble, and empathetic when seeking help, you'll be surprised at how much support you can get and how happy your team is to give it to you. Follow the advice here to learn how to ask questions in this way: ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://www.jointaro.com/question/vNE8kgpx2zdI1wACg9jA/how-do-you-overcome-the-fear-of-asking-stupid-questions-bothering-people-when-you-need-help/)
- **Minimize the time that you're a n00b** - Let's say perception is a problem and people think you're annoying when you're asking for help as a new team member. It's much better to ask a *bunch* of questions in a short period of time and become very independent afterwards instead of asking a few questions here and there and prolonging the period where you're an inefficient newbie for 3-6 months and dragging down the team. The latter would be *much* more annoying.

Related resources:

- ["How do I not bother people when asking for help?"](https://www.jointaro.com/question/0Im1Kcgso1fJ8eAX3oOO/how-do-i-not-bother-people-when-asking-for-help/)
- ["How do I balance being more independent and asking questions?"](https://www.jointaro.com/question/cLsgiARaD5kVmV1BvdUi/how-do-i-balance-being-more-independent-and-asking-questions/)

[Masterclass] How To Write Better Code Faster As A Software Engineer

Code: It's the main thing software engineers care about. However, as we all know, writing code quickly while keeping it clean can be extremely difficult. This is what this masterclass will help you with: We want to empower you to not only write more code, but write higher-quality code as well.

There were a ton of important points from this masterclass, so here's our Top 5 (in no particular order):
- **Go deep, not wide** - One of the most common mistakes junior software engineers make is not focusing on just 1 stack, often captured by being a "full-stack engineer". When you go ultra-deep on just 1 stack, you will start developing software engineering fundamentals and "muscle memory" that allows you to write code a lot faster. It will generally take 2-4 years of focus on just 1 stack to start getting really good at it. For more information about this point, check out this video: [This Is How Software Engineers Should Initially Learn](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/)
- **Build side projects** - There's no magic to getting better at coding: The more you do it, the stronger your skill. This is why side projects are so powerful: They allow you to write more code without overworking yourself as we talk about in this discussion: ["How will side projects enhance my skills as a software engineer on the job?"](https://www.jointaro.com/question/KORArGLRW6mNn47ddC1S/how-will-side-projects-enhance-my-skills-as-a-software-engineer-on-the-job/)
- **Submit polished pull requests** - There's more to code than the raw lines you put into commits; how you submit it for review is a huge factor as well. If you take the time to make atomic PRs, add context, and attach a thorough test plan, your code will be landed much faster (and your team will love you for it). For concrete examples on what this looks like, watch this: [One Diff, One Thesis - What Every Code Review Should Be Like](https://www.jointaro.com/lesson/3NAbmgiaY3IpvayNIoVl/one-diff-one-thesis-what-every-code-review-should-be-like/)
- **Really absorb code review feedback** - The main way you will learn as a junior engineer or as an onboarding team member is by getting feedback on your code. Make sure to respond to code review feedback in a timely manner (<4 hours) and really soak it in: Strive to never make the same code quality mistake twice. If you're having trouble getting your code reviewed fast, follow the advice here: [Quick Tips To Get Higher Quality Code Reviews Faster](https://www.jointaro.com/lesson/QgDk2yWlfWzgLjh56bSq/quick-tips-to-get-higher-quality-code-reviews-faster/)
- **Modularize your code** - Split your code up into focused components with single responsibilities and thoughtful names. When you do this, your code will be much more flexible, reusable, and easier to read. Here's our advice on how to break down large projects into more digestible chunks: ["How can I be better at executing on my work when it comes to coding and breaking down ambiguity?"](https://www.jointaro.com/question/6lfyIKgkoclcDNKWq9o3/how-can-i-be-better-at-executing-on-my-work-when-it-comes-to-coding-and-breaking-down-ambiguity/)

Related resources:
- [[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results](https://link.jointaro.com/8D6Y6BnYm8696RtC9)
- [[Masterclass] How To Do Amazing Code Review](https://link.jointaro.com/8D6Y6BnYm8696RtC9)
- ["What can I do to quickly build my reputation as a junior engineer?"](https://link.jointaro.com/hxCTvumsQhUqRAbn6)
- [Presentation slides](https://docs.google.com/presentation/d/17o6XlEjiYbkV1FMrhOoFwcM1O59NmdAOfZ3AXol7daY/edit?usp=sharing)

Don't Learn Code In This Way - How Software Engineers Waste Time

So many software engineers mess up when they're trying to learn code by bringing over a bad habit from school: Studying. This is simply not how software works, and this video's here to explain why.

Here are the core points:
- **Reading code and documentation is ineffective** - You can't purely read your way towards a good understanding of a codebase; it will get you 10-15% of the way tops. Software is fundamentally about doing - The actual learning begins when you jump in and start playing with the code. On top of all this, it's much better to get a high-level understanding of the codebase by asking your teammates for it instead of trying to infer it yourself from raw reading.
- **Documentation gets worse the better the company is** - Good software companies are fast-moving. This is a big reason why FAANG is successful: They are able to still move quickly despite their immense size. Because of this, documentation is rarely kept up to date due to how fast the codebase evolves. In fact, excessive reading of documentation may actively harm you if it contains legacy patterns that aren't accepted at your company anymore.

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. You can watch it here: [[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer](https://www.jointaro.com/lesson/n384HdJuDgulSHbHQLnf/masterclass-how-to-succeed-at-a-new-team-or-company-as-a-software-engineer/)

So now that you know how NOT to learn a codebase, here's some resources on how to actually learn a codebase:
- [How To Learn A New Codebase Fast](https://www.jointaro.com/lesson/DX27hiXPJ4G7Czk2mwLL/how-to-learn-a-new-codebase-fast/)
- [Learning A New Codebase? Here's How To Figure Out What Matters](https://www.jointaro.com/lesson/dQXKZNqivtoByEHV9V17/learning-a-new-codebase-heres-how-to-figure-out-what-matters/)
- ["How can I learn a large codebase fast as an intern?"](https://www.jointaro.com/question/F2rJZgdUBxdGZilFTR6k/how-can-i-learn-a-large-codebase-fast-as-an-intern/)

Onboarding Gives You Special Powers: Make Sure To Use Them

Most people view onboarding as a position of weakness: They don't know anything while the team knows everything, and now they need to bridge that gap. While that's somewhat true, onboarding is *not* a position of weakness, and thinking this will only make your onboarding slower and less effective.

Here are the core points from the video:
- **Nobody wants to be mean to the newbie** - This means that you have extra slack to ask questions and request help more aggressively than the average team member. However, this "aura" doesn't last forever - Make sure to really use it while you have it! The first month in particular is when the team will be extra accommodating of you.
- **You will never have fresh eyes again** - Being new gives you a perspective that tenured members of your team simply can't have. Use this to share new ideas and suggestions to the team: Tactically, you are very well equipped to improve the onboarding process. Don't only view onboarding as a state where you need to be dependent on others and consume help - Feel empowered to bring about positive change as well.

Related resources:
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://www.jointaro.com/question/vNE8kgpx2zdI1wACg9jA/how-do-you-overcome-the-fear-of-asking-stupid-questions-bothering-people-when-you-need-help/)
- ["What does it mean to not require handholding anymore?"](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/)
- ["I'm afraid of asking questions when I don't know how to start a new ticket - How to get over the fear?"](https://www.jointaro.com/question/ReLSgQGmVGlXkwrupN5T/im-afraid-of-asking-questions-when-i-dont-know-how-to-start-a-new-ticket-how-to-get-over-the-fear/)

How To Figure Out If A Team Is Important To A Company

In this age of layoffs, it's important to choose a team and organization that is valued by the company overall. Even ignoring layoffs, it's better to join a team that's mission critical overall due to more career growth opportunities, especially as a software engineer.

Here's the core points from the video:
- **Profit center or cost center** - Does the company see your organization as core to its revenue generation or something it simply needs to have in a digital age? If its the former, that means the organization is probably better for your career:
  - **Profit center example:** The ads/search organization at Google
  - **Cost center example:** Website developers at a dental company
- **Growth trajectory** - In particular, is the organization scaling up its headcount quickly? If so, that shows that it's a company priority, and scope naturally appears when teams get bigger due to higher XFN and alignment costs.
- **Company visibility** - Do execs mention your organization in all-hands meetings? Better yet, is it referenced on earnings calls? The more an organization is mentioned in these more public communications, the better positioned it is within the company.

This clip was taken from our masterclass here: [[Masterclass] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

Related resources:
- ["How possible is it to spot red flags about toxic culture during the interview?"](https://www.jointaro.com/question/1JwmhC3Nh9Ku0fkDL1bq/how-possible-is-it-to-spot-red-flags-about-toxic-culture-during-the-interview/)
- ["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/) - Question from a Google L4 engineer
- ["Is it better to work in revenue-generating divisions within your company?"](https://www.jointaro.com/question/BIv8teCgxktk5tak6tlI/is-it-better-to-work-in-revenue-generating-divisions-within-your-company/)

How To Find A Good Team With Career Growth Opportunities

Not every team will have the scope you need to get to the next level, especially at FAANG and Big Tech. If you're looking to get to senior engineer levels and beyond, here's what to look out for in a team:
- **Past launches** - If the team has frequent, meaningful launches from the past year, it's likely this will continue.
- **Healthy balance of levels** - You want folks more senior than you to learn from and folks more junior than you for you to mentor and work through.
- **Strong engineering manager track record** - In particular, see who they have been able to get promoted. If there are examples of senior and staff engineers grown organically within the team, that's another good sign.

This clip was taken from our team selection masterclass. You can watch it here: [[Masterclass] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

Related resources:
- ["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/) - Question from a Google L4 engineer
- ["How do I find a good team that sets me up for the mid-level -> senior level promotion?"](https://www.jointaro.com/question/oHJWlzm1qdHUZx66moaT/how-do-i-find-a-good-team-that-sets-me-up-for-the-mid-level-greater-senior-level-promotion/) - Question from an Amazon SDE 2
- ["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/)

Software Engineers - Don't Forget These 2 Things When Considering A Team

These 2 more tactical aspects are often forgotten by software engineers when evaluating a team, even though they are huge influencers on your work-life balance and career growth on a team:
- **Oncall** - You want to make sure that the team has a healthy system there where you aren't oncall too often, and the system is stable (so you don't need to wake up in the middle of the night constantly to fight fires). For more information on how to evaluate the health of an oncall rotation, check out the linked discussion below from an Atlassian Software Engineer.
- **Code review speed** - It is easy for slow iteration here to stack up. If your team takes 3 days on average to review your PR and you need 3 revisions to finalize your commit, that means it will take you 2 entire weeks to land code (which is abysmal). A good team will turnaround code reviews in <1 day.

This clip was taken from our [masterclass on finding the best company/team for you - Click here to watch the full thing](https://link.jointaro.com/F4DDyKfuo3hMhj868).

Related resources:
- ["How do I factor in oncall into my team selection?"](https://link.jointaro.com/3LHQz46Ft1c7ZoXo6) - Question from a Junior Software Engineer at Atlassian
- [Code Review MUST Be Fast, Otherwise The Team Is Unhealthy](https://link.jointaro.com/oxK55E1bkX8nMeNGA)

The Real Pros And Cons Of Working At FAANG And Big Tech

Working at FAANG and Big Tech is general is put on a pedestal by the vast majority of the industry, but it's not all sunshine and roses. Here's the complete pictures:
- Pros:
  - **Prestige** - If you don't already have one of these names on your resume, adding one makes it 10x better automatically.
  - **Compensation** - This one is the most obvious: These companies pay extremely well.
  - **Consistent foundation** - The biggest one is the learning, especially for earlier-in-career software engineers. It is hard to go into these companies, do well there for a couple years, and not come out as a significantly better engineer. You will get more consistency by setting a baseline for your compensation and level.
- Cons:
  - **Hard to find scope** - In particular, growing to senior can be difficult. So many of the hard technical problems at these companies are already solved, and there are thousands of super talented software engineers looking for scope as well.
  - **You're just a cog in the machine** - At FAANG, you are one talented engineer out of literally 10,000+. The majority of engineers will be doing very incremental work that doesn't feel very fulfilling - There are literally engineers whose job it is to optimize a single button. This is all very connected to the aforementioned con of not being able to find scope.
  - **Work-life balance is dicey** - These companies pay you well for a reason: The bar is high. It can be stressful and tiring to meet expectations, especially if you're transitioning from a non-FAANG company.
- It's also important to remember that you need a much more holistic set of skills on top of coding most of the time to succeed at these companies. For many, this is a pro as it leads to more well-rounded growth, but for others who want to focus more on being builders, it can be incredibly draining.

For a deeper look into what life at FAANG is actually like, join us for our upcoming event: [Should You Work At FAANG? - What Big Tech Is Like For Software Engineers](https://www.jointaro.com/event/should-you-work-at-faang-what-big-tech-is-like-for-software-engineers/)

This clip was taken from our [1.5 hour masterclass on finding the best company/team for you, which you can click here to watch](https://link.jointaro.com/F4DDyKfuo3hMhj868).

Related resources:
- [Why You Should Start Your Career At A Big Tech Company](https://link.jointaro.com/9k3HkgfJsTp1Nd2w5)
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/n57gbTWERveGTQuM9)

[Case Study] Hypercharging Your Growth At Early Startups (w/ Staff Engineer Seed Zeng)

[Click here for the presentation slides](https://docs.google.com/presentation/d/1ZocNUZJL-feWAKoucVLUcaVxix2Xa1udEL4KpgQRBTo/edit?usp=sharing).

There are a *ton* of great points covered in this session, so we'll only share our Top 5:
- **Startups have massive scope** - In an early-stage startup, there is always an infinite supply of hard, technically deep problems. This allows you to have a lot of freedom choosing an opportunity that works well for you and build up a wide breadth of important skills. This is almost always *not* the case in Big Tech - [Check out this expert career advice on the difference between Big Tech and startups when it comes to learning](https://link.jointaro.com/n57gbTWERveGTQuM9).
- **Don't say "I'm not qualified to work on this"** - The best software engineers are able to adapt to any situation their team faces and add value regardless of what framework or tech stack is needed. In order to do that, you must first flip this fearful mentality. [Here's our masterclass on how to learn quickly in tech](https://link.jointaro.com/S2h95sJvRU8Utjj6A).
- **Don't be afraid to make mistakes** - Recovering from a mistake is one of the most powerful ways to learn, and startups will generally have more tolerance for mistakes as stakes are lower compared to a more mature, massive public company where product issues can make the news. [Here's our advice on how to maximize your growth from mistakes](https://link.jointaro.com/THof1u97Z5t1ovCr9).
- **80% of the journey is just showing up** - Seek out important, complex situations and run towards them instead of away from them, especially with production issues. If you're earlier-in-career, you can learn a lot simply by being a participant in fixing these fires; from there, you can make yourself a core driver more and more. [Here's our advice on how you can be more independent debugging tricky technical problems](https://link.jointaro.com/xE8oMpCaDYjuMhCg7).
- **It's all about the people** - Your career growth is largely a product of the people you surround yourself with, and this is especially true in a startup where the team is small, bonds are deep, and everybody knows each other. [Here's our advice on how to network effectively within a company](https://link.jointaro.com/Hr1nr53D7sfQAEv3A).

To see (and hear) more from Seed:
- [Connect with him on LinkedIn](https://www.linkedin.com/in/seedzeng/)
- [Check out his podcast "Superposition"](https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkLnBvZGJlYW4uY29tL3N1cGVycG9zaXRpb25zaG93L2ZlZWQueG1s?sa=X&ved=0CAMQ4aUDahcKEwjot6up4Zf7AhUAAAAAHQAAAAAQAQ&hl=en)

Related resources:
- [Session #6 - Maximizing SWE Growth: Ownership and Specialization At Startups](https://link.jointaro.com/2ZevbN54MPZPTocH8)
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/n57gbTWERveGTQuM9)

What's Often Overrated When Choosing Your Next Job

Here are the attributes we've generally seen software engineers prioritize too much when weighing career opportunities:
- **Product space** - This usually manifests as pursuing a tech trend (like VR or NFTs). Of course, if you're legitimately passionate about the space, go for it, but seriously ask yourself if you would be in this space if it wasn't regularly talked about.
- **Technical space** - Similar to product space, you can follow trends here. Choose a stack that you're legitimately passionate about, which also has the support network you need (very important for junior engineers). The risk with cutting-edge technology is that it often doesn't have a lot of mature teaching resources behind it (it's cutting edge for a reason).
- **Level/title** - Promotion is a decent and concrete career goal earlier on, but don't go to bad companies to maximize your title. At the end of the day, your level and title are just strings next to your name.
- **Compensation** - Money is genuinely important in almost all cases, but what a lot of people don't realize is that very high pay often comes with a catch (usually work-life balance). Try treating this as a lagging indicator - If you're genuinely growing fast as a software engineer, you will eventually
land an opportunity that is top-of-market (as you deserve).

This clip was taken from the following masterclass: [[Masterclass] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

Related resources:
- ["How should I think about levels when it comes to evaluating jobs and in my career overall?"](https://www.jointaro.com/question/siBFn9WmU204N6D0IRHZ/how-should-i-think-about-levels-when-it-comes-to-evaluating-jobs-and-in-my-career-overall/)
- ["I feel like senior engineers tend to focus on a specific area. How can I pick a specialization that's still relevant in 5-10 years?"](https://www.jointaro.com/question/xFEhcvfbJ2P0pYzZ4r6f/i-feel-like-senior-engineers-tend-to-focus-on-a-specific-area-how-can-i-pick-a-specialization-thats-still-relevant-in-5-10-years/)

The First Thing You Need To Do Before Figuring Out Your Next Company And Team

Choosing the right company and team for you as a software engineer is one of the most important decisions you'll make, and given the high turnover in the tech industry, is a decision that you will have to make multiple times. This is why having the right mentality here is so crucial, which is what this video covers.

Here are the core points:
- Everyone is different - There is simply no "one size fits all" career path for everyone. FAANG companies are great overall of course, but there are going to *many* people and situations where it doesn't make sense to go there.
- Before thinking about your next move, have an honest conversation with yourself and those close to you about your priorities. *Your goal is to create a stack-ranked lists of your priorities.*
- Prioritization is a much harder exercise than people realize as there's simply so many angles to it. Here the ones mentioned in the video:
  - Compensation
  - Work-life balance
  - Company prestige
  - Supportiveness of team
  - Growth opportunities
  - Stability
  - Maximum outcome (risk tolerance)
  - Remote work
  - Product space
  - Company ethics
  - Technical space
  - Level/title
  - Benefits
  - Location

This clip was taken from the following masterclass: [[Masterclass] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

Related resources:
- ["How do I know when it's time to leave a team/company?"](https://www.jointaro.com/question/2Ahiy6ZtUYWDjkSoG3Zk/how-do-i-know-when-its-time-to-leave-a-teamcompany/) - This is the Q&A that Rahul mentioned in this video.
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://www.jointaro.com/question/KWXIrFIR1EIJsvdOdo7u/whats-the-difference-between-big-tech-and-startups-in-terms-of-learning-and-growth/)

[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer

There are **ton** of great points in this presentation, so to prevent this summary from being a 10 page essay, we're only including our Top 5 points:
1. **Asking for help != weakness** - In fact, it's quite the opposite: Trying to figure out everything on your own and not asking questions is what makes you weak. Being comfortable with your cluelessness and putting yourself out there aggressively to get all the help you need is what makes you strong. Learn more about this dynamic here: ["How do I balance being more independent and asking questions?"](https://www.jointaro.com/question/cLsgiARaD5kVmV1BvdUi/how-do-i-balance-being-more-independent-and-asking-questions/)
2. **Get maximum value from questions** - Ask high-quality questions and ask follow-up questions to really understand the answers your teammates give you and the systems they followed to arrive at those answers. Your goal is to learn skills in a sustainable way that makes you more independent as opposed to needing hand-holding all the time. To better understand hand-holding (and how to evolve from it), check out our in-depth explainer here: ["What does it mean to not require handholding anymore?"](https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/)
3. **Don't get trapped reading the code and documentation** - The only real way to learn a codebase is to just hop in, start changing code and seeing what happens. Software is all about learning via doing. Watch this video to learn more: [How To Learn A New Codebase Fast](https://www.jointaro.com/lesson/DX27hiXPJ4G7Czk2mwLL/how-to-learn-a-new-codebase-fast/)
4. **Thanking people is a skill** - When you're onboarding especially, it is crucial for you to show your gratitude effectively: Don't just do the basic, boring "Thanks for the help!" DM over Slack/Teams after you have been helped. Send the helper a heartfelt note, tell them in person, or let their manager know about their great deed. You can learn more about "deep thanks" here: [Effective Communication Guide [Part 3.1] - The Power Of Thanks](https://www.jointaro.com/lesson/noWZaoGWlrYQxX2Vhigd/effective-communication-guide-part-31-the-power-of-thanks/).
5. **Be empowered to help others, even when you're new** - Anyone can help others, even the newbie. In fact, newbies are equipped to add unique value by having a fresh pair of eyes, particularly around improving the onboarding process for others. If you're onboarding, make it one of your priorities to earn respect as that will make the entire onboarding process smoother for you.

For more premier resources on onboarding:
- [[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/)
- ["How do you overcome the fear of asking stupid questions / bothering people when you need help?"](https://www.jointaro.com/question/vNE8kgpx2zdI1wACg9jA/how-do-you-overcome-the-fear-of-asking-stupid-questions-bothering-people-when-you-need-help/)
- ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://www.jointaro.com/question/QhqQQGrDgFjZbqohpKe0/how-can-i-become-more-independent-and-better-at-unblocking-myself-with-tricky-technical-issues/)
- [Presentation Slides](https://docs.google.com/presentation/d/1MTs7GIklpVnYrA_JRlgcpKu1reeTLto1kYEsa6M8UqI/edit?usp=sharing)

System Design Series: Taro Playlists [Part 10] - This Is Just The Beginning

Congratulations, you made it to the end of our **system design** series! If you liked this series and want to see more like it, give this video and all the others in the playlist a like!

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 are working through a **system design** at your job!

Here are the core points from the video:
- Creating the **system design** doc is just the 1st step of the process: The next step is getting aligned from the team!
- Here are the steps to get strong alignment and the technical and overall product direction on a project:
  - Time-box the exercise: Have a firm date in mind on when this alignment needs to happen and work backwards from that date.
  - Share the doc with teammates and stakeholders and push them to leave feedback asynchronously. You can directly cc important people on relevant portions for them to look through.
  - Set up a tech review meeting as a forcing function to solidify all the alignment and talk through any remaining points of content. This meeting should probably be 45 minutes or more. Book it far ahead of time as senior+ engineers, tech leads, and managers tend to have very busy schedules.
  - Remind people before the meeting to go through your system design doc beforehand and try to resolve as many threads before the meeting as possible. You might need to do this several times.
- Everything covered in this system design series is effectively a requirement to be a competent senior+ engineer and tech lead, *especially* if you work at FAANG or some other Big Tech company.
- This can all be done reactively as well. If you're working on a small, tightly-knit team with very high synergy (common in startups), raw tribal knowledge and ad-hoc collaboration may be enough to ship projects consistently well. In this case, doing all this probably doesn't make sense. However, if your last couple projects have been pretty rocky, you might want to consider adding all the processes outlined in this series.

If after all this, you're still hungry for more **system design resources**:
- [How To Ace Your Big Tech Interview [System Design]](https://link.jointaro.com/NoVGhFiEErzfh61f6) - This is a full 1.25 hour masterclass, so prepare yourself for a **ton** of knowledge!
- ["How do I get better at building large scale systems without working directly on such projects?"](https://link.jointaro.com/Dm9wE33YC7ffwAPa6) - Question from a Senior Software Engineer at LiveRamp
- ["How to improve on non-technical skills like writing software design document?"](https://link.jointaro.com/T7GCmM4Z4CZhve4y5) - Question from a Mid-Level Software  Engineer at Microsoft
- ["My team has been doing architecture debates for months and we’re in gridlock."](https://link.jointaro.com/Zzx1NRMJFHvtHcvP8) - Question from a Senior Software  Engineer at Google
- ["How can I better contribute to system design discussions on my new team?"](https://link.jointaro.com/FH7ED2533nSTJSRc6) - Question from a Senior Software Engineer at Google

System Design Series: Taro Playlists [Part 9] - Thinking Into The Future

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 are doing a system design at your job!

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

- Products are rarely shipped in isolation: You will almost always iterate on them in the future, extending them and adding new features.
- You should always take some time to think into the future for your project. The amount of time you take will vary a lot based on situation, but it generally plays out like this across company types:
  - **Smaller companies and startups**: Spend less time as goal is to ship, and it's unclear if the company will survive to even iterate.
  - **Big Tech/FAANG**: Spend a lot of time as these companies need to think long-term to maintain their massive market presence.
- When coming up with future iterations during your system design, order them by likelihood of doing and level of priority.
  - Spend more time thinking through the scenarios at the upper end of the list and incorporate them into your system design if they are very likely to be done in the next couple months.
  - Your goal is avoid a scenario where you need to extend your system shortly after it's launched, but it's so brittle and fragile that you would need to rewrite huge swaths of it to accommodate the new use-cases.
- However, this is a failure mode on the opposite extreme and that is being unreasonably forward thinking and over-engineering your system as a result. Making a protocol more generic and scalable almost always takes more time.
- When building systems or services, seriously think about the assumptions you are making.
  - Will the input this API takes in always be in this format and have certain fields?
  - Will this hard-coded if-statement start blocking valid control flows in the future?

System Design Series: Taro Playlists [Part 8] - Breaking Down The Work And Timeline

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 are doing a system design 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:

- Something Alex forgot to mention in this video is the "POCs" section, where POC = "Point of Contact".
  - Big projects will usually have a lot of stakeholders, so having this "people map" is very helpful for any project stakeholder to know who to direct their questions to for a certain aspect of the project (which are often about the timeline/milestones).
  - This small, humble section is *especially* relevant at FAANG/Big Tech where the range of responsibility holders is almost always huge for major projects.
- Decomposing work and breaking big projects down into smaller tasks is helpful for so many reasons:
  - It allows you to estimate the project far more accurately by increasing clarity.
  - It creates "swim-lanes" for more junior engineers as they now have smaller, clearer chunks of work as opposed to this giant, hulking ambiguous cloud of a project.
  - It makes it easy to understand project as you can now break clusters of tasks into groups and attach a milestone to each group.
- Don't just decompose the work: Try to sequence it into a logical order as well. For example, if you're building a CRUD feature, you probably want to prioritize the "Create" part as that's what everything stems from.

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!

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.

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

System Design Series: Taro Playlists [Part 4] - Covering Edge Cases

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

- You should *always* at least try to cover all the edge cases when building out a product, even if you're a small startup.
  - If you're at Big Tech in particular, you absolutely need to have amazing coverage on edge cases as even an issue affecting just 1% of users could be breaking the experience for 10 million+ people.
- A lot of edge cases are quite easy to cover and are low-hanging fruit. Bad engineers will be lazy and ignore these, supposedly in the name of velocity.
  - **Example:** You have a login form that takes in email. Instead of no-oping, throwing a generic error, or letting them login with an invalid email, validate the email upon submission and show an error message if it's invalid. This will almost always be a 5-10 minute change.
- There's many "playbooks" of edge cases, so coming up with edge cases isn't rocket science - It's largely a solved problem. Here are some examples:
  - **Generic edge cases that apply to any user input:**
    - Input is blank
    - Input is overly long
    - Input is very strong
  - **Generic edge cases that apply to any content collection:**
    - No content
    - A lot of content
    - Content fetch fails
- *Being very diligent around edge cases is also crucial for interviews, both DSA and system design, and is often how Big Tech interviewers differentiate the great candidates from the mediocre ones.*

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!

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.