Master The Behavioral Interview [Part 22] - Do Mock Interviews

Software engineers love working and studying solo, but this is extremely difficult with behavioral interviews. This lesson teaches you:

- Why behavioral interviews are inherently collaborative and effectively require mock interviews to master
- How to get the most value from your mock behavioral interview sessions

Master The Behavioral Interview [Part 14] - Junior Engineer

Every software engineer starts off as a junior engineer. Junior engineers can't really do anything, but they still need to do pass interviews. This lesson teaches you:

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

Master The Behavioral Interview [Part 10] - When You Don’t Have An Answer

If you're an earlier-in-career software engineer, there is a very high chance that you will get a behavioral interview question where you don't have an answer. This lesson teaches you:

- How to gracefully and immediately react when you get a behavioral interview question asking for a scenario that you have never been in before
- Backup options that you can present to the interviewer to still answer the question despite not having an answer that 100% fits

Managing Up: Enabling Managing Up to You

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

Ethan's other courses on Taro: 

- <https://www.jointaro.com/course/the-growth-and-promotion-recipe-magic-loop/>
- <https://www.jointaro.com/course/maximizing-a-severance-package/>

Managing Up: Politics and Ethics

Managing Up: Skip Level Leaders

Managing Up: Senior Peers

Negotiation Course: Don't Give A Number First

The most important rule of negotiation is "Don't give a number first." Don’t talk about what compensation you’re expecting, and definitely don't share what you were making at your last job. 

It’s actually illegal in 22 states for recruiters to ask about your prior compensation (CA, NY, IL): <https://www.hrdive.com/news/salary-history-ban-states-list/516662/> 

Because of the info asymmetry we talked about before, there’s no benefit to you sharing a number, but a lot to lose. Henry Ford (the automaker in Detroit in the early 20th century) illustrated this well. He employed a tactic called "highball negotiation" where he would match the offer given by a landowner, even if it was inflated. Read more about this in "[The People's Tycoon: Henry Ford and the American Century](https://www.amazon.com/Peoples-Tycoon-Henry-American-Century/dp/0375707255)" by Steven Watts

Example dialog from the recruiter:

> We really need a number before proceeeding”

Sample candidate reply:

> At this time, I’m more focused on determining if the role is a good fit. I’m confident we can figure out an agreeable number once we mutually agree that we could work together.

Negotiation Course: Misconceptions Around Negotiating

Given how taboo money + compensation is, there are unsurprisingly many misconceptions about negotiation. Here are 3 common lies you may have heard about negotiation:

**Myth #1**: *"Your offer will get rescinded if you negotiate."* Companies will never rescind your offer for simply negotiating if you do it in good faith and you're not lying about it. Once you’ve gotten to the offer stage, the company has invested many hours of time evaluating you, so it'd be irrational for them to withdraw the offer simply because you're curious about the compensation package.

**Myth #2**: *"Negotiation makes you look cheap."* In fact, quite the opposite. Negotiating effectively shows that you're a high-value candidate, and that you understand the value you're bringing to the company. 

**Myth #3**: *"Someone will get less if you get more."* This is not how tech job offers work. The technology industry (at least the VC-backed companies that employ the majority of people) is focused on rapid growth. These companies are generally more concerned about growth rather than trying to save money through small compensation adjustments.

File all this under fake news!

Nail Your Promotion As A Software Engineer [Part 22] - The Project Credit Formula

You have been given your projects for the performance review cycle, and they're okay but not amazing. How can you make the most of this opportunity and cobble together a case for promotion? This lesson teaches you:

- The definition of scope, another tech term that is commonly thrown around but horribly misunderstood
- The overall formula to determine how much credit you get for a project
- How to be creative and get the most credit from every project you work on
- How projects of a certain scope can either by increased by 1 level or decreased by 1 level

Ace Your Tech Interview As A Software Engineer [Part 29] - Don't Get Downleveled

Downleveling is something many software engineers aren't aware of when they enter the industry and immediately start idolizing FAANG. It's a brutal phenomena that absolutely needs to be accounted for during your software engineer interview job search. This lesson teaches you:

- What downleveling is and why it's so common among Big Tech companies
- How to avoid getting downleveled in the interview process, both the easy way and the hard way
- General frameworks to understand the differences between the core engineering levels of junior, mid-level, senior, and staff at Big Tech companies

To develop a much better understanding of engineering levels at top tier companies, check this out: [\[Taro Top 10\] Understanding Engineering Levels](https://www.jointaro.com/playlist/e9rjATPbSyvRPsukXiHn/)

Ace Your Tech Interview As A Software Engineer [Part 23] - Data Structures And Algorithms (DSA)

Data structures and algorithms (otherwise known as DSA) - We've all heard of them before. For many software engineers on the job hunt, it is the bane of their existence (and for good reason). This lesson teaches you:

- When to expect DSA problems during the interview loop
- How DSA problems came to take over the software engineer interview
- Why FAANG and Big Tech companies overall use DSA interviews so aggressively (hint: it's not because they're stupid)

To master the data structures and algorithms interview, check out these resources:

- [\[Course\] Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)
- [\[Taro Top 10\] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)

Level Up Your Code Quality As A Software Engineer [Part 22] - Too Many Comments

Comments is a coding technique everyone learns particularly early, which makes sense as newbies need the extra hand-holding. However, there's a weird phenomenon where code comments go from a good thing to a bad thing very rapidly in your career. This lesson will teach you:

- Why comments are so prolific across code
- How comments end up hurting rather than helping, especially at scale and with large codebases
- What you should do instead of adding a bunch of code comments
- The fundamental mentality around writing good, clean, readable code, which Alex breaks down with a concrete refactoring example

System Design Series: Taro Playlists [Part 9] - Thinking Into The Future

You can find the full [system design doc here](https://docs.google.com/document/d/15WaM8Ojan82g0m2mtz6kC2Hiyj0Q6VbjfqRmVNDI3qw/edit?usp=sharing) - Feel free to use it as a template for when you are doing a system design at your job!

The system design tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

- Products are rarely shipped in isolation: You will almost always iterate on them in the future, extending them and adding new features.
- You should always take some time to think into the future for your project. The amount of time you take will vary a lot based on situation, but it generally plays out like this across company types:
  - **Smaller companies and startups**: Spend less time as goal is to ship, and it's unclear if the company will survive to even iterate.
  - **Big Tech/FAANG**: Spend a lot of time as these companies need to think long-term to maintain their massive market presence.
- When coming up with future iterations during your system design, order them by likelihood of doing and level of priority.
  - Spend more time thinking through the scenarios at the upper end of the list and incorporate them into your system design if they are very likely to be done in the next couple months.
  - Your goal is avoid a scenario where you need to extend your system shortly after it's launched, but it's so brittle and fragile that you would need to rewrite huge swaths of it to accommodate the new use-cases.
- However, this is a failure mode on the opposite extreme and that is being unreasonably forward thinking and over-engineering your system as a result. Making a protocol more generic and scalable almost always takes more time.
- When building systems or services, seriously think about the assumptions you are making.
  - Will the input this API takes in always be in this format and have certain fields?
  - Will this hard-coded if-statement start blocking valid control flows in the future?

Make Sure To Set This Up With Your Manager To Ace Your Performance Review

- Work with your manager to figure out which peers you should request feedback from at the end of the cycle: They may already have a bunch of peers in mind!
- Once you figure out these key peers, talk with them upfront about your goals, especially if they're ambitious and you're gunning for promotion. Work with them early to build this relationship, especially if they're more senior.

[Part 8] Meta Intern Success Series - Rahul's Internship + Current Economy

I interned at Meta in the summer of 2013 (it was called Facebook in my day…). I barely got the return offer at the end of the summer. My reflections on what I could have done better: 
- Too much back and forth on my code review. I made the same types of mistakes in the code I wrote, and I occasionally tried to pushback if a reviewer requested changes. 
- Not communicating with enough with teammates. In addition to my intern manager, I should have had a regular 1:1 with the person who was primarily reviewing all my code. 

What I did well: 
- I was responsive. I replied to messages + comments quickly, and I tried to share my insights (from my project) where possible.. 
- I was a good culture fit: I built a substantial hackathon project which garnered some attention.

Advice for the current economic condition for software engineer interns: 
- Focus on cultivating relationships with people on your team, so they are able to refer you. 
- Leverage the work you did in Meta to more easily land interviews at competitive companies.

[Go back to part 1 of the Meta intern series](https://www.jointaro.com/lesson/DPcsvbf5IKk57xcqyiAC/part-1-meta-intern-success-series-internship-program-overview/)

What To Do If You Don’t Mesh Well With Your Manager

Signs Of A Bad Engineering Manager: Reactive vs. Proactive

The Engineering Manager "Partner In Crime": The Tech Lead

Don't Forget: Code Review Is Public And Has Huge Consequences

In this final segment, we emphasize how **code review is not just a technical exercise—it’s a public, cultural signal**. Especially for tech leads and senior engineers, the way feedback is delivered in code review has real consequences for team morale, inclusion, and career development.

### Key Takeaways:

- **We treat code review as a public cultural forum**: Comments are visible to others on the team and can impact how engineers—especially juniors or new hires—are perceived. Feedback that embarrasses someone publicly can harm confidence and even affect performance reviews.
- **We avoid harsh criticism in public threads**: If we’re truly concerned about someone’s patterns (e.g., lack of testing mindset or carelessness), we give that feedback in private, not in a code review. We follow the rule: *Praise in public, critique in private.*
- **We understand the leadership signal we send**: As tech leads, our tone sets the bar. If we leave demoralizing or curt comments, we implicitly encourage others to do the same—fostering a negative or toxic culture.
- **We handle serious feedback face-to-face**: When needed, we schedule a quick 15-minute conversation to deliver constructive criticism with nuance and care—ensuring it’s received in the spirit of growth, not shame.
- **We use code reviews to build people up, not tear them down**: Every interaction is a chance to create a safer, stronger engineering culture. We remember that what we say—and how we say it—has lasting impact.

Ultimately, we believe that **code review is leadership in action**—and great leaders use it to uplift their teams, not diminish them.

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.