DSA Crash Course [Part 16] - Intersection Approach

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

> Write a function, *intersection*, that takes in two lists, *a*,\_b\_, as arguments. The function should return a new list containing elements that are in both of the two lists.
>
> You may assume that each input list does not contain duplicate elements.

```
intersection([4,2,1,6], [3,6,9,2,10]) # -> [2,6]
```

```
intersection([2,4,6], [4,2]) # -> [2,4]
```

```
intersection([4,2,1], [1,2,4,6]) # -> [1,2,4]
```

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

Ace Your Tech Interview As A Software Engineer [Part 9] - Polish Your Resume

Your resume is the most important professional document in your life. However, a lot of software engineers are severely lacking in this department. This lesson teaches you:

- The perspective of the often underappreciated tech recruiter and why they automatically reject the overwhelming majority of resumes, especially if they work for a top company like Big Tech
- How to write a resume that recruiters won't hate and instantly throw in the trash, leveraging that empathetic mentality from before
- The steep, underestimated cost of basic resume mistakes, which are incredibly common among immigrant engineers where English isn't their first language
- Why you should make just 1 focused resume instead of several, especially if you're earlier-in-career
- How recruiters hyper-efficiently read resumes (spoilers: they often don't read the entire thing)

13 minutes isn't nearly enough to fully understand all the mechanics of a good resume, so you should dive deeper here: [\[Masterclass\] How To Write A Stellar Tech Resume That Gets You More Job Opportunities](https://www.jointaro.com/lesson/OnQV2V3J8DYVBBuGbZx6/masterclass-how-to-write-a-stellar-tech-resume-that-gets-you-more-job-opportunities/?playlistId=PJqfgn35DG82NSm3QyfT)

Level Up Your Code Quality As A Software Engineer [Part 8] - Case Study: Instagram vs. Robinhood

Trying to nail down what good code looks like is equivalent to trying to staple jello to a wall. Almost every software engineer looks up to FAANG and FAANG-adjacent companies, and that's what this lesson will cover in-depth with an example. This lesson will teach you:

- The engineering philosophy behind Instagram's Android codebase, its unique attributes, and its priorities
- The engineering philosophy behind Robinhood's Android codebase, its unique attributes, and its priorities
- Why taking Instagram Android code and pasting it into Robinhood would have been terrible despite it being industry-leading in its own context (and vice-versa)

Become An Open Source Master [Part 5] - The Benefits Of Open Source

We'll discuss the reasons why you should get involved in open source and the benefits it can bring, both professionally and personally.

- **Work on code that matters:** Contribute to projects used by others, gaining a sense of achievement and pride.
- **Improve your coding skills:** Receive feedback and learn from experienced developers, improving your coding abilities and knowledge.
- **Build relationships:** Connect with maintainers, contributors, and users, expanding your network and learning opportunities.
- **Enhance your professional portfolio:** Showcase your skills and experience to potential employers through your open source contributions.
- **Grow your personal reputation:** Gain recognition and build valuable connections within the open source community.

Connect with James: 

- GitHub: <https://github.com/jamesgpearce>
- Twitter (X): <https://twitter.com/jamespearce>

The Most Dangerous Thing People Don't Realize About FAANG

So many engineers focus on just the interview when it comes to breaking into Big Tech. However, cracking the FAANG interview isn't the main thing you should worry about: *Surviving at Big Tech is what's truly hard.*

Here are the core point from the video:
- **Big Tech expectations are very high** - In exchange for world-class pay, you are expected to have world-class productivity. For most engineers coming from non-Big Tech backgrounds, they're going to have to put out more work that's also higher quality compared to what they've normally done.
- **It can be hard to adjust** - This is especially relevant if you spent a very long time (10+ years) working at companies that weren't as cutting edge as Big Tech prior to going there. It is very difficult to do things in a completely different way to what you're very used to.
- **Performance review is stressful** - Since these companies are so big and have so much process, performance reviews are incredibly thorough and take a long time. It often takes months to write and collect all the feedback necessary to compute the final rating. Couple this with fear of PIP and stack ranking and you have an environment that really puts engineers on edge.

Related resources:
- [[Masterclass] How To Navigate Your Performance Review In Tech](https://www.jointaro.com/lesson/b0B8uqIAUnBLE10jJHJG/masterclass-how-to-navigate-your-performance-review-in-tech/)
- ["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/)

Have The "Meta Conversation"

A "meta conversation" is a **conversation about conversation**. It's a conversation you should have with coworkers to discuss **how** you should communicate.

- How often do you want to meet?
- How often do you want feedback?
- What is your preference for written vs verbal updates, and the format?

You will be working with your manager and team for 100s of hours over the course of a year, so it's worth spending some time at the beginning of the relationship to understand how you can best work together.

Being New Is A Superpower

Instead of treating your newness as a liability, view it as a superpower.

- Nobody wants to be mean to the new person, so you have the perfect excuse to request resources aggressively.
- You can observe problems with the codebase, processes, or tools that tenured employees have learned to tolerate.
- You can connect the dots between different teams or ideas that would be harder for people entrenched in their roles.

Approach your onboarding with the urgency that "**You will never have fresh eyes again**."

As the most clueless person, if you revamp a resource (wiki, code, etc) to be easy to understand for yourself, you are making it easy for **everyone** to understand.

Maximizing a Severance Package 4/9 - Never Accept on the Spot

During a termination, don't sign anything on the spot. **Buy time.** Buy time to do your research, to prepare, and to come back and negotiate.

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

How To Find A Good Team With Career Growth Opportunities

Not every team will have the scope you need to get to the next level, especially at FAANG and Big Tech. If you're looking to get to senior engineer levels and beyond, here's what to look out for in a team:
- **Past launches** - If the team has frequent, meaningful launches from the past year, it's likely this will continue.
- **Healthy balance of levels** - You want folks more senior than you to learn from and folks more junior than you for you to mentor and work through.
- **Strong engineering manager track record** - In particular, see who they have been able to get promoted. If there are examples of senior and staff engineers grown organically within the team, that's another good sign.

This clip was taken from our team selection masterclass. You can watch it here: [[Masterclass] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

Related resources:
- ["What should I look for in a new team in terms of growth?"](https://www.jointaro.com/question/i2bOMPrqaRc0NUZ7918F/what-should-i-look-for-in-a-new-team-in-terms-of-growth/) - Question from a Google L4 engineer
- ["How do I find a good team that sets me up for the mid-level -> senior level promotion?"](https://www.jointaro.com/question/oHJWlzm1qdHUZx66moaT/how-do-i-find-a-good-team-that-sets-me-up-for-the-mid-level-greater-senior-level-promotion/) - Question from an Amazon SDE 2
- ["What does it mean to not have enough scope to be promoted?"](https://www.jointaro.com/question/bJuagPwOEEy5vkcXKkqh/what-does-it-mean-to-not-have-enough-scope-to-be-promoted/)

Overcoming Imposter Syndrome - You Have So Much More Value Than You Realize

One of the biggest factors holding software engineers back is a simple one: They don't believe in themselves. This is very common in the tech industry where being surrounded by talented peers makes it very easy to end up with a case of imposter syndrome. This video explains why every single person in tech is wrong when they believe they can't add value.

Here are the core points from the video:
- **You can't be alive for 20+ years and not have something to share** - 2 decades is a long time. A lot of people don't believe they can share value when they're early in career, which completely discards all their years prior to their career. It's not like you only started generating value in the world after you embarked on your tech career journey. It is mathematically impossible to have been on planet Earth for so long and not have something cool you can share with others.
- **Believe in yourself** - You are limited by what you think of yourself: If you don't believe that you can offer value, then you won't offer value. The absolute first step to successful networking is recognizing your own potential and feeling empowered to help others.
- **Accessible ways that *anyone* can add value**
  - Interesting experiences
  - Odd talents
  - Learnings from failure
  - Being a friendly face

Related resources:
- ["How can I bridge my confidence gap to put myself out there more and ask for help more aggressively?"](https://www.jointaro.com/question/mLKUkNXpLcCxQMfWopqU/how-can-i-bridge-my-confidence-gap-to-put-myself-out-there-more-and-ask-for-help-more-aggressively/)
- ["I've felt imposter syndrome from seeing super talented peers - How do I deal with this?"](https://www.jointaro.com/question/MPUkGXFDaBixmxfjOg9i/ive-felt-imposter-syndrome-from-seeing-super-talented-peers-how-do-i-deal-with-this/)

Come Up With 500k+ User Project Ideas [Part 4] - Finding Inspiration

Good side project ideas don't grow on trees, but finding them actually isn't that difficult. This lesson teaches you:

- The mentality you should have with your day-to-day life to organically stumble into great software product ideas
- How frustration in general is actually a blessing in disguise, not just for side projects but for engineering in general
- Tactical ways you can improve on existing products in your life

Level Up Your Code Quality As A Software Engineer [Part 7] - Code Quality Isn't Static

Things would be so easy if we could just copy-paste the tech stack of our favorite FAANG company and call it a day. The bad news is that this is a prime recipe for disaster. This lesson will teach you:

- Why there's no such thing as objectively "good" code and the primary vector stopping that (hint: It's the only resource that matters)
- The right mentality to have when improving your specific codebase in your specific situation
- How to think about your code architecture as it relates to scale

Top System Design Interview Mistakes [Part 13] - Identifying Key Issues

In the final segment of the system design series, we focus on the importance of driving the design of your system during interviews. In this video, we cover how to identify key issues. Here's the video's core points:

- Avoid following a rigid structure. For example, don't just jump into a data model or architectural diagram without considering the unique requirements of the system you're designing, such as group messaging dynamics
- Actively ask clarifying questions to understand the requirements better. This helps in identifying and addressing key issues specific to the problem, rather than sticking to a generic approach
- Tailor your approach based on the specifics of the problem. If dealing with a unique system, like a group messaging app, adapt your design to handle unique challenges, such as managing multiple notifications from a single message
- Lead the discussion by probing into requirements and challenges. This ensures that your design addresses the most critical aspects of the problem

If you need extra help with your system design interview, [Formation.dev](https://formation.dev/partners/taro) can provide you hands-on, personalized support. Join us here: <https://formation.dev/partners/taro>

Tech Lead Blueprint 3/17 - Why do TLs exist?

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

Properly Learning From Software Engineers More Senior Than You

True or false: What is built by a very senior engineer is more important than how they built it.

When observing very senior engineers, what should you look for to properly learn from them?

True or false: At the top tech companies, the very senior engineers make 5-10x more than their very junior counterparts because they work 5-10x harder than they do.

Which are good examples of questions you can ask when understanding a very senior engineer's behavior?

True or false: At the top tech companies, you are told less and less what to do as you grow more senior, working on more ambiguous projects while having greater freedom to choose what you work on.

As a junior software engineer, it can be daunting understanding the senior and staff engineers on your team. This video covers the mindset shift to make to start leveling yourself from properly observing them, achieving career growth without these engineers having to formally mentor you.

Here's the core points:
- **Observe more senior teammates' behavior** - Principal engineers will usually have 10x the impact of a junior engineer. They don't get there by working 10x as hard - We all have the same 24 hours in a day. Instead of asking yourself *what* these great engineers are getting done, ask yourself, "*How* do these engineers get stuff done?". Marveling over their much larger impact won't get you anywhere - You start really learning from these engineers when you start breaking down the path they took to achieve that impact.
- Here are more specific axes to observe:
  - **Communication** - How do these engineers share status updates and rally the team around their ideas?
  - **Direction** - How do they prioritize projects and select the best ones?
  - **Quality** - How do these engineers protect the sanctity of launches? What kind of feedback are they leaving in code review? What good habits do they have when they submit code? How do they facilitate system design discussions?

Related resources:
- ["What's the core insight behind quick growth?"](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/)
- ["How do you get the most out of mentorship?"](https://www.jointaro.com/question/IbuZydz0QzsVVqESVaxQ/how-do-you-get-the-most-out-of-mentorship/)

Creating A Portfolio That Makes Recruiters Come To You

Building a personal portfolio looks nice and feels good, but it *rarely* helps engineers find jobs. In this video, we cover how you can truly stand out as a software engineer and make the jobs come to you (instead of the other way around).

Here are the core points:
- Building a portfolio website can be a nice exercise, but don't spend too much time on it. *Don't expect to get any inbound recruiter reach outs due to your portfolio site*. There is no real central repository of them that recruiters browse.
- In terms of what recruiters do browse, it's primarily LinkedIn. If you have this portfolio energy, it's much better spent polishing your LinkedIn profile instead.
- At the end of the day, a portfolio website is resume++. This means that your foundation is still your resume: Make sure your resume is *extremely* sharp before you even consider building a portfolio website.
- Alex found a lot of success having his Google Play developer page be a portfolio as it hosted real, verifiable products on it. Since his side projects got millions of installs combined, he's gotten reach outs from top companies like Uber, Square, and Instacart through his Google Play developer email.

Related resources:
- ["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/)
- ["I want to land a job in a big tech as a SWE - How to do it?"](https://www.jointaro.com/question/MWJfUBnnUr8CKYFCO8bp/i-want-to-land-a-job-in-a-big-tech-as-a-swe-how-to-do-it/)
- ["Can Github stars grab big tech recruiters' attention?"](https://www.jointaro.com/question/XaUn4XuIBMSmrr5fcHIT/can-github-stars-grab-big-tech-recruiters-attention/)

Level Up Your Code Quality As A Software Engineer [Part 12] - Break It Down

Software is scary, especially when you get big projects that require thousands of lines of code to implement. This lesson will teach you:

- The steps to turn any tough technical problem into something that's quite manageable (and even easy)
- Why decomposition is one of the important skills for a software engineer to have at all levels
- A framework to plan out your commits and create a crystal clear roadmap for your code
- How to decompose coding projects in a systematic way, demonstrated through an in-depth example covering a classic software flow: User login

Avoid These Junior Engineer Mistakes With Code Review

In this video segment, we reflect on common mistakes and best practices around code submissions, especially relevant to early-career engineers. The discussion centers around how to be thoughtful and intentional in code reviews to earn trust and increase velocity over time.

- **We don’t treat code review as a speed game.** Moving fast at the cost of quality—like deferring fixes or separating tests from the initial diff—often backfires. We strive to bundle fully thought-out changes with tests as one atomic, reviewable unit.
- **We use RFC diffs to gather early feedback.** When we're unsure of direction, we create “Request for Comment” diffs clearly labeled as such. This helps reviewers give high-level input without getting stuck on minor details.
- **We always show proof of testing, even for small changes.** Even if our change is minimal (e.g., a refactor or doc update), we still confirm it compiles and passes existing tests to signal due diligence.
- **We think like reviewers.** Providing context, test signals, and clarity up front not only earns trust but speeds up the feedback loop and helps us land code more efficiently.

I Sucked At This For 25 Years As An Engineer – 8 Tips For Communication

Communication is the skill that separates the best engineers from the mediocre ones. 

**Nothing great is built alone**, so even if you’re the best coder in the world, at some point in your career you will have to work with others. When you get to that point, communication is how you get things done. 

Here are 6 tactical communication tips for engineers (and there are two more in the video!)

**1. Learn how to say no. If your PM or manager comes to you with a request, don't just say no.**

Instead, say "not right now" and explain why you're choosing to do other high-priority work. This approach lets you acknowledge the request or the idea, but you’re able to firmly/politely say no by explaining why you want to stay the course. 

**2. Use tentative language**

Especially for critical feedback, leave room for discussion. One way this manifests is during code review: some of the best engineers at Meta actually ended their feedback with a question mark:

"Crash with negative input" ➡️ "Crash with negative input?" One character makes a big difference!

**3. Make people feel heard**

In 1:1s, I’ll literally say "Let me say that back to you" and repeat back what they said to me. This works magically well.

Even if you disagree, this strategy lets you start from a place of agreement -- the person was heard.

**4. Say thank you**

*Proper* thank yous are about more than sending a one-line message. A proper thank you involved thanking them in your launch post or sending them a thank you when you hit a milestone. That's how you build deep relationships.

**5. Advance the conversation**

This is a personal pet peeve for Rahul. If we're talking about where to get lunch, and I propose Indian food, don't just say "I don't like Indian." You need to propose some alternatives in that response. Also, google the ["no hello"](https://nohello.net/) philosophy.

**6. Know your audience**

Many engineers either provide too much or too little context. Communication is an exercise in empathy. You have to figure out what your audience cares about and deliver value to them.

Related links:
- [Taro's communication guide](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)
- ["When should you offer to help a colleague?"](https://www.jointaro.com/question/u4GMlmLOuaU4Olhh2XAy/when-should-you-offer-to-help-a-colleague/)

Master The Behavioral Interview [Part 6] - STAR

Behavioral interviews are ultimately an exercise in story-telling, something that many software engineers unfortunately struggle with. This lesson teaches you:

- The STAR format, how it works, and why it's important
- What to include with S(ituation)
- What to include with T(ask)
- What to include with A(ction)
- What to include with R(esult)
- What a stellar behavioral interview answer following the STAR format looks like

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.