Master The DSA Interview [Part 3] - Struggling? That's Completely Normal

You are smarter than you think. Yes, this is even true if you're struggling with LeetCode easy problems. This lesson teaches you:

- Why engineers often underestimate their ability when it comes to data structures and algorithms
- How the learning progression curve for data structures and algorithms works for 90%+ of engineers
- How to set up your mentality and goals when it comes to studying data structures and algorithms

Level Up Your Code Quality As A Software Engineer [Part 5] - Fake "Clean Code" Shortcuts

A lot of software engineers want shortcuts: They want to find the optimal tech stack, programming language, and framework to slot into their code so it's automatically the best and they have conquered code quality. Unfortunately, that's just not how code quality works. This lesson will teach you:

- Why having truly good code quality is so, so hard and more about building up fundamental technical skills
- How to have a proper senior engineer mentality around "clean code" and how to extend a codebase
- Common fake "clean code" shortcuts that engineers desperately want to believe but ultimately aren't true (often stemming from obsession with FAANG and Big Tech)

[Become A Go-To Person 1/18] How This Course Works

A course by [Jordan Cutler](https://www.linkedin.com/in/jordancutler1/), Senior Software Engineer at Pinterest and Author of the [High Growth Engineer Newsletter](https://read.highgrowthengineer.com/)

How To Build Work Relationships Faster - Giving Deeper Thanks

If you want to build work relationships efficiently and effectively network in general, it's vital to master the art of giving thanks and showing gratitude.

Here are the core points from the video:
- **Giving thanks is a skill** - Don't just send a cookie-cutter 1 sentence thanks over DM after someone helps you: It's very soulless and takes you almost 0 time to write. Helping someone out with their work performance is one of the most high-impact ways you can add value to their lives; you should respond in kind when you receive this help. Some basic tactics to "level up" your thanks is to send a heartfelt paragraph and to thank them in person, either through a video call or actually in-person if you're physically coworking.
- **Thank teammates via their manager** - This is especially true at a high-performance tech company like FAANG where so much of the engineering culture revolves around performance review. If someone goes above and beyond helping you, make sure to let their manager know. If they're a recurring helper, you can even tell their manager that you deeply believe that this altruistic behavior should be rewarded in their performance review: When the helper hears this from their manager, they will *really* value you as a teammate and know that their efforts have truly been rewarded.
- **Thank publicly** - This adds more weight to your gratitude and also acts as an artifact to help out the other person during performance review.
- **Recurring thanks** - There's no reason why you can't thank someone multiple times for the same thing. Alex had a mentee who was really good at doing this: They would be very thankful on the initial unblock, and after the full project finished, they would thank the helper again (i.e. *"I just shipped this project, and it wouldn't have been possible if you didn't help me on X"*).

Related resources:
- [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/)
- [Don't Waste Your 1 on 1s. Build The Relationship](https://www.jointaro.com/lesson/wcFrGc53iHzbWh0Ssw1j/dont-waste-your-1-on-1s-build-the-relationship/)

[Masterclass] How To Become A Debugging Master And Fix Issues Faster

There will always be bugs, and this only becomes more and more true as your product gets bigger. In this video, we go deep into the often underrated software engineer skill of debugging.

Here are the core points:
- **Bugs are a source of growth** - So many engineers see having to fix issues as merely frustration, an obstacle getting in the way of their feature work. This is a toxic mentality to have that holds back your growth. Feature work isn't the only way to move a product forward, and at the end of the day, your team has to come together to uphold the integrity of its systems. Being a champion in that process is a powerful way to get to senior+ levels.
- **Do your research** - When you get a bug, don't just dive in and start mucking around in the code. Figure out the exact repro steps and go through the flow multiple times to really get it. Detail the blast radius by understanding attributes like when the issue popped up, how many users it affected, and what versions of your software experience the problem. Spend at least 15-30 minutes expanding the context behind the bug.
- **Understand the end-to-end flow** - Every outcome in software is a series of steps: When there's a legitimate bug, it simply means that one (maybe several) of those steps are now broken. Before you start seriously debugging, build up this mental model of the overall ecosystem behind the bug - Ask your teammates if you need help with this. This mental model will serve as the foundation of your debug process.
- **Maintain a debug diary** - Document every step of your journey as you're debugging. This will prevent you from trying the same hypothesis twice and makes it much easier for you to hand off the bug if necessary. This context will allow the new person to easily "download" everything you did and pick up where you left off. This writing will also help you a lot come performance review time when you want to claim credit for the fix.
- **Retrospect** - An ounce of prevention is worth a pound of cure. After every bug resolution, do some amount of thinking around how you can prevent similar issues from cropping up in the future. This is especially important with massive bugs that inflicted a lot of damage. In those scenarios, write-up a post-mortem and discuss it with your team.

Related resources:
- [[Case Study] Solving A Multi-Million $$ Instagram Bug](https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/case-study-solving-a-multi-million-dollardollar-instagram-bug/)
- ["How can I root cause bugs faster?"](https://www.jointaro.com/question/PSv7aYI70VwaDsoRgMyW/how-can-i-root-cause-bugs-faster/)
- ["I'm trying to fix a P1 bug, but some relevant code is owned by another team. Unsure about ownership and how to proceed."](https://www.jointaro.com/question/ZRneLgwmrM2JLCrGn5Rz/im-trying-to-fix-a-p1-bug-but-some-relevant-code-is-owned-by-another-team-unsure-about-ownership-and-how-to-proceed/)

If you want to become a better coder in general, check out our masterclass here: [[Masterclass] How To Write Better Code Faster As A Software Engineer](https://www.jointaro.com/lesson/iYpRj8XfyzCSaTYnce3y/masterclass-how-to-write-better-code-faster-as-a-software-engineer/)

Use Code Review Feedback For Hypergrowth - Meta Prodigy Engineer Story

As a junior software engineer, one of the main ways you're going to grow is through feedback on your code review. Because of this, it's vital that you get the maximum value from code review feedback.

Here are the core points from the video:
- **Respond quickly and with appreciation** - Be thankful of good code review feedback, and try to respond to code review comments within 1 to 4 hours. Don't be defensive when it comes to code review feedback.
- **Don't make the same mistake twice** - Take the time to really understand and absorb the feedback: Don't just make the suggested change. If you don't understand the principles behind some feedback on your code, just ask! [Here's our in-depth advice on how to really not forget code review feedback](https://link.jointaro.com/7wjo6DcDcJmxDVYB9).
- **Alex's mentee prodigy story** - Alex had a Meta mentee who was able to grow from junior [E3] to senior [E5] in just 2 years. A big part of this was their incredible code velocity:
  - This mentee really nailed learning from code review feedback. Their initial commits were a bit messy, but they quickly got to a point where they stopped making mistakes.
  - They were also very meticulous about their pull request quality. They always had very thorough summaries alongside very complete test plans. For more complicated commits, they would have up to 5 videos walking through every case.
  - After 1 half, this engineer was writing almost 500 commits a half, making them the #1 code committer in the entire organization. This was largely because their stellar code quality and code review learning allowed them to land their pull requests on the very first try 90%+ of the time.

This highlight is from our masterclass on "How To Write Better Code Faster As A Software Engineer". [Click here to watch it.](https://link.jointaro.com/v6zEgUfQTxoSj33Z7)

Related resources:
- [Quick Tips To Get Higher Quality Code Reviews Faster](https://link.jointaro.com/dE4U41RAVtZKLhxJ7)
- [Avoid These Junior Engineer Mistakes With Code Review](https://link.jointaro.com/agkYrLH8uuCv4UcPA)
- [Code Review MUST Be Fast, Otherwise The Team Is Unhealthy](https://link.jointaro.com/oxK55E1bkX8nMeNGA)

Negotiation Course: Rahul's History And Success With Negotiation

Rahul's compensation went from $110K at the beginning of his career to $830K in his peak earning year, 2021, as a Tech Lead and Manager at Meta (Facebook). That's more than 7x! A lot of his Total Compensation (TC) growth can be attributed to his ability to negotiate. There were 2 main segments of negotiation in Rahul's career: 

- 2013: 5 offers at Facebook, Google, Twitter, Microsoft, and Square
- 2017: 6 offers at Facebook, Google, Snapchat, Stripe, Uber, and Airbnb

This gave Rahul the leverage he needed to see dramatic increases in compensation. Some examples: 

- The Snapchat stock grant went from $600K --&gt; $1.0MM and the signing bonus went from $10K --&gt; $100K
- The Facebook stock grant went from $325K --&gt; $600K and the signing bonus went from $30K --&gt; $45K

The numbers here are due primarily to timing, information, and options, all things you can learn. The results can be life-changing, and you don't need to be a genius programmer to discover your own version of this.

These data points show how negotiation is extremely high leverage. A few hours of extra work can lead to a change of 6 figures or more in compensation.

- Rahul's YouTube video about 5 offers he received as a new grad: <https://youtu.be/rceUVaiXQgU> 
- Rahul's YouTube video about how compensation in tech works: <https://youtu.be/wqdpzu4Oa2I>

[Part 1] Meta Intern Success Series - Internship Program Overview

- The Meta software engineer internship program is very legit. It resembles the experience of working as a full-time Meta engineer as closely as possible, complete with calibrations and a formal manager.
- The program is also hard. The pass rates that got mentioned around the company were 50 to 75%. It's one of the harder software engineer internships to get a return offer from as the goal is to perform at E3 MA. If this is your first software engineer internship or you have only interned at companies weaker than Meta prior, the high bar can be overwhelming.
- However, the reward is tremendous. Meta is an incredible company to work at and amazing as a career starter. Meta is also one of the highest paying companies for the entry-level band (E3), and the signing bonus for return offer interns is sky-high (60k to 100k).
- 4 outcomes for Meta software engineer interns:
  - No offer: As mentioned before, many interns will unfortunately be here. The numbers after this correspond to the percentage of the "surviving" pool.
  - MA (70%): "Meets All Expectations", which is a regular return offer. The vast majority of successful software engineer interns get this. 
  - EE (25%): "Exceeds Expectations", which is given to very strong interns.
  - Rockstar (5%): For interns that completely crush it and are very close to functioning as a mid-level engineer (E4).
- Internship schedule (assuming standard 12 week length):
  - Weeks 1-3: Onboarding
  - Weeks 5-6: Mid-cycle review
  - Weeks 10-11: Final calibrations (return offer is decided here)
  - Weeks 11-12: Relax and have fun. Only your performance from Weeks 1 - 10 is counted towards your final review
- As a software engineer intern, you formally report to an intern manager (IM), which is shown on the org chart. On top of the IM, you will have 1-3 other peers who will review your diffs and help you. During calibrations, feedback from your IM and these peers will determine your final rating.

For more expert internship advice: [Full SWE Intern Advice Playlist](https://www.jointaro.com/topic/software-engineering-intern/)

Stop Getting Ghosted With Your Reachouts - How To Write A Great Cold Message

If you're a software engineer, you are likely going to do a cold reach out at some point in your career. This is almost always true when you're a junior engineer and don't have too deep a network yet. However, most software engineers go about this aspect of professional networking in the wrong way, especially when it comes to job searching and interviewing.

Here's how to write a cold message that actually has a chance of getting a response:

- **Mention your own background** - If you have any credibility, use it. What accomplishments do you have? What makes you special compared to everyone else and deserving of a response from this person?
- **Have a specific request** - The more pinpointed your ask is, the less effort it takes for the other person to figure out how to help you. Don't just ask for help with things like "career guidance" or "helping you find a job" - These categories are far too broad. Ask for tips on clearer areas like how to resolve disagreements in cross-team meetings or how you can pass behavioral interviews with &lt;50 person startups. For more advice here, check this out: [Asking Effective Questions That Get Great Answers Quickly](https://www.jointaro.com/lesson/HV8sq75WxM9VhK0dhUun/asking-effective-questions-that-get-great-answers-quickly/)
- **Find commonality** - Having common ground is one of the most important factors with a successful relationship. Whether it's working on the same tech stack, coming from the same school, or playing the same video game, share that commonality to make yourself feel more familiar.
- **Build them up** - At the end of the day, everyone enjoys being praised. Put them on a pedestal and explain why *their* input in particular is valuable to you. Show that you didn't send the exact same message to 100+ different people.
- **Make up follow-up items clear** - Don't just ask for "guidance" or "mentorship": Make it clear what's the exact form of help you want? Is it a link to a useful blog post or video? Is it a 30 minute 1-on-1 meeting?

Related resources:

- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- ["How to get referrals?"](https://www.jointaro.com/question/FQIi8us9uoTDIYdzMhvg/how-to-get-referrals/)

Ship & Grow 500k+ User Side Projects [Part 3] - Crafting The MVP

You should launch the initial version of your side project as fast as possible. So what exactly should it have? This lesson teaches you:

- The only thing your side project MVP (minimum viable product) needs to have
- How a piece of software can still deliver value despite having incredibly few features (or even just 1 feature)
- What a good MVP looks like, explained with an in-depth example
- A common mistake engineers make when it comes to shipping their MVP, explained with an in-depth example

If you're curious to learn why building a good auth flow is 5x harder than engineers think: <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/case-study-signup-form-edge-cases/>

Level Up Your Code Quality As A Software Engineer [Part 10] - Sweat The Details, Call Out Edge Cases

Building software that "works" is easy. Building software that truly works in all viable scenarios is hard and what separates the great engineers from the mediocre ones, especially at Big Tech. This lesson will teach you: 

- Why mistakes are extremely punishing in software
- The relationship between the happy flow and edge cases
- Why being detail-oriented is an extremely valuable asset in tech, especially for your code quality
- The mental framework to have as a software engineer to proactively call out edge cases in a systematic way

Build Deep Relationships Quickly In Tech [Part 2] - Why A Strong Network Isn't Optional

No engineer is an island. And if they are, they're going to have a bad time. This lesson teaches you:

- How a strong network helps with job searching
- How a strong network helps with promotion and overall on-the-job performance
- How a strong network helps with general learning
- Why you need to start networking *now*, and how starting "early" actually makes the networking way easier

To better understand the difference between a strong referral vs. a weak referral: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/referrals/>

Managing Up: Understanding Your Boss

Understand the preferred communication style of your boss:

- Preferences/pet peeves

- Strengths and weaknesses

- Work to earn trust

- Share your own style and best environment

Connect with [**Ethan on LinkedIn**](https://www.linkedin.com/in/ethanevansvp/)

Taro members get a discount to join [Ethan's Level Up community](https://levelupwithethanevans.substack.com/taro25)

Top System Design Interview Mistakes [Part 5] - Don't Over or Under-Engineer a System

In system design interviews, it's crucial to strike the right balance between complexity and simplicity in your solutions. This video highlights the importance of avoiding both over-engineering and under-engineering:

- Designing systems with unnecessary complexity can lead to wasted resources, higher risks of bugs, and an impractical solution
- While caching can improve performance, indiscriminately adding caches without careful consideration can introduce inconsistencies and unnecessary complexity
- Rather than adding complexity for its own sake, stay focused on the unique challenges of the problem at hand to identify the most effective solutions
- Thoughtfully evaluate where to apply caching or other optimizations by weighing the benefits against the potential downsides
- Ensure that your design decisions are driven by the specific needs of the problem, rather than trying to impress the interviewer with buzzwords or unnecessary tools

This approach helps create efficient and practical solutions tailored to the specific challenges of the interview prompt.

If you need extra help with your system design interview, [Formation.dev](https://formation.dev/partners/taro) can provide you hands-on, personalized support. Join us here: <https://formation.dev/partners/taro>

Negotiation Course: How This Course Works

Your ability to negotiate is undeniably one of the highest-leverage skills you can learn. But tech workers are notoriously bad at negotiation. Based on discussions with 100s of tech workers, there are 2 common reasons for this: 

1. They choose not to negotiate. They somehow view negotiation as a perverse 'badge of honor' that they simply accept the first offer they receive and they don't want/need to ask for any adjustment. 
2. They try to negotiate but are ineffective. They don't have leverage or cannot defend why they're asking for certain things. 

This course is designed for tech employees who are exploring job opportunities and will receive a job offer in tech (and ideally multiple!). My goal is for you to feel confident and strong in discussions you have with recruiters and hiring managers.

This course is broken down into 3 major parts: 

1. **Principles** - How does negotiation work and why is it worthwhile?
2. **Planning** - What should you do (and not do) before and offer you receive an offer?
3. **Tactics** - What is the best course of action for various scenarios?

If you get more than a $10K increase in your compensation by following the tactics outlined in this course, send me an email at [rahul@jointaro.com](mailto:rahul@jointaro.com) -- we will celebrate together!

How The Best Software Engineers Learn A Tech Stack - The Lego Model

- "The Lego Model" is a way to view the world and understand your learning journey as a software engineer.
  - Technical components (e.g. rendering a list of items) are the individual legos
  - Complete products (e.g. a food delivery app) are the full lego creations
- There are 3 axes to evaluate your legos:
  - **Quantity:** How many you have
  - **Quality:** How good and sturdy your legos are
  - **Commonality:** How "in demand" your legos are (i.e. how many creations they can fit into)
- Most earlier-in-career engineers understand the 1st axis of quantity and incorrectly spend a lot of time learning different tech stacks and frameworks.
- Those same engineers often don't even realize the 2nd and 3rd axes exist:
  - When they learn a component, they will build it out with very low quality.
  - They will learn "flashier" components that aren't even used by most products/companies.

For examples on how to excel at the 2nd and 3rd axes, check out the related resources below!

Related resources:
- [[Masterclass] How To Learn Quickly In Tech](https://www.jointaro.com/lesson/u9ldIvrTvV1wfWExccDR/masterclass-how-to-learn-quickly-in-tech/) - The full video this clip came from
- [This Is How Software Engineers Should Initially Learn](https://link.jointaro.com/iVBpCaB6pAHivhdi6)
- [Building Software For Optimal Learning Example - Login Flow](https://link.jointaro.com/oEkTB3pskKH6JHCX6)

[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free

Here are our Top 5 points from this session:
- **Side projects are incredibly powerful** - They improve your portfolio, increase your coding velocity, and give you holistic experience around building products end-to-end.
- **Care deeply about quality** - Users notice when your app or website is buggy. Strive to cover all edge cases and provide a truly polished experience.
- **Eat your own dogfood** - The best way to know how to improve your product is to use it yourself. This was a staple of Meta's engineering culture.
- **Least clicks design** - At the end of the day, it doesn't matter how "pretty" your product looks if it isn't efficient. Think about how you can have your "hero flow" take as few clicks as possible.
- **Understand SEO** - Work backwards from what people will be searching for when they need a product like yours. Then have those words in your product title and relevant metadata.

Related resources:
- [Presentation Slides](https://docs.google.com/presentation/d/1lfSCWI_OUtchWpIEKwG8JkII8IUvBeACRqEJlnTErjU/edit?usp=sharing)
- [How To Come Up With Product Ideas That Get 100k+ Users](https://link.jointaro.com/7Q8cDrda23zv2omU9)
- [How Side Projects Make Recruiters Come To You](https://link.jointaro.com/rxqDDu4sgMQbP6LT8)
- [Why Side Projects Are So Powerful For Junior Engineers](https://link.jointaro.com/cFo3doiWDeE5dpa67)
- [How To Split Your Time Properly Between Work & Side Projects](https://link.jointaro.com/YFCmNrsdqhuMSeUw5)

20 Years Of Fighting Procrastination [Part 1] - Rahul's History With Procrastination

Welcome to our "20 Years Of Fighting Procrastination In 1 Hour" course! Here are the core points from the lesson:

- Your instructor Rahul Pandey goes through his personal experience struggling to get stuff done (and learning how to fix that)
- Focus on building systems that make it easy to do the right thing and hard to do the wrong thing, rather than relying on willpower
- The advice is tailored for people with autonomy over their time, not for those in reactive or manager-style roles

Manager vs. Maker schedule: <https://paulgraham.com/makersschedule.html>

Why Most Companies Suck At Onboarding

You should not expect a good onboarding process at your company. Helping new employees ramp up is a good example of something that is *important but not urgent*. Tenured employees likely don't remember what it's like to be new.

While many companies will have insufficient or non-existent onboarding, the other end of the spectrum is also unfortunate: larger bureaucratic companies will have excessive onboarding, with months of training before you can do anything productive.

Even if the company has good intentions, building a solid onboarding plan is a hard problem: the tech industry's rate of change is very high, with people, tools, and technologies changing every year. Naturally, documentation and processes around onboarding become outdated.

Despite the difficulties, poor onboarding can be seen as an opportunity for new employees to have an immediate impact.

Top System Design Interview Mistakes [Part 6] - Freezing on the Spot

In system design interviews, clear communication is crucial. Many candidates struggle not because they lack knowledge, but because they fail to express their ideas effectively. This video highlights a common issue: Freezing under pressure.

- Instead of freezing when faced with a complex problem, keep the conversation going by asking clarifying questions. This not only helps you gather necessary information but also engages the interviewer.
- If unsure what to ask, focus on understanding the system’s functionality. Questions about the product’s purpose and user journey can guide your design process.
- Involving the interviewer through questions shows your experience and keeps the interview on track.

In short, don’t let nerves stop you—ask questions to maintain momentum and communicate effectively.

If you need extra help with your system design interview, [Formation.dev](https://formation.dev/partners/taro) can provide you hands-on, personalized support. Join us here: <https://formation.dev/partners/taro>

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.