How To Get Real Feedback So You Can Actually Improve

Core points:

- Let the other person know that you treat all feedback as a gift and really appreciate constructive criticism.
- Schedule a 1:1 with crucial people in your org/team to get feedback. It can be every 1 to 3 months. Make it clear that it's a feedback meeting.
- It's important to understand the feedback giver's perspective. Nice people, those you are (hopefully) working with, are going to hold back often by default to shield you. This is why you need to make it clear that you really appreciate honesty and transparency.
- Feedback is crucial towards promotion.

Related resources:

- ["I got some pretty "unspecific" feedback. How can I sharpen it to make more actionable?"](https://www.jointaro.com/question/gKsY3J4x5rz2zdG2OXYJ/i-got-some-pretty-unspecific-feedback-how-can-i-sharpen-it-to-make-more-actionable/)
- ["I work in a small company with no formal perf review system - How can I get feedback to improve?"](https://www.jointaro.com/question/ZkjOqjW2ou4LhJ0HyIIK/i-work-in-a-small-company-with-no-formal-perf-review-system-how-can-i-get-feedback-to-improve/)
- ["How do I find a proper mentor within my company?"](https://www.jointaro.com/question/53nM0O5iemQD5K5ZQkYE/how-do-i-find-a-proper-mentor-within-my-company/)

Master The Behavioral Interview [Part 17] - Staff Engineer

Staff engineer is a level that most engineers never reach (when using the expectations and compensation that FAANG/FAANG-adjacent companies have of Staff). This lesson teaches you:

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

You can learn about Staff Engineer archetypes in our senior -&gt; staff course here: <https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/why-have-archetypes/>

Growth And Promotion 1/6: Course Intro

What's in this course:

- How to ask for promotion and growth
- Helping out to earn trust
- Advanced lessons for any level
- Prioritization

Starting at Amazon as a Senior Manager, then Director, then Vice President, Ethan has had decades of experience at top tech companies. This career growth course is developed from his own knowledge and input from his extensive network of fellow coaches and executives. (See Rahul's interview with Ethan about [**the top 1% of engineers.)**](https://www.youtube.com/watch?v=b6P83dtntKo)

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

[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free

Start with a simple side project and keep iterating on it to separate your side project from the rest.

Related resources:
- [[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)
- [How Alex Made An App That Got 80k+ Users In 1 Month](https://www.jointaro.com/lesson/GlSjjLhuUdHt5drq3l5F/how-alex-made-an-app-that-got-80k-users-in-1-month/)
- ["Finding a mobile app idea - How to do it?"](https://www.jointaro.com/question/KJ4VXh6rUhKbWeiJoRDe/finding-a-mobile-app-idea-how-to-do-it/)
- ["What are some of the side income or passive income sources you can suggest?"](https://www.jointaro.com/question/URhejS9m02tEFM9WLZsd/what-are-some-of-the-side-income-or-passive-income-sources-you-can-suggest/)
- [Presentation Slides](https://docs.google.com/presentation/d/1ai8lxU1B-bH35iiSFf5hvk6NjAHpUyF2rshjyDipvaY/edit?usp=sharing)

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

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

Questions You Can Ask To Evaluate An Engineering Manager

Here are some questions you can ask to engineers on a team to evaluate the engineering manager:
1. How has the manager been able to grow you? How clear is their advice? 
2. Is the team more on the stable or thrashy side? 
3. What has the team struggled with historically? 
4. What has the manager done to uphold work / life balance (WLB) and minimize burnout?

Here are some questions you can ask directly of the manager: 
1. How do you prioritize tasks and projects within your team? Can you walk me through your process for making those decisions?
2. How do you handle conflicts or disagreements among team members? Can you provide an example of a time when you successfully resolved a conflict within your team?
3. How do you ensure that your team members are growing and developing in their roles? Do you have a process for providing feedback and setting goals with team members?
4. How do you measure the success of your team and your individual team members? What metrics do you use?
5. How do you balance the needs of your team with the needs of the company? Can you provide an example of a time when you had to make a difficult decision that balanced those competing interests?
6. How do you stay up-to-date with new technologies and industry developments? Do you encourage your team members to do the same?
7. How do you foster a culture of collaboration and communication within your team? Can you provide an example of a successful collaboration within your team?
8. How do you handle failure or setbacks within your team? Can you provide an example of a time when your team faced a setback and how you supported your team through it?
9. How do you ensure that your team is delivering high-quality work on time? Do you have a process for reviewing and testing code?
10. How do you prioritize work-life balance for your team members? Do you encourage them to take breaks and disconnect from work outside of working hours?

This video is a clip from our masterclass about how to find a good engineering manager. You can watch it here: [[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/)

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

[Masterclass] How To Have Impactful 1 on 1 Meetings

Related resources:
- [[Taro Top 10] Communicating Effectively As An Engineer](https://www.jointaro.com/playlist/yJ6oybePeu93sDSZ1GiQ/)
- [How To Effectively Leverage Skip Level 1:1s](https://www.jointaro.com/lesson/TToehFEc738PBhJcALwL/how-to-effectively-leverage-skip-level-11s/)
- ["Coffee Chat Questions With a Tech Lead - What to ask?"](https://www.jointaro.com/question/jGNZthqhvzYPiMckPEl1/coffee-chat-questions-with-a-tech-lead-what-to-ask/)
- [Presentation Slides](https://docs.google.com/presentation/d/1O1bUrK1NgyfYoMkIqCFJ0SvXv-IQlPhP1gYzBp95abU/edit?usp=sharing)

Struggling With DSA? Don't Worry, That's Healthy!

True or false: Interviewing is all about how much you know. As long as you study a lot and understand enough material, you will pass the interview.

For almost everyone, what does the learning curve look like for data structures and algorithms?

True or false: It's completely normal and even a good sign when you feel dumb while studying data structures and algorithms.

What's the most important piece when you're learning data structures and algorithms material?

True or false: If you aren't making progress on data structures and algorithms after 2 months, your mind probably just isn't geared to understand them. At that point, you should be practical and just look for interviews that don't have these kinds of problems.

Mastering data structures and algorithms (colloquially known as "DSA") is a frustrating experience: It requires such a different type of thinking and is rarely required on the actual software engineering job. This is why if you want to get good at DSA, you need the right mentality first.

Here are the core points from the video:
- DSA learning is an exponential process. You are going to be terrible initially, and eventually things will start to "click" once you hit the inflection point.
- When you feel dumb, understand that this is completely natural: This is almost a good thing as it's entirely expected.
- DSA is very much an input-driven exercise. Build a good process around studying it regularly and commit to it. With constant persistence, you will eventually get to where you want to be!

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

Amazon Behavioral Interview [Part 1] - Intro

This video introduces a mini-course designed to help viewers master behavioral-based interview questions, commonly used by top companies like Google and Amazon.

- **Focus:** The course emphasizes a framework and process to effectively answer these questions, drawing on the instructors' extensive experience (one was a Google interviewer, the other an Amazon Barraiser).
- **Benefits:** By learning this approach, viewers can confidently handle any interview, reduce stress, and significantly increase their chances of landing their desired job.
- **Content:** The course includes downloadable worksheets and other resources to guide viewers through the process of mastering the "STAR" method (Situation, Task, Action, Result) for answering behavioral questions.
- **Instructors:** The instructors have a combined wealth of experience in interviewing and being interviewed at top companies, ensuring the course provides valuable and practical insights.
- **Goal:** The ultimate goal is not just to teach the STAR method, but to boost viewer confidence and significantly improve their chances of success in job interviews.

Learn more about Alan's job search program, Kadima Careers, using this [discount link](https://signup.kadimacareers.com/mQBsDvu).

One Diff, One Thesis - What Every Code Review Should Be Like

In this segment, we focus on the powerful practice of **“One Diff, One Thesis”**, along with a recap of three foundational principles for writing high-quality diffs. These habits dramatically improve your velocity, code quality, and perceived maturity as an engineer—especially early in your career.

### Key Takeaways:

- **We follow the “One Diff, One Thesis” principle**: Each code change should focus on a single, clearly defined purpose. Large, unfocused diffs (e.g., 5,000+ lines) dilute review quality and lead to blind approvals or unclear feedback.
- **We break big features into smaller, stackable diffs**: By submitting changes in 50–250 line chunks with logical dependencies, we keep discussions focused, reduce cognitive load for reviewers, and maintain a clear project history.
- **We pay the “20-minute tax” for high-quality diffs**: Investing time in writing strong context, test plans, and clear, focused diffs pays off by dramatically speeding up approvals and reducing iteration cycles.
- **We see these habits as promotion-worthy**: The most common reason junior engineers struggle during performance reviews is neglecting these basics. Conversely, those who consistently apply them stand out and accelerate their growth.
- **We optimize for long-term velocity and trust**: Thoughtful, well-structured diffs help reviewers engage more quickly and confidently, enabling faster delivery and demonstrating leadership-level attention to detail.

These three practices—**providing strong context, writing solid test plans, and submitting focused diffs**—are low-effort, high-return habits that every engineer, especially early in their career, should master.

Making The BEST Case For Yourself In Performance Review: The Self Review

- Your self-review is the most important feedback for you come performance review season: Ignore the weirdness you may feel hyping yourself up and take it very seriously.
- The onus for representing yourself well falls mainly on you, not your manager or peers. Nobody knows you better than you. It's your job to make sure that none of your awesome achievements fall through the cracks.
- Start your self-review early and refine it across several iterations with your manager.
- Use [your brag journal](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/brag-journal/) to seed the self-review.
- Show the impact. Attach links to proof as much as you can (e.g. linking a dashboard with positive metrics to show that the project you launched added business value).

Related resources:

- ["How can I most effectively talk about my projects?"](https://www.jointaro.com/question/c0CDYi5VCRXz0gHHLiGP/how-can-i-most-effectively-talk-about-my-projects/)
- ["How to figure out what the most important projects are?"](https://www.jointaro.com/question/CgCPA60bDDHoOteN7Lmb/how-to-figure-out-what-the-most-important-projects-are/)

Break Into Tech And Become A Software Engineer [Part 1] - Intro

In this lesson, we explore how anyone can transition into a tech career, regardless of their background.

This lesson covers:

- Brian's journey from a troubled past to becoming an engineering manager and business owner
- How his late start in tech, at age 30, began with small interactions while driving for Uber
- The decision to attend a coding bootcamp, where his passion for coding took off
- The importance of support from friends and community in learning to code and landing a first job
- The idea that people from all kinds of backgrounds, including those with difficult pasts, can break into the tech industry

If you need extra help breaking into tech, join Brian's exclusive, cohort-based bootcamp (just 10 students per batch). Use this link for Taro users for $800 off: <https://www.parsity.io/taro>

Connect with Brian on LinkedIn: <https://www.linkedin.com/in/brianjenney/>

How To NOT Learn A Codebase

The biggest mistake engineers make when going into a new codebase is to excessively read through the code and documentation. This is a horrible way to learn. 

The problem is exacerbated because the supporting documentation of the code is usually out-of-date: the docs can't keep up in a fast-moving tech company.

Instead, just dig in and start coding!

- Break things
- Add all the print statements ever
- Get the debugger working
- Run the code and see what happens

The key takeaway is that you should **get your hands on the keyboard** (even if it's uncomfortable).

DSA Crash Course [Part 7] - Big-O Examples Lecture

In this lecture, Alvin shows examples of code with different Big-O complexities.

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

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>

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)

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

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

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.