Rahul's Compensation Journey To $800K (and behind-the-scenes)

In 2021, the last full year Rahul worked at Meta, he made $823K. When he joined Facebook (Meta) in 2017, his total compensation was $390K. See the full details [in the YouTube video](https://youtu.be/inydj1VZ0y0).

In this session, Rahul documents how his yearly compensation more than doubled over the 4.5 years he was employed at the company. This talk will cover details that didn't fit into the YouTube video while exploring angles of it more in-depth.

Topics:

- What components of compensation matter the most in a typical tech company
- Parts of a company's compensation philosophy which have large consquences, but are not often understood or discussed
- How to think about level and negotiation when job hopping
- The psychology around pay changes, and how people change their spending when hitting certain compensation milestones

Related content:

- [How To Earn Respect Fast - Senior Engineer Onboarding Story](https://www.jointaro.com/lesson/FaD8tVGXP6SiRQfee4SD/how-to-earn-respect-fast-senior-engineer-onboarding-story/)
- ["How can I think like a staff engineer?"](https://www.jointaro.com/question/RU3Mof8NeEYQP30l6giW/how-can-i-think-like-a-staff-engineer/)
- [This Is Why FAANG Engineers Make So Much Money - Tech Compensation Breakdown](https://www.jointaro.com/lesson/1aKjiSKcHDttnyTAYXy4/this-is-why-faang-engineers-make-so-much-money-tech-compensation-breakdown/)
- [\[Masterclass\] Understanding And Optimizing Your Pay In Tech](https://www.jointaro.com/lesson/gk408yBIV2fa5RjVR213/masterclass-understanding-and-optimizing-your-pay-in-tech/)

Write A Stellar Resume As A Software Engineer [Part 10] - Fancy Formats

Creativity is great, and it's a very important skill for software engineers. However, the resume is not a medium for creativity to thrive. This lesson teaches you:

- Why "creative", fancy resume formats are really bad for a tech resume, shown through a very eccentric example
- The principles to follow for a great resume format
- What a resume with an optimal format looks like with a real-life example

If you need inspiration for your resume format, you can use Alex's template as a template. Download it here: [Alexander Chiou Resume.docx](https://docs.google.com/document/d/1NnAx2jYkRTMCQwbdDPPqSj1Fwxkahda-/edit?usp=sharing&ouid=109380646850979301783&rtpof=true&sd=true)

[Become A Go-To Person 2/18] What Industry Experts Say

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

Master The Behavioral Interview [Part 15] - Mid-Level Engineer

Mid-Level engineers are engineers who have a good amount of experience but aren't exactly senior yet. Most software engineers fall into this bucket. This lesson teaches you:

- The expectations from a mid-level engineer overall and how that reflects in behavioral interviews
- The kinds of stories mid-level engineers tell in behavioral interviews

A Framework For Integrating AI Into Your Workflow

> **AI will not replace you. A person using AI will.**

This [tweet](https://twitter.com/svpino/status/1610984481342771200) was seen 5M times because it captures a transformation that will happen in the workplace over the next 5 years.

This video covers a practical framework to apply AI tools like ChatGPT, Bard, or Github Copilot to become more productive in your job.

The goal for many of us is to become the mythical **10x engineer** – they have 10x as much impact as their peers. These engineers do exist, but they don’t write 10x more code or fix 10x more bugs. Instead, they understand the concept of leverage, which manifests in two ways.

- Take a challenging problem, and solve it in a 10x or 100x better way
- Make 10 or 100 people around you more productive

Shreyas Doshi has a [framework called LNO](https://www.aakashg.com/2022/02/01/lno-framework-for-product-managers/) to identify where you should spend your effort:

- *Leverage (L)* tasks are tasks that have huge consequences and you should do a great job.
- *Neutral (N)* tasks are tasks that are important, but don't have a big payoff. You should do a good job.
- *Overhead (O)* tasks are tasks that are a tax on your time. You should just get it done.

Let's go through an example in each bucket:

In the **leverage** bucket is creating the design or architecture for the project. This is high leverage not only because architecture is inherently difficult to change, but it’s also an important trust-building exercise.

- Ask AI to identify what could go wrong with your general approach and then add that as a discussion.
- Ask AI to summarize documents related to what you’re trying to build
- Ask AI to solve the problem and then sanity-check. The results here won’t always be good, but at least you should be able to explain why you’re choosing one path over the other.

Some coding tasks are in the **neutral** bucket. AI gives us the opportunity to dramatically speed up how long some coding tasks take.

- Use tools like Copilot to write boilerplate code much faster
- Instead of having to go to StackOverflow, you can get answers inline
- Ask for things like regexes or how to do something in idiomatic Kotlin

Finally, there are tasks in the **overhead** category that AI can help minimize

- The classic example is writing your performance review – you’re not actually having any business impact.
- I recommend every engineer has a [brag document](https://www.jointaro.com/lesson/QVqPkuCvplbHSqBWtKJX/make-your-promotion-case-easy-keep-a-brag-journal/) of what they did throughout the half or year. Then you need to massage all your work into whatever template your company uses.

With the rise of AI, asking good questions is more important than ever. Artificial Intelligence cannot read your mind (at least not yet 😅), so the quality of your question dictates the quality of your response. Learn more about asking good questions with our course: [\[Course\] Ask Great Questions That Get Great Answers Quickly](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/)

Ace Your Tech Interview As A Software Engineer [Part 27] - Hiring Manager Round (Separate)

Congratulations, you went through the onsite loop and did well! But what's this - The engineering director behind the job you're interviewing for wants to talk? This lesson teaches you:

- When separate hiring manager rounds happen (and why that's a good thing)
- How to pass hiring manager rounds and what to expect from them

Grow From Mid-Level To Senior Engineer [Part 16] - Project Management

Planning a project is just the first step: Execution is when things really matter. The problem is that every software engineer leading a project should expect the unexpected, especially at a top tech company. This lesson teaches you:

- How senior engineers set themselves apart when leading projects
- The core ingredients for successfully managing a project, both during and after execution

Related resources:

- ["What are some thoughts on maintaining good meeting hygiene?"](https://www.jointaro.com/question/CModSkZ4LWzw9bdaiakt/what-are-some-thoughts-on-maintaining-good-meeting-hygiene/)
- ["How to get more visibility on work?"](https://www.jointaro.com/question/XA0X51AypDLCeVeleJv4/how-to-get-more-visibility-on-work/)

Nail Your Promotion As A Software Engineer [Part 8] - Avoid Level Overload

Not all teams are created equal when it comes to promotion opportunity, far from it in fact. Don't sleep on this crucial angle when it comes to planning out your promotion plan as a software engineer. This lesson teaches you:

- The 2 types of level overload to avoid and which one is worse
- How to a team that has a healthy mix of levels vs. one that doesn't
- Why level overload is bad, particularly when there's a lot of engineers at the same level you are

Grow From Senior To Staff Engineer [Part 11] - Define The Roadmap

All the way to senior, engineers are almost entirely given projects to work on. This dynamic flips as you grow from senior to staff. This lesson teaches you:

- The differences between senior and staff engineers when they participate in the team roadmapping process
- The skills you need to become a leading, staff-level influence in roadmapping

Grow From Junior To Mid-Level Engineer [Part 7] - Code Review

As a mid-level engineer, it's not enough to write good code yourself - You need to help others write good code as well. This lesson teaches you:

- How junior and mid-level engineers differ when it comes to code review quantity, shown with concrete Meta numbers
- The difference between a junior engineer code review comment vs. a mid-level engineer code review comment, explained with an in-depth example

Get better at code review with our masterclass: [\[Masterclass\] How To Do Amazing Code Review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/)

Grow From Senior To Staff Engineer [Part 8] - Create Scope

The best engineers don't need to be told what to do. Creating scope is a behavior that usually develops as an engineer hit senior, and it's sharply refined as they grow to staff. This lesson teaches you:

- Why staff engineers often write less code than their senior engineer counterparts
- The difference between senior and staff engineers when it comes to creating scope
- A trap senior engineers often fall into when trying to creating scope
- The more graceful way competent staff engineers create scope within their organizations

Watch Rahul's internal tool case study here: [\[Case Study\] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story](https://www.jointaro.com/lesson/qvp2quodqAEWSkN7sayt/case-study-building-a-meta-internal-tool-to-empower-an-entire-org-staff-promotion-story/?playlistId=EWIo3USNcsgXbCs5PS0h)

Code Review MUST Be Fast, Otherwise The Team Is Unhealthy

In this final segment of the video, the speakers reflect on the crucial role that **code review turnaround time** plays in engineering culture, team productivity, and developer happiness. Timely reviews are not just a technical necessity—they reflect the team’s values and operational discipline.

- **We treat code review turnaround time seriously.** Our standard should be to review diffs within *one day*, two at most. Slow feedback cycles—especially taking 4–5 days—compound and slow down overall delivery velocity.
- **We recognize code review as a gatekeeper with real power.** Since all production code must pass through this step, bottlenecks here can deeply affect morale, productivity, and team trust.
- **We advocate for clear team expectations.** When reviews consistently lag, we push for a shared SLA (Service Level Agreement) around review times, ensuring accountability and smoother planning.
- **We balance urgency with respect.** While prompt reviews are key, we also avoid pestering reviewers within minutes of submitting. Giving at least 6 hours (unless it’s urgent) is a sign of maturity and respect.
- **We proactively build good habits.** Many of us block time at the end of our day to batch and respond to review requests, which helps us maintain velocity without excessive context-switching.

Onboarding Tips Within Smaller Companies

Some relevant tips if you're onboarding as an engineer in a smaller company:

- Smaller companies will have less process and, therefore, a less formal onboarding. This means it's more important to get stuff done quickly since you can't rely on a bunch of classes or hand-holding.
  - A good benchmark is to land code within a week
- In a smaller company, a lot of knowledge will be in the heads of a few people
  - Your goal is to find the tenured people and ensure you understand their worldview and prioritization.
- Don’t assume processes or people exist. Especially if you come from a larger company, you should not assume that there is a well-defined QA (Quality Assurance) team or design team.

DSA Prep Is One Of The Highest ROI Activities On Earth

If you do a good job studying for your data structures and algorithms interview, you can set yourself up financially for the next few years.

Related resources:
- [[Taro Top 10] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [[Taro Top 10] Finding A Tech Job](https://www.jointaro.com/playlist/E6R0wVJ5EyCfVnVrlfno/)

One Of The Biggest Tech Career Killers: Not Being Truly Great With Feedback

Feedback is the primary fuel for you to improve. Despite this, most engineers (and most people in general) are far worse at taking feedback than they think they are.

Here are the core points from the video:
- **Be very appreciative of your manager's feedback** - Your manager is the main source of feedback for you (it's literally their job). Your goal is to create a virtuous cycle where your manager wants to keep giving you feedback as you make the experience smooth.
- **Be accepting of non-perfect feedback** - It is very rare for feedback to be 100% accurate. Search hard for a kernel of truth in the feedback, and if you can find it, you should cherish that overall feedback.
- **Be extremely careful being defensive** - This is a 1-way door. Sharing feedback is awkward. If your response to getting feedback is to make the situation weird and be the slightest bit defensive, that person will likely never give you feedback ever again.
- **Ingesting feedback has a high skill ceiling** - It's way, way, way higher than almost everybody thinks. The most talented engineer Alex ever worked with got promoted from E3 new-grad to E6 (Staff) at Meta in less than 3 years. One of the main reasons behind that stellar growth trajectory is that they were able to process feedback extremely efficiently, almost always implementing it the week after they got it.

Related resources:
- ["Can someone elaborate on "always treating feedback as a gift"?](https://www.jointaro.com/question/4DoEnMIq2ISadfAJuwp9/can-someone-elaborate-on-always-treating-feedback-as-a-gift/)
- [[Taro Top 10] Software Engineer To Engineering Manager (IC -> M Track)](https://www.jointaro.com/playlist/oz0mnJvHHgM8NfVF7rgp/)
- [[Masterclass] What Software Engineers Should Look For In Their Engineering Manager](https://www.jointaro.com/lesson/oeY7ncZhzJ5NO6dij5e7/masterclass-what-software-engineers-should-look-for-in-their-engineering-manager/)

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

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

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

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

Build Deep Relationships Quickly In Tech [Part 21] - Go Deeper: Follow Through

Related courses:

- [Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [Ask Great Questions That Get Great Answers Quickly](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/)

Maximize Your Productivity As A Software Engineer [Part 20] - Just Jump In

If there's one thing software engineers love to do, it's prepare. They'll read and watch and listen to countless resources in order to get "ready" to tackle their meaty technical challenges. This lesson teaches you:

- Why "preparing" to do a task is basically the same as doing nothing
- The right mentality you must have to tackle any software engineering task efficiently, going away from the mindset that got you through school
- How to effectively dive into a task and get it done fast

Nail Your Promotion As A Software Engineer [Part 23] - Sell Yourself, Claim Your Wins

So many software engineers don't realize that perception and reality are 2 very different things that often drift apart. The painful truth is that perception is far more important than reality. This lesson teaches you:

- How software engineers can do amazing work but their teammates actually think they're mediocre
- Why you need to put in the work to get full credit for your work, especially for promotion
- Why you shouldn't only wait for huge launches to communicate progress
- Which mediums to use when it comes to sharing progress updates
- The many benefits of high-quality project updates

For more concrete tactics on writing a top-notch project update, check this out: ["How to get more visibility on work?"](https://www.jointaro.com/question/XA0X51AypDLCeVeleJv4/how-to-get-more-visibility-on-work/)

Grow From Senior To Staff Engineer [Part 5] - Finding The Right Team

As a senior engineer, you can work hard and do everything right and still not have a real case to get promoted to staff engineer. This lesson teaches you:

- Why certain teams are far better for a staff engineer promotion than others
- What you need on a team from a seniority perspective to get to staff
- Why it's important for a team to have engineers more junior than you to grow to staff

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.