Write A Stellar Resume As A Software Engineer [Part 3] - The Key To Writing A Great Resume

In the vast majority of cases, a recruiter is reviewing the resumes of software engineers. This means a lot more than most engineers realize. This lesson teaches you:

- The #1 principle you **need** to remember when writing your resume
- The important attributes of recruiters when it comes to vetting resumes
- How to truly empathize with recruiters and infer their resume screening behaviors based on that
- How recruiters read through engineering resumes

Tech Lead Blueprint 1/17 - What's The Deal With Tech Leads?

Engineer A claims "*I am the Tech Lead for Engineer B*", while Engineer B claims "*I am the Tech Lead for Engineer A*" 🤔🤔

Lalit has seen several variants of this from his experience as a peer reviewer for Google engineers during performance reviews. Lalit discusses the common desire for the tech lead role, the lack of explicit definitions in tech companies, and the implicit nature of becoming a tech lead.

Connect with Lalit on LinkedIn: <https://www.linkedin.com/in/lalitkundu/>

Grow From Junior To Mid-Level Engineer [Part 1] - How This Course Works

Congratulations on breaking into tech as an engineer! Let's get you off to a great start. Here are the core parts of the lesson:

- Your instructor [Alex Chiou](https://www.linkedin.com/in/alexander-chiou/) walks you through his extensive 10+ year Silicon Valley background with rapid career advancement, ending up as a high-performing tech lead making $750k at Robinhood. More importantly, he goes through how he was able to grow his mentees to lightning fast promotions, particularly at Meta where he grew 10+ junior engineers (E3) to mid-level engineers (E4) in just 1 year!

- You'll understand what it means to be a junior vs. a mid-level engineer in the market, including the interview space

- We walk you through the course objectives. By the end of the course, you will understand:

  - 💡 Truly understand the **difference** between a junior engineer and a mid-level engineer

  - 🛠️ Learn to **code** like a mid-level engineer

  - 💪 Know what it means to be truly **independent**

  - 🧠 Have the right **mindset** to act as a mid-level

  - ✅ Define a clear **roadmap** to mid-level

If you haven't already, we recommend taking the overall promotion course here: [Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)

DSA Crash Course [Part 3] - Max Value Walkthrough

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

Code along and test your work in the following editor workspace: <https://structy.net/problems/max-value?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/>

Asking Great Questions [Part 3] - The Key Behind Questions That Don't Suck

There are good questions, and there are bad questions. One of the main ways to thrive as a software engineer is quite simple: *Ask **good** questions*. So how do we do that? This lesson teaches you:

- The key concept behind asking a truly good question
- Why empathy is an engineering superpower in general
- The concrete way to identify a bad question
- The concrete way to identify a good question

The Journey to Staff Engineer In Big Tech (Panel Discussion) - Sep 2023

The journey to Staff Engineer is unique for everybody. In this session, we talk about all the ways we got there! Senior Engineer is a terminal level at most tech companies.

Staff Engineer is the next level up. This is referred to as Staff at Meta/Google, or Principal Engineer at Amazon/Microsoft.

Themes discussed in the video:

- Staff Engineers need to have multiplicative impact and influence across multiple teams. There are several ways to achieve this (occasionally referred to as archetypes): code machine, architect, product thinking, fixer, and more.
- Communication, and right-sizing it to the level and discipline of your audience, is critically important.
- Being able to speak to real, quantifiable numbers when it comes to the impact you have is essential.
- Staff engineers are typically known as the experts in certain domains or situations. Becoming well-known in an area is a skill and does require some amount of marketing.

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

Publicly available promotion stories:

- [Ryan's Instagram video processing improvements](https://engineering.fb.com/2022/11/04/video-engineering/instagram-video-processing-encoding-reduction/)
- [Rahul's internal tool for debugging](https://www.jointaro.com/lesson/qvp2quodqAEWSkN7sayt/case-study-building-a-meta-internal-tool-to-empower-an-entire-org-staff-promotion-story/)

Panelists:

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

Watch the [Q&A portion of the panel here.](https://www.jointaro.com/lesson/P7bEwvDaCuYRfEtmfcaL/the-journey-to-staff-engineer-in-big-tech-qanda/)

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

Maximize Your Productivity As A Software Engineer [Part 4] - Stay The Course

It's incredibly easy to get distracted with random incoming tasks, especially at a fast-paced company like FAANG. This lesson teaches you:

- The importance of staying the course and sticking to your high-impact, ruthlessly prioritized tasks
- How to diplomatically push back and say "No" (saying "Yes" to everything is one of the easiest ways to destroy your productivity as a software engineer)

Nail Your Promotion As A Software Engineer [Part 3] - The Key To Understanding Promotion

We're told our entire lives that the key to success is to work hard. While this is admittedly true for most professions, it's very much not the case when it comes to software where you need to work *smart* in order to get anything done, especially for promotion. This lesson teaches you:

- The key insight behind understanding what promotion truly means, especially at top companies
- Why you can't get promoted by just working longer hours and writing more code, especially at very senior levels
- A framework to understand what separates incredibly senior (L6+) engineers from the more junior ones
- What it means to think multiplicatively instead of individually, including an in-depth example

Excited about developing better product intuition after watching this lesson? Check this out: ["How to develop product sense as an engineer?"](https://www.jointaro.com/question/w84sxyM805YOCokfvuQ8/how-to-develop-product-sense-as-an-engineer/)

Why Onboarding Matters

This video discusses the importance of onboarding and how it can significantly impact your reputation and career growth. 

If you imagine a "**Trust Meter**" where 0 means you have no trust and 100 means absolute trust, your default score as the new engineer will be around 50. Existing employees will think you are smart and have good intentions, but you need to work hard to increase the score and unlock larger-scoped projects. This hard work begins in onboarding.

The other reason the initial months in the company are important is because the tech industry is changing increasingly rapidly. When the average tenure at a company is &lt; 2 years, you need to figure out how to fully ramp up in a fraction of that time. Even within the same company, you will likely switch teams multiple times. Re-orgs are so common!

By approaching onboarding with a proactive plan and a sense of urgency, you can set yourself up for success and build strong relationships quickly.

Effective Communication Guide [Part 2] - Basic Tactics

Most software engineers are socially awkward, and they perceive communication as this mythical skill that is impossible for them to master. Well, it turns out that there's quite a lot of very easy things you can do to become much better at communication. This lesson teaches you:

- **Use tentative language** - You can always be wrong, and you should acknowledge that in how you communicate:
  - Bad: "Your code isn't performant."
  - Good: "I think this code may have performance issues."
- **Body language matters** - Communication isn't only the words you say or write, it's also how you express with your face and body. This is something that is biologically wired into humans: Put your entire self into it when you are communicating, especially when you're listening! This is covered more in the part of this course: [Effective Communication Guide \[Part 3.2\] - Deep Listening](https://www.jointaro.com/lesson/q1UyjOoZ2pud9IdmXlVJ/effective-communication-guide-part-32-deep-listening/)
- **No leading "hello" for digital communication** - When asking for help digitally, don't do a greeting and then wait for a response greeting before jumping into your ask: Just attach your ask from the get-go. Software is all about efficiency and waiting for this round trip makes things less efficient. For more advice around asking for help effectively, here's our in-depth video about it: [Asking Effective Questions That Get Great Answers Quickly](https://www.jointaro.com/lesson/HV8sq75WxM9VhK0dhUun/asking-effective-questions-that-get-great-answers-quickly/)
- **Lead with the core point** - Think of a "tldr" when it comes to long articles. This also applies to how you talk: Start with the main idea, and then go into the details. When you start by going into the weeds (very common for earlier-in-career engineers), it's very easy for people to be uninterested or get lost in what you're saying. For an example of how this applies to technical writing, check out this Q&A from a Meta engineer about it: ["How to get more visibility on work?"](https://www.jointaro.com/question/XA0X51AypDLCeVeleJv4/how-to-get-more-visibility-on-work/)

The #1 Thing You Need To Know About Promotion In Tech

True or false: To get to very senior engineering levels, you need to write thousands of lines of code per day.

Why is output not as important for promotion?

- *Promotion is about behavior, not output*
- Raw output doesn't scale. You only have so many hours in a day, and your hands can only physically type so many lines of code per minute.
- Senior engineers can have 10x to 100x the impact of a junior engineer. In order for them to do this, they need to add deeper types of value to the business.
- That deeper type of value comes from behaving in a fundamentally different way to more junior levels. In particular, engineers at these very senior levels add multiplicative value instead of additive value. An example of this is a senior engineer empowering many others to write code instead of just writing the code themselves.

Related resources:
- [[Taro Top 10] Time Management And Productivity](https://www.jointaro.com/playlist/5WA87nbbYJWLnQ60D826/)
- [[Masterclass] How To Get Promoted Faster In Tech](https://www.jointaro.com/lesson/W730BOdrfAIXAEVd8HUf/masterclass-how-to-get-promoted-faster-in-tech/?playlistId=eZOEUatYEe7BBAZByuha) - The full video where this clip is from
- ["How to improve at multi tasking at work?"](https://www.jointaro.com/question/ION8KZHyA8fNWOpHDhZI/how-to-improve-at-multi-tasking-at-work/)

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

Core points from the video:

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

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

DSA Crash Course [Part 4] - Is Prime Approach

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

> Write a function, *is_prime*, that takes in a number as an argument. The function should return a boolean indicating whether or not the given number is prime.
>
> A prime number is a number that is only divisible by two distinct numbers: 1 and itself.
>
> For example, 7 is a prime because it is only divisible by 1 and 7. For example, 6 is not a prime because it is divisible by 1, 2, 3, and 6.
>
> You can assume that the input number is a positive integer.

```
is_prime(2) # -> True
```

```
is_prime(3) # -> True
```

```
is_prime(4) # -> False
```

```
is_prime(5) # -> True
```

```
is_prime(6) # -> False
```

```
is_prime(7) # -> True
```

```
is_prime(8) # -> False
```

```
is_prime(2017) # -> True
```

```
is_prime(2048) # -> False
```

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

Promotion Is Underrated And The True Foundation Of Your Pay And Career

Here are the core points from the video:

- In a lot of companies, promotion isn't meaningful, both in terms of growth and pay increase. *However, promotion is extremely powerful when you're working at a top-tier company like FAANG.*
- In a good environment, promotion is the most organic option to increase your total compensation as it means that your actual skill and increased pay are actually correlated with one another.
  - If you get promoted at a FAANG/Big Tech company, this sets the foundation for future opportunities as you will now be put at this level at least 95%+ of the time. For example, if you become a senior engineer \[L5\] at Google, it is very unlikely that your next company will put you below senior.
  - It's also crucial to remember that at FAANG/Big Tech, the expectations are quite real and quite high. By getting promoted to your level, this means that you are actually able to perform at this level, as opposed to the scenario where you negotiated an up-level via a job switch where you might be dangerously over-leveling yourself.
- *The problem with doing the interview prep and job switching grind is that you're not actually growing as a software engineer during that time.* There is a huge disconnect between interview skill and actual skill, especially with data structures & algorithms (DSA).

Additional promotion resources:

- [Nail Your Promotion: Senior To Staff (L5 -&gt; L6)](https://www.jointaro.com/learning-paths/nail-your-promotion-senior-to-staff-l5-to-l6/)
- [Nail Your Promotion: Mid-Level To Senior (L4 -&gt; L5)](https://www.jointaro.com/learning-paths/nail-your-promotion-mid-level-to-senior-l4-to-l5/)
- [Nail Your Promotion: Junior To Mid-Level (L3 -&gt; L4)](https://www.jointaro.com/learning-paths/nail-your-promotion-junior-to-mid-level-l3-to-l4/)

Master The DSA Interview [Part 2] - The Key To Truly Learning DSA

One of the biggest mistakes software engineers make is memorizing content instead of actually understanding the concepts. This lesson teaches you:

- How to learn data structures and algorithms properly instead of merely doing rote memorizations
- What it looks like to truly master a data structures and algorithms problem, shown with an in-depth example
- Common patterns to remember with data structures and algorithms

How To Be An Effective Tech Lead [Part 2] - Why Most Tech Leads Suck

There are far more bad tech leads than good tech leads. But why is that? This lesson teaches you:

- How tech leads struggle when they have bad intentions
- How tech leads struggle when they have good intentions

[Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

- The expectations for an L5+ (senior+ at a FAANG or similar company) engineer are high. You won't get 12 months or even 6 months to fully onboard: You need to start having huge impact and showing your depth within 1-2 months.
- After starting, Alex told his managers that he was happy to offload any responsibilities they had so they could focus on higher-level issues and expand their scope. As a tech lead, you need to view your manager as a partner, not just a boss. "Treat me as a resource."
- The project that Alex was first put on was to make settings more server-driven within Robinhood
- The most impactful thing to do was to add color to the project:
  - Stabilize and then drive the workstream meetings
  - Create a thorough tech spec
  - Align XFN to figure out how to treat each settings section properly, especially in places where there were inconsistencies
- How Alex added his depth:
  - Wrote a 5+ page Android spec for his portion
  - Manually audited all of settings and compiled a detailed spreadsheet of inconsistencies to fully capture impact
  - Thorough data analysis spec, doing complicated SQL queries himself
  - Mentored an L4 engineer in the process, giving them L5 scope
- Recap (how you can incorporate the learnings here into your work):
  - Earn trust quickly: Be "aggressively" nice. Find out how you can add value to others and be very sincere and upfront about it.
  - Fill in the gaps: View your projects holistically and figure out what's missing to move the project forward. This will often times be "less flashy" non-coding work.
  - Bring people together: Don't be paralyzed by your lack of knowledge. Especially if you're new to a company, you will be clueless in a lot of scenarios. If you're in a cutting edge company like Meta/Robinhood, there will be a smart person(s) somewhere out there with the answer: You just need to bring them together in a healthy way.
  - Go deep: There's far more to a senior engineer than their ability to code. If you're a new L5+ engineer, even the tenured L3/L4s at the company will code circles around you in the beginning. If you're an L5+ engineer, figure out what behaviors and fundamentals you have that more junior engineers don't and show those as much as you can. This generally involves shipping software in a much more holistic way.

Related resources:
- [Presentation slides](https://docs.google.com/presentation/d/1j5Lj_IGrtCRUpobj0f8k9egrBAej9apzikGp_V_iTCk/edit?usp=sharing)

Become A Debugging Master [Part 2] - Why You Should Love Bugs

Bugs are often seen as a nuisance, but in reality, they offer one of the highest-impact ways to grow and succeed as an engineer. Here are the core points from the lesson:

- Junior engineers often avoid bugs to chase “cool” feature work, but experienced engineers recognize bugs as critical for making meaningful product impact
- Owning and fixing bugs can accelerate your career growth, even to senior levels like Staff or Senior Staff Engineer, by demonstrating deep technical skill
- Debugging teaches you to dive across teams, codebases, and systems—skills that are rare, valuable, and highly rewarded
- Fixing bugs ensures real, lasting impact compared to feature work, where many experiments and launches often quietly fail
- Mature engineers view the endless supply of bugs as opportunities to create visible, undeniable value by removing problems that directly affect users

Related resources:

- Code quality course: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [Girish Patangay: The billion versions of Facebook you’ve never seen](https://www.youtube.com/watch?v=eXGgc79sGwY)

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

Grow From Senior To Staff Engineer [Part 1] - How This Course Works

If you work hard enough and play your cards right, you will eventually become a senior engineer. However, the same isn't true for staff, and this is why most engineers will never make it to the equivalent of a Staff Engineer at a top tech company like FAANG. Here are the core parts of the lesson:

- Your instructor [Rahul Pandey](https://www.linkedin.com/in/alexander-chiou/) walks you through his extensive 10+ year Silicon Valley background with rapid career advancement, ending up as a high-performing Staff Engineer making +$800k at Meta.
- You'll understand what it means to be a senior engineer vs. a staff engineer in the market, including the interview space.
- We walk you through the course objectives. By the end of the course, you will understand:
  - 💡 Truly understand the **difference** between a senior engineer and a staff engineer (more than a career matrix)

  - 🧠 Create **clear mental models** to develop L6 behavior

  - 📃 Identify your **fundamental gaps** to staff

  - 🗺️ **Chart a path** to Staff Engineer

  - 🧐 Go through Staff Engineer **archetypes** to find your fit

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.