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)

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

DSA Crash Course [Part 10] - Most Frequent Char Approach

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

> Write a function, *most_frequent_char*, that takes in a string as an argument. The function should return the most frequent character of the string. If there are ties, return the character that appears earlier in the string.
>
> You can assume that the input string is non-empty.

```
most_frequent_char('bookeeper') # -> 'e'
```

```
most_frequent_char('david') # -> 'd'
```

```
most_frequent_char('abby') # -> 'b'
```

```
most_frequent_char('mississippi') # -> 'i'
```

If you need additional support taking these DSA skills and actually applying them, take [**Alvin's**](https://www.linkedin.com/in/alvin-zablan-b73a92117/) *complete* data structures and algorithms course on [**Structy**](https://structy.net/?utm_source=taro). You can try out the concepts yourself in their interactive code editor and learn advanced DSA patterns like stack exhaustive recursion.

Use [**this link to get 20% off**](https://structy.net/purchase?promo_code=taro20) the entire Structy DSA learning experience.

Follow Alvin on LinkedIn: <https://www.linkedin.com/in/alvin-zablan-b73a92117/>

[Case Study] Solving A Multi-Million $$ Instagram Bug

- A big part of moving from L4 (mid-level) to L5 (senior level) is being able to create your own scope. You can't just expect a perfect suite of projects to come from your manager.
- Like in this session's case study, bugs are a great source of finding your own scope!
- The bug was very slight: Instagram story ads started off on the wrong part when they were resurfaced to a user. As an Android engineer, Alex discovered this in IG Android initially. This bug had been in production *for over a year* at this point.
- How Alex expanded the scope after finding this bug:
  - Worked with iOS to see if the bug was there (it was)
  - Worked with PMMs to confirm that this violated the advertiser contract and merited a refund. This made the bug an immediate SEV.
  - Worked with a data scientist to figure out exactly how many times this bug occurred and calculate the exactly refund to advertisers ($2M+)
  - Put the fix behind an A/B test to measure impact and make sure it was working
- How you can incorporate the learnings from this case study:
  - Be detail-oriented. At Big Tech in particular, seemingly small issues can have massive impact.
  - Don't just silently fix bugs. Take the time to figure out its entire scope - It could be a SEV!
  - Understand the world outside of yours. Look for opportunities to bring in others (especially those of different roles) into what you're working on to expand scope for everyone!

Here's the [link to the slides](https://docs.google.com/presentation/d/1vPtelhi5caMsZNC-XFGhy1FtRveIbNxg0k3LZctRPOs/edit?usp=sharing).

For more resources around creating scope:
- ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://link.jointaro.com/uBcb5LjZiD5DasfB9)
- ["How can I come up with big initiatives, especially those at a Staff level?"](https://link.jointaro.com/6MWig3VSr3nVo81w9)

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)

Grow From Mid-Level To Senior Engineer [Part 3] - At A Glance: Mid-Level Vs. Senior

What exactly does it mean to be a mid-level engineer vs. a senior engineer? What's the gap? This lesson teaches you:

- What it means at a high-level to be a mid-level engineer vs. a senior engineer
- The types of projects mid-level engineers work on vs. a senior engineer
- The ownership and scope difference between a mid-level engineer vs. a senior engineer
- The difference in organizational complexity between mid-level engineers and senior engineers

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

Level Up Your Code Quality As A Software Engineer [Part 13] - Lay Out The Plan

It's tempting as a software engineer to leap straight into the code and start being productive. However, this can often cost you time in the long-term, especially with more technically complex tasks. This lesson will teach you:

- Why it's important to create a plan to increase your code quality, move faster, and build up relationships with your teammates
- What goes into a rock-solid coding plan (hopefully you were paying attention during the prior parts of the course!)
- Exactly what a good technical plan looks like with a concrete, real-life example from Taro

Amazon Case Study: The Ultimate Guide To Navigating A PIP

Case studies are valuable to (1) realize that you are not alone and (2) learn from the experiences of others and see what you can apply.

We’ll start with a new grad Amazon engineer who joined during the pandemic.

- **Before**: First job out of college, was on Focus after 6 months
- **During**: Shocked when they found out (URA quota suspected). Manager became more “HR-like”, less candid
- **After**: Went through the PIP and failed, even though they showed improvement

Level Up Your Code Quality As A Software Engineer [Part 16] - One Diff, One Thesis

One of the biggest and easiest ways to level up your code doesn't even lie in the code itself and is about how you split it up when submitting it for code review instead. This lesson will teach you:

- The most common way low-performing software engineers mess up their code when submitting it for review
- Why championing the concept of "One Diff, One Thesis" massively boosts your productivity alongside your code quality
- How to tell whether your pull request follows the principal of "One Diff, One Thesis" or should be broken up into smaller pull requests instead
- How to split up your technical task or project into chunks, so you can map out its pieces to a series of pull requests following "One Diff, One Thesis". We do this with an in-depth example further digging into the login flow

Write A Stellar Resume As A Software Engineer [Part 4] - 1 Resume To Rule Them All

Writing tons of different resumes is one of the easiest ways to waste time and overwhelm yourself on the software engineer job search. This lesson teaches you:

- Why you should only have 1 resume, especially if you're an earlier-in-career engineer
- Why "full-stack" engineer is often a trap for more junior engineers
- How to figure out the 1 resume you should write
- What to do if you really can't write just 1 resume (i.e. how to break the tie)

What Is An Engineering Manager?

In this lesson, we explore what an Engineering Manager (EM) is, what they do, and how understanding their incentives helps us collaborate more effectively.

- We learn that an EM is a leadership role supporting engineers, typically managing 8–12 reports, though team sizes can vary widely.
- We understand that the EM’s primary goal is ensuring the team consistently delivers meaningful impact.
- We recognize that knowing an EM’s core incentives helps us work with them more effectively and collaborate better overall.
- We review the two major career tracks in tech: the IC (individual contributor) track and the M (management) track, which begins with the EM role.
- We note that the EM is the first layer of management, with roles like Director, VP, and CTO above them, and that most of us will report to an EM unless we reach very senior IC levels (e.g., L8/L9).

You did everything right. That wasn’t the problem.

Some people move up because they ask for more.\
Others move up because they already act like they own more.\
Then there’s the third kind—the ones still waiting for someone to notice.

If that feels familiar, this section will explain why hard work alone isn’t the lever you think it is.

**Want to go deeper?**

- Explore more tools and courses at [**Taha’s Method**](https://www.tahasmethod.com/) — from interview prep to leadership development.

- Follow me on [**LinkedIn**](https://www.linkedin.com/in/tahahussain/) and subscribe to my weekly newsletter, [**The Conscious Leader**](https://tahahussain.substack.com/), for more lessons like these. 

- **Taro members get 30% off** my flagship course [**Top Tech Leader**](https://bit.ly/tarotopleader)*. Discount available later in the course.*

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

Nail Your Promotion As A Software Engineer [Part 4] - Do It For The Right Reasons

It's easy to become promotion-obsessed, especially at top companies like FAANG where promotions are so meaningful. However, this is a toxic mentality to have that ultimately hurts your career ambitions. This lesson teaches you:

- How to strike a delicate balance between deliberately pushing for promotion and having a healthy growth mentality
- The optimal mindset to have to get to extremely senior engineering levels
- Common pitfalls promotion-obsessed engineers fall into and what you should do instead for each of those situations

Related resources:

- ["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/?playlistId=EWIo3USNcsgXbCs5PS0h)
- ["How do I find projects for myself at work?"](https://www.jointaro.com/question/KitOGyYkpbsXFGoHPJUj/how-do-i-find-projects-for-myself-at-work/)
- ["How can I help juniors?"](https://www.jointaro.com/question/OzbQJCzLPbOKTEqpeSxF/how-can-i-help-juniors/)

DSA Crash Course [Part 9] - Anagrams Walkthrough

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

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

If you need additional support taking these DSA skills and actually applying them, take [**Alvin's**](https://www.linkedin.com/in/alvin-zablan-b73a92117/) *complete* data structures and algorithms course on [**Structy**](https://structy.net/?utm_source=taro). You can try out the concepts yourself in their interactive code editor and learn advanced DSA patterns like stack exhaustive recursion.

Use [**this link to get 20% off**](https://structy.net/purchase?promo_code=taro20) the entire Structy DSA learning experience.

Follow Alvin on LinkedIn: <https://www.linkedin.com/in/alvin-zablan-b73a92117/>

[Masterclass] How To Write A Stellar Tech Resume That Gets You More Job Opportunities

Writing an effective resume is crucial for succeeding within the tech industry, especially for software engineers. It's the primary step you need to clear before getting a chance with an interview opportunity. Unfortunately, there is a lot of misinformation around how to write a good resume: For 80%+ of junior software engineers struggling to break into tech, a poorly written resume is one of the main causes.

All that being said, here are our Top 5 points from the sessions (in no particular order):
1. *Remember that a recruiter is reading your resume and will, on average, only spend ~10 seconds on it*
    - They are almost certainly non-technical. Make things very accessible and easy to understand: Avoid jargon!
    - Be ruthlessly concise. For the vast majority of cases, your resume should only be 1 page.
2. Having a spelling or grammar mistake is the easiest way to get your resume thrown out
    - You have an effectively infinite amount of time to polish your resume. If you can't even catch basic mistakes like these, it shows that you have poor attention to detail or bad prioritization.
3. Show, don't tell
    - Don't just say that you're great, prove it
    - Example: Talking about the Android apps you've built with 100k+ users is much more effective than just saying you're a great Android engineer
4. Traps to avoid:
    - Having a summary section at the top
    - Self-rating yourself across skills
5. In the end, your resume needs to be approved by a human, not just an ATS
    - Making your resume very weird to "optimize" for the ATS is the epitome of winning a battle to lose the war. It's pointless

For an effective example + template you can use, [check out Alex's latest resume here.](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/articles%2FAlex%20Chiou%20Resume%20-%20FINAL%20FOR%20SHARING.docx?alt=media&token=3a75b8b2-09e8-4b68-b80d-22761055c3b2) You can import it into Microsoft Word online and swap out all of his content with yours.

Related resources:
- [[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/)
- [Presentation Slides](https://docs.google.com/presentation/d/15eLqE_WmePLA--lYTG0ZJVcHhpEld2qNTck_w0t_E9k/edit?usp=sharing)

[Masterclass] How To Learn Quickly In Tech

Related resources:
- ["How do I identify the core things to learn when picking up a new tech stack?"](https://www.jointaro.com/question/0VfjTWl2gxCKS0PRHpRT/how-do-i-identify-the-core-things-to-learn-when-picking-up-a-new-tech-stack/)
- ["What’s the most effective way to switch domains in tech?"](https://www.jointaro.com/question/eFr9vsyTSiYLCbtsj7RR/whats-the-most-effective-way-to-switch-domains-in-tech/)
- [Presentation Slides](https://docs.google.com/presentation/d/1C0RYphpovijVp8s3JVjG9iYFT6hgPJNHabIeP8WF7V4/edit?usp=sharing)

Create An Onboarding Doc

The **onboarding doc** is a reference guide as you join the company. This document is literally designed for you, outlining your role + team, people to meet, and how you can get started. Generally, your manager will provide an onboarding doc for you, but you should feel free to augment or create your own if the doc is lacking. This is a great place to collaborate and deepen your relationship with your manager -- point out further areas of discussion.

Components of a good onboarding doc:

1. Team charter (translated down from the company mission)

2. Partner teams + people

3. Expectations + milestones 

   1. These should be clearly defined so it'll be clear if you achieved the expectation or not

4. Project ideas with t-shirt sizing

5. Engineering rubric or career matrix for your role, if one exists

Reference question: [What should be part of an onboarding doc?](https://www.jointaro.com/question/FL7XdfLsG9Da6YyfbjZ3/what-should-be-part-of-an-onboarding-doc/)

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.