1 on 1s Are The Time To Be Awkward

Why should you be awkward and even a little bit uncomfortable in 1 on 1 meetings?

True or false: 1 on 1 meetings are great for staying in sync, so status updates are one of the best things you can talk about during them.

Which of the following are good things to talk about in 1 on 1 meetings?

The 1 on 1 meeting is one of the most important usages of time in the workplace. Even the most junior engineer will generally have at least a 1 on 1 meeting series with their engineering manager. However, 1 on 1 meetings are often completely wasted by software engineers - Here's how to avoid that.

Here are the core points from the video:

- 1 on 1 meetings are the most inefficient way to communicate anything that is non-controversial
  - The main culprit here is detailed status updates. If you're using the majority of the time to share these and talk tactics, you are doing 1:1s wrong.
- The most effective way to leverage 1:1s is to talk about things that are *awkward and maybe even make you uncomfortable*. Here are some examples of "awkward" topics:
  - Feedback to improve
  - Emotions (both positive and negative)

Related resources:

- [\[Course\] Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [The Art of the Awkward 1:1](https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c)

A Huge, Often Unused Way Your Manager Can Help With Promotion

- Your manager is critical to your promotion. More specifically, if your manager is not supportive of your promotion case, it is near impossible for you to get promoted.
- You need to create a plan with your manager as soon as the performance review cycle starts to set expectations on what you need in order to be a good candidate for promotion. It should be modal and detail the following:
  - What it means to meet expectations
  - What it means to exceed expectations
  - What it means to totally crush expectations
- Regularly work with your manager to get feedback and understand your progress for this plan

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

How To REALLY Level Up Your Coding Ability With Side Projects

There is no secret to getting better at coding: As a software engineer, you will become faster at coding when you write more code. This is where side projects can really come in.

Here are the core points from the video:
- **Side projects are a productivity "hack"** - They allow you to write more code without overworking yourself. The self-guided, free nature of side projects essentially make them a hobby that also helps your performance at work.
- **When to consider side projects** - There are 2 factors that make this lever far more powerful:
  - You work at a startup: Startup code will be much more "vanilla" and closer to the code you find online. This means that it won't be too different from side project code.
  - You work on the front-end: If you're a web/iOS/Android developer and are working with pixels on screen, this puts you in a great position to do side projects as your work is inherently more sharable.
- **Side projects develop other important skills** - On top of raw coding, side projects also help you dabble in the skills of product managers, designers, data scientists, user researchers, and a whole lot more since you own the product entirely. These skills are also important for software engineers, especially those pursuing senior levels.

This highlight is from our masterclass about becoming a better coder. You can watch the full video 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/)

Related resources:
- [[Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free](https://www.jointaro.com/lesson/AI4zi759PSGn6RwIFT6f/masterclass-how-to-come-up-with-100k-users-app-ideas-you-can-build-for-free/)
- [[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/)
- ["What technologies or stacks should I create a project to add in my resume for entry level software jobs?"](https://www.jointaro.com/question/c0DiG5ureLbkZ1mKD9Rf/what-technologies-or-stacks-should-i-create-a-project-to-add-in-my-resume-for-entry-level-software-jobs/)

What Software Engineers Don't Get About Clean Code

Back at Instagram, Alex was able to grow very quickly. This was largely due to his coding ability. In his 1st half at Instagram, he pushed \~125 commits to production. In his 2nd half, he pushed \~185 commits to production. In his 3rd half, he pushed \~275 commits to production, making him a Top 5 code committer within his org of 50+ software engineers.

Here are the core points from the video:

- **You don't need to sacrifice quality for velocity** - This is one of the biggest misconceptions about code. You can both write a lot of code while keeping the polish high. In fact, high code quality and velocity naturally go hand-in-hand.
- **Messy code is a defining trait of a weak SWE** - 99% of bad software engineers have poor code quality, and conversely, you will rarely meet a high-performing software engineer that puts out messy code. Optimizing your code quality is one of the most powerful ways to avoid being a low performer, especially if you work at FAANG or Big Tech in general where the scale and stakes are much higher for code.
- **80/20 rule applies to code quality** - It usually doesn't make sense to cover 100% of edge cases, but you can generally cover \~80% of them with \~20% of the maximum effort, even if you're a tiny startup. Don't make excuses for broken, unreadable code by saying "We have to move fast"; strive to find that 80/20 path.

Related resources:

- ["What's the difference between a low performer software engineer and a high performer?"](https://www.jointaro.com/question/nMxx2EMVIlJbl1oK4SGu/whats-the-difference-between-a-low-performer-software-engineer-and-a-high-performer/)
- ["How can I write great code faster?"](https://www.jointaro.com/question/ciE9a2TZ7rZNyYP8HbeJ/how-can-i-write-great-code-faster/)

Code Review Is NOT For Catching Bugs

In this follow-up video, we dive deeper into the **true purpose of code review**, challenging the misconception that its main goal is to catch bugs. Instead, we emphasize how code review plays a central role in shaping team culture, accountability, and knowledge sharing.

### Key Takeaways:

- **We see code review as a cultural engine**: It’s a key mechanism for how our team communicates, transfers norms, and builds a shared understanding of quality and standards.
- **We’ve learned that code reviews aren’t about bug-hunting**: Studies—including from Microsoft Research—show that code reviews are not effective at finding bugs, even with multiple reviewers or approval layers.
- **We hold ourselves accountable for our code**: The responsibility for quality and testing lies with the author—not the reviewer. Code review isn’t a safety net for catching functionality issues.
- **We avoid over-reviewing**: Adding more layers of review slows us down without meaningfully reducing bugs. Instead, we focus on meaningful reviews that support learning and alignment.
- **We use code reviews for knowledge and culture transfer**: Through thoughtful feedback and shared context, we reinforce how we build, think, and collaborate—making code review a vital part of team growth.

Why You Should Start Your Career At A Big Tech Company

- **There's no universal right answer to which company works best for you** - At the end of the day, you should figure out what you care about and what your goals are and work backwards from there. It's entirely possible that Big Tech isn't a good fit for you.
- However, in a vacuum, you should start your career at a Big Tech company if you can. The main reason is that Big Tech is generally quite good at adding a layer of consistency to your career.
- You will probably learn a lot about writing good, scalable code as these companies know how to build massive systems and hire smart people.
- Your compensation will be very competitive, making it easier to negotiate proper pay and level at future jobs.
- You will probably develop a decent suite of fundamental soft skills as you need to learn how to work with many stakeholders to succeed at Big Tech.

How Neetcode Got Promoted From L3 to L4 (Mid-Level) Engineer At Google - Tips + Insights

Neetcode struggled with unemployment as a fresh college graduate in 2020. To prepare for interviews, he started the (now massive) [Neetcode YouTube channel](https://www.youtube.com/neetcode) and landed a job a year later at [Google](https://www.jointaro.com/topic/google/) as an entry-level (L3) software engineer. 

As his first full-time job, Neetcode was unsure if he'd succeed within Big Tech, but he was able to get promoted to mid-level engineer (L4) quickly.

Neetcode attributes his success within Google to 3 elements: 
- **Working independently**: Don't be afraid to try things on your own. You should take advantage of the smart people around you, but you need an attitude of self-sufficiency. That means you should be willing to dive into the code, try out experiments, and read documentation as needed.
- **Soft skills**: Break down the work you're doing to discuss the parts that people care about and be proactive with giving status updates. If you feel like a project may get delayed, be very honest about that with your manager -- communicate what happened and what you're doing to fix it. 
- **Some luck**: Neetcode had a great manager and his starter project turned out to have a larger scope than initially planned. This set him up for the L4 promotion.

Neetcode's (self-assessed) coding skills were average, but he performed better than most L3s due to his ability to work independently and superior soft skills.

**If you'd like a discount on Neetcode Pro, checkout the [Taro Perks](https://www.jointaro.com/perks/) page.**

Related resources: 
- [Learn how Google does performance review](https://www.promotions.fyi/company/google/performance-review)
- [How to work more independently? from an Amazon engineer](https://www.jointaro.com/question/vyIAC3hCmRpiWzzL6SjP/how-to-work-more-independently/)
- [Why You Should Start Your Career At A Big Tech Company](https://www.jointaro.com/lesson/OcWRqQcx31VwIEV6tfWK/why-you-should-start-your-career-at-a-big-tech-company/)

[Masterclass] How To Build Deep Relationships Quickly In Tech

Professional networking is vital for a healthy career, especially as a software engineer. However, many tech workers struggle with building relationships, especially introverts. In this masterclass, we teach you how to improve your interpersonal communication and build meaningful professional connections quickly, which might even make you some work friends along the way.

There were a ton of important points from this masterclass, so here's our Top 5 (in no particular order):

- **You're going to get burned, and that's okay** - Professional networking is just like making friends or dating: You will meet people where it just doesn't work out. Don't let that tear you down and make you cloister up. Move on from those relationships and continue investing in new people.
- **Make them feel special** - Asking someone for a huge favor with some copy-paste message isn't networking: It's begging. The classic example is cold messaging random people for referrals into their FAANG company. If you want any chance of success with a reach out, make sure to deeply explain your background and credibility alongside why you reached out to that specific person in particular - Put them on a pedestal.
- **Understand their incentives** - One of the biggest reasons people fail with networking is that they're entirely caught up in what *they're* looking for, reducing their networking to "*How can I get this other person to give me what I want?"*. Successful relationships are those where each party is able to provide lots of value to one another, and the first step to doing that is to understand what the *other* person wants and what motivates them. When it comes to networking within a company, this is usually tied to what they get rewarded for in performance review.
- **Lead with kindness** - Only helping others when they have already helped you is a recipe for weak, slow-growing professional networks. Kindness is 10x more valuable in building up a relationship when it's unexpected, making the pleasant surprise of helping someone who's never helped you before especially powerful. For a deep dive into this concept (including a story about how Taro cofounders Alex and Rahul met), check out: ["How do you network effectively within a company?"](https://www.jointaro.com/question/DwT9GtdYK9nwFV3a7jrU/how-do-you-network-effectively-within-a-company/)
- **Maximize 1 on 1 meetings** - 1 on 1s are the core engine behind deepening interpersonal communication, and that includes professional ones. Schedule a recurring 1 on 1 if possible with anybody you want to build a deep relationship with, and make sure to use that time well. Embrace [the art of the "Awkward 1 on 1"](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/) to share honest feedback, talk about how you're feeling, and learn who they truly are as a person. To learn more about this, watch this: [\[Masterclass\] How To Have Impactful 1 on 1 Meetings](https://www.jointaro.com/lesson/FEK6JZqW2Jg3rdN9yeGn/masterclass-how-to-have-impactful-1-on-1-meetings/)

Related resources:

- [Alex's Guide To Effective Communication](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)
- ["How do I lead without authority?"](https://www.jointaro.com/question/BWv3hFSELbn59mXJbkNB/how-do-i-lead-without-authority/)
- [What Makes A Truly Great Tech Lead](https://www.jointaro.com/lesson/uHqZZ15SK19MatEvLSO6/what-makes-a-truly-great-tech-lead-a-vp-of-engineerings-perspective/)
- [Presentation Slides](https://docs.google.com/presentation/d/1TDdBRQTGc66T35PzB5SwcJ3HQci_csdy8mzKxQu3law/edit?usp=sharing)

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

3 Mistakes Too Many Software Engineers Make (from a Director at Airbnb)

As Head of Search Engineering at Airbnb, [Rachel Zhao](https://www.linkedin.com/in/rachelzhao/) has coached + mentored many engineers as they climb the ladder. She calls out 3 things NOT to do for software engineers: 

1. **Don't work too hard (for an extended period)** - This leads to burnout, which hampers both your health and your growth. Rachel regularly spends time reflecting and figure out what new skill/project she can take on. You can learn more about the importance of reflection when it comes to productivity in [our video here](https://link.jointaro.com/dXkvKXs4FfbK5V6h7).
2. **Don't say "I'm not learning enough"** - At the end of the day, the company hired you to do a job - Growth is more of a 2nd order priority for many companies. This means that you need to be proactive about owning your growth - Don't just expect your manager to hand you the perfect curriculum of projects to get to the next level. For in-depth advice on how to create that scope for yourself to get to the next level, check out [this in-depth Q&A advice](https://link.jointaro.com/bah6v7RFpnywVYyv9).
3. **Don't focus on the score, focus on the game** - In particular, don't focus too much on level and viewing others as competitors. Think about how your org functions and how you can add the most impact. Check out our in-depth advice on [how to view levels when it comes to your career](https://link.jointaro.com/JJBA5KSCLdoK9Sc39).

How To Effectively Leverage Skip Level 1:1s

Your "skip" is the person that your manager reports to - It's what happens when you "skip" your manager when going up your reporting chain. 1 on 1 meetings with your skip are tricky as you can't talk to them the same way you would to your direct manager:

Here's how you can get maximum value from your skip 1 on 1s:
- **Understand your organization's overall strategy** - Since your skip is operating at a higher-altitude, they will be naturally well equipped to answer this question. Ask them what their priorities are, and you can then weave them into your own work to increase your impact.
- **Share "on the ground" insights** - Skips are generally pretty disconnected from nuts and bolts day-to-day work due to their seniority. As an IC, you are well-equipped to share what that experience is like as that's your life. This is really valuable, if you can come up with insights on how to improve this experience.
- **Be honest with feedback** - There's not much value sucking up to your skip and telling them that they're great and everything is going great because of that. Be candid and unafraid to share real problems with how the organization functions.

Related resources:
- ["How to make the most out of Director/VP/Exec office hours?"](https://www.jointaro.com/question/GSihcOIzyP4sq5Gp1pWb/how-to-make-the-most-out-of-directorvpexec-office-hours/)
- ["Topics to talk in 1:1 with skip level manager?"](https://www.jointaro.com/question/yK1UiPgm1EElzHRIqlM8/topics-to-talk-in-11-with-skip-level-manager/)
- ["What should I discuss in first 1:1 with my skip-level manager?"](https://www.jointaro.com/question/WjBisBXMwLrSGO0mpR56/what-should-i-discuss-in-first-11-with-my-skip-level-manager/)

The #1 Tried And True Tool For DSA Interviews

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

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

[Case Study] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story

- Debugging was a huge pain point for the Facebook Portal org.
- To fix this, Rahul built a tool that made it far easier to debug tricky Android issues (Portal runs a fork of Android). It took all the crazy dump files from Android bugs and extracted the insights.
- Rahul started off the tool with an *extremely* simple interface: Upload the massive dump file and it would extract insights. He would improve it later by making it so the user only needed the bug ID.
- The tool started off with around 100 engineers using it and then grew to 250+! This massive scope was enough to get Rahul AE (additional equity) and a promotion to E6 (Staff at Meta).
- How you can incorporate these learnings into your work:
  - Look internally for opportunity. There are ways to have impact besides shipping flashy products, and in Big Tech in particular, improving engineering efficiency can be a *huge* win given how many engineers there are!
  - Understand the pain of your peers. Not only is this just a kind, empathetic thing to do that builds relationships, pain often comes with opportunity.
  - Think outside your stack. Instead of working forward from your stack of choice and what you can do with that, zoom out and holistically look at problems across your org in general. It's cheap to learn other stacks to build solutions - The main thing to do is identify problems.
- Here's [a link to the slides](https://docs.google.com/presentation/d/1Scxll_pApdPLXk42jSHcrZ4LaTE8_7BUjvB14z9-SgU/edit?usp=sharing).

Related resources:
- [[Case Study] Effective Communication: Leading A Multi-Org Re-architecture At Meta](https://www.jointaro.com/lesson/Rovw6IfITXGr55NdftFw/case-study-effective-communication-leading-a-multi-org-re-architecture-at-meta/)
- [What's the Difference Between A Senior And Staff Engineer?](https://www.jointaro.com/lesson/FzvHLUprcYonudsxnJc2/whats-the-difference-between-a-senior-and-staff-engineer/)
- ["I would like to get more clarity on what a Staff-level project and execution look like."](https://www.jointaro.com/question/RQa5tsnXnZr6Xg1ziv0X/i-would-like-to-get-more-clarity-on-what-a-staff-level-project-and-execution-look-like/)

This Is How You Become A Layoff-Proof Software Engineer

Some software engineers are better equipped against layoffs than others. They are less likely to get laid off, and if they do get laid off, they bounce back faster than everyone else. This video covers how those engineers do that.

Here are the core points:

- **Focus on building up fundamental skills** - Divorce yourself from specific technologies and product spaces. Always be thinking: *"Can I take my abilities to a completely different team/company and succeed?*"
- **Soft skills are very underrated** - Communication, leadership, and project management are skills that are useful anywhere. They are also skills that are almost always required to reach senior engineering levels, especially at Big Tech companies like FAANG.
- **Learn how to do real system design** - This is how you ascend to the higher level, away from the direct code, allowing you to add more value to engineering organizations. To learn how to do real system design (not the trivia you need to know for interviews), watch our course here: [\[Course\] System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

Related resources:

- ["What are software engineering fundamentals?"](https://www.jointaro.com/question/3VNPK7wol76s89EkgFeW/what-are-software-engineering-fundamentals/)
- ["How to develop soft skills like leadership, stakeholder management, etc.?"](https://www.jointaro.com/question/Ivo1RsizAMGoGKXmqg6N/how-to-develop-soft-skills-like-leadership-stakeholder-management-etc/)

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.

What A Test Plan Is And Why Every Code Review Needs One

In this video, we explore the value of including a **clear test plan or demo** with every code review. This simple but often overlooked practice builds trust, improves collaboration, and turns code reviews into lasting pieces of product and engineering history.

### Key Takeaways:

- **We always include a test plan or demo**: Whether it's a video, GIF, image, or command-line instruction, we attach an artifact that shows what our code does—especially when it impacts visual or user-facing components.
- **We demonstrate the *actual* behavior of our code**: A video showing the happy-path functionality proves the feature works and saves reviewers from guessing or manually testing our changes.
- **We create long-term product context**: Test plans turn code reviews into searchable, durable documentation. They help future engineers (including ourselves) understand *why* a piece of code was written and what it was supposed to do.
- **We reduce risk when extending legacy code**: When we need to modify or build on old code, a past test plan often reveals how that code works, what features it powers, and how to avoid breaking it.
- **We invest a few minutes now to save hours later**: Including a test plan takes only 5–10 minutes but dramatically improves team empathy, speeds up reviews, and enhances the maintainability of the entire codebase.

This practice is one of the easiest and most impactful ways we show care for our teammates—and for the long-term health of the code we ship.

[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms

Data structures and algorithms (often abbreviated as "DSA") is an infamous staple of the software engineer interview experience. Data structures and algorithms problems are the most well-known for being part of the FAANG interview process, especially for Google.

Here are our Top 5 favorite points from this masterclass (in no particular order):

- **DSA prep is insanely high ROI** - In fact, the return on investment for time spent on DSA studying makes it one of the highest yield activities any human can do period. If you haven't worked at FAANG / Big Tech before, switching into it is likely to increase your pay by 50%+. If you're in the US, this will often mean a raise of $50k+. So the next time you're feeling burnt out from DSA studying, keep this very bright light at the end of the tunnel in mind.
- **Leetcode and Glassdoor are all you need** - DSA studying is a solved problem. You can use other, newer tools if you want, but the old-school ones still work just fine. Glassdoor in particular is naturally very effective given the "Big" nature of "Big Tech". Go through the recent data points from Glassdoor if you're interviewing for Big Tech and make sure you have a good grip on recurring recent problems.
- **Learning DSA is all about pattern recognition** - For 80%+ of DSA problems, there will be some 1-2 liner "trick" that represents the whole solution. For example, the "trick" to 2 sum is "Look for the difference and use a set/dictionary". It is not scalable to memorize solutions as code - Look for patterns and remember solutions as that high-level insight.
- **Communicate, communicate, communicate** - Since FAANG companies are so huge, there are naturally going to be far more stakeholders on every project, making alignment far more important. Because of this, Big Tech companies will often closely judge your communication skills during the interview. Don't just code in silence - Even if you get the right answer, you may still fail for not maintaining a dialogue with your interviewer.
- **Don't forget about space** - Most people are aware of big O run-time complexity, but candidates often forget about space complexity. Make sure to talk about both when you analyze your solution. As a side note, remember that a recursive solution will *not* be O(1) space.

Related resources:

- [\[Course\] Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)
- [How Alex Got Into Meta With 0 Prior LeetCode Experience](https://www.jointaro.com/lesson/ZYiTbN21FsqFxFdpwt5a/how-alex-got-into-meta-with-0-prior-leetcode-experience/)
- ["How do I balance my time between studying DSA and fleshing out my portfolio?"](https://www.jointaro.com/question/fhV2SCn56aYF4gfPVLmV/how-do-i-balance-my-time-between-studying-dsa-and-fleshing-out-my-portfolio/)
- ["Should I quit to prep for interviews?"](https://www.jointaro.com/question/Cno3oaZkvUu7BPLhHB7g/should-i-quit-to-prep-for-interviews/)
- [Presentation Slides](https://docs.google.com/presentation/d/13uLUHDvZifjp2aVClGsW29nfuVpQYvrkGLP8cej0R_k/edit#slide=id.p)

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.