The MANY Benefits of Code Review (What You Didn't Realize)

In this video, we explore the deeper value of **code review**—going beyond its obvious impact on code quality to highlight how it shapes team culture, collaboration, and continuous learning. While improving code is a benefit, we emphasize that the long-term value lies in building a stronger, more aligned engineering team.

### Key Takeaways:

- **We use code review to improve code quality**: At a basic level, reviews catch issues and lead to cleaner, more maintainable code—but that’s just the surface-level benefit.
- **We treat code review as essential feedback**: Just like feedback in any other domain, having someone else evaluate our work helps us grow—technically and professionally.
- **We build team awareness and cross-pollination**: Code reviews help teams stay aligned and aware of each other’s work, which strengthens cohesion and product velocity.
- **We learn even when no changes are made**: Valuable discussions often emerge from understanding *why* code was written a certain way, even if the final diff remains unchanged. This raises the collective standards of the team.
- **We view code review as a cultural cornerstone**: We love it so much that reviewing code became a natural, even joyful, part of our daily routine—it’s how we grow, connect, and elevate our craft.

Maximize Your Productivity As A Software Engineer [Part 2] - The Productivity Giant You Are Missing

When it comes to productivity, most software engineers have the completely incorrect strategy of simply working harder. This isn't sustainable and misses the forest for the trees. This lesson teaches you:

- The true highest leverage thing you can do when it comes to your productivity, explained with an example from Meta and Google
- Why working on the right things is much better than just working on your current things faster

Here's the promotion course: [\[Course\] Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)

Level Up Your Code Quality As A Software Engineer [Part 3] - The Myth About Better Code

So many software engineers and engineering managers don't actually understand the relationship between code velocity and code quality. This lesson will teach you:

- Why code quality and code velocity aren't at odds with one another, completely busting the myth that writing better code makes you ship more slowly as a software engineer. In fact, they actually go quite well together!
- The true, nuanced relationship between how good a software engineer's code is and how fast they move
- Where you want to be as a software engineer when it comes to balancing code quality and code velocity
- How the highest-performing software engineers use their stellar code quality as an asset to move faster and land more impact than everyone else

The Rare Insight Top Tech Companies Have About Engineering Managers

Most engineering managers [EMs] are bad and aren't much more than glorified, overpaid whip-crackers. Here's what the world's best tech companies realize about engineering management that other companies don't.

Here are the core points:
- **Good EMs think long-term** - It's really easy to burn out the team for short-term gains, just working them harder and harder so everything ships quickly. However, this isn't hard to do and sacrifices the future of the team. Teams run this way eventually reach a state of weak productivity due to high turnover and completely drained engineers. Good EMs strive to operate their teams in a sustainable way, taking care of their engineers while also pushing for velocity.
- **Good tech companies hold EMs accountable** - In particular, EMs are expected to uphold the overall health and integrity of their teams. Companies like Meta explicitly score managers on how well they are able to give their engineers growth opportunities, preserve their work-life balance, and shield them from thrash so they have the focus to execute.

Related resources:
- [[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/) - The full video where this clip was taken from
- [How Do Effective Engineering Leaders Help Their Teams Achieve More?](https://www.jointaro.com/lesson/xGJDCG7VL4hcZaq5XL92/how-do-effective-engineering-leaders-help-their-teams-achieve-more/)
- ["How do I figure out whether I should stay as an IC engineer or explore management as an EM?"](https://www.jointaro.com/question/Y6qIop9wpOlCYUL0nGs0/how-do-i-figure-out-whether-i-should-stay-as-an-ic-engineer-or-explore-management-as-an-em/)
- ["What are the commonalities and differences between tech leads and engineering managers?"](https://www.jointaro.com/question/c3MLGlkQgOQ6OUHANAxT/what-are-the-commonalities-and-differences-between-tech-leads-and-engineering-managers/)

Write A Stellar Resume As A Software Engineer [Part 3] - The Key To Writing A Great Resume

In the vast majority of cases, a recruiter is reviewing the resumes of software engineers. This means a lot more than most engineers realize. This lesson teaches you:

- The #1 principle you **need** to remember when writing your resume
- The important attributes of recruiters when it comes to vetting resumes
- How to truly empathize with recruiters and infer their resume screening behaviors based on that
- How recruiters read through engineering resumes

[Case Study] How To Land 18 FAANG+ Offers With Steven Zhang (Airtable, USDR, Tableau)

While on the job hunt in 2019, Steven Zhang received 18 offers (out of 22 onsites), including from companies such as Airbnb, Apple, Facebook, Palantir Technologies, Pinterest, Stripe, Uber.

In the process, he became an expert in software engineering interviews and job searching. Steven shared his thought process and methodology:

- When you have many interviews, **operationalize it, and treat it like a multi-week/month project**. Some days will feel like a slog, but that's ok and part of the process. (Steven used Airtable to coordinate all his conversations.)
- **Doing an interview prep course is completely worth it for DSA**. It may cost a few thousand dollars, but being able to land the ideal job is definitely worth it (and likely worth tens of thousands of $$). Steven used InterviewKickstart (his referral: https://bit.ly/swe-tips-ik).
- **For behavioral interviews**, Steven recommends:
  - Writing all questions you received in a Google doc
  - Recording yourself doing mock interviews with a friend and then listening to it.
- **Steven received offers at various levels through the bands**, from L3 (junior) to L5 (senior). Your level has huge implications for your compensation.
- Negotiation tips:
  - Negotiation should not be adversarial- think of it as doing price discovery
  - If you ask nicely, no one will rescind your offer for asking for more money.
  - Negotiation/post team matching is a way to get signal on the company itself

Relevant resources:

- [\[Masterclass\] How To Ace Your Big Tech Interview - Data Structures And Algorithms](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/)
- [\[Masterclass\] How To Ace Your Big Tech Interview - System Design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/)
- [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/)
- Steven's [viral Medium article about this experience](https://medium.com/@stevenzhang/how-i-landed-18-faang-software-engineer-offers-after-not-interviewing-for-5-years-fc0dfc957a5d).
- Connect with [Steven on LinkedIn](https://www.linkedin.com/in/stevenqzhang/)

[Case Study] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project

Oncall is a critical process for any good engineering team, especially larger ones. However, a lot of software engineers aren't truly exposed to oncall until several years into their career. This detailed case study covers what a healthy oncall looks like and how ex-Instagram tech lead Alex led his organization towards that.

This session covered a *lot* of ground, so we'll focus more on the learnings instead of the historical story:
- **Good oncall ingredients**
  - Very strong sense of ownership expected from the current oncall - The buck should stop with them
  - A detailed runbook and thorough documentation in general around SLAs, SEV criteria, and ownership
  - 7 to 12 engineers on the rotation so you're only oncall <15% of the time
  - A retrospective process that brings together the team to share knowledge and figure out how to improve their systems as a whole
- **Pain = Opportunity** - Never say *"That's just the way it is"*: Every problem is solvable. If you want to level up fast, strive to alleviate pain at scale for your team instead of running away from it. Here's a great discussion covering this concept in more detail: ["Ways to add value when asked “What do you think would be biggest challenges for next quarter?"](https://www.jointaro.com/question/zYbkS5Bn00H9RGKiiL4F/ways-to-add-value-when-asked-what-do-you-think-would-be-biggest-challenges-for-next-quarter/)
- **It's All About Relationships** - This is especially important at senior and staff engineering levels. In order to change process and push big projects, you need to get many people to agree with you. Understand that these relationships take time to grow and you need to start as early as possible. Check out this masterclass to deep-dive into this: [[Masterclass] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)
- **Understand Everyone's Incentives** - They will be very different for people who aren't on your team or aren't engineers. As a tech lead, you are expected to work across XFN boundaries regularly, and succeeding at this requires understanding what drives everyone and finding mutual interests.
- **Lead By Example** - Put yourself on the line and practice what you preach. A disconnect between what you're recommending and your own actions is one of the easiest ways to sabotage your own influence.
- **Stand On The Shoulders Of Giants** - At Big Tech companies in particular, there will always be hundreds of other engineers in the company who have already solved the problem you are currently working on. There is no need to reinvent the wheel - Seek out those people and learn from them.

Related resources:
- ["How to form a healthy on-call rotation?"](https://www.jointaro.com/question/8OuTidxuVaeuQCV28IhD/how-to-form-a-healthy-on-call-rotation/)
- ["How can I improve the unstructured, chaotic oncall rotation I'm on?"](https://www.jointaro.com/question/ScxFpybXXC90qmnLEU7A/how-can-i-improve-the-unstructured-chaotic-oncall-rotation-im-on/)
- ["How can I maintain work-life balance with a hectic oncall?"](https://www.jointaro.com/question/WLqDVZQa8rAEmFEl15oA/how-can-i-maintain-work-life-balance-with-a-hectic-oncall/)
- [Presentation slides](https://docs.google.com/presentation/d/19PpKY5VoRAP8OMhu2shwhLthKiodw5cUruk6Lycelho/edit?usp=sharing)

Don't Be Naive When Networking - Understand That You'll Get Burned

One of the main ways to grow your tech career is by building relationships. However, a lot of software engineers struggle immensely with this, dismissing the entire craft as "playing politics". This video explains why that mentality is toxic and how you should set up your mindset instead.

Here are the core points:
- **Every company will have politics** - What separates the good companies from the bad ones is that the good ones have a moderate amount of politics while the bad ones have an overwhelming amount of politics. If you're going to any decently sized company, you will have to do understand how to interact with people and get them to like you. It is near impossible to get to senior levels without being able to do this.
- **Professional networking is just like "real life"** - There isn't a huge difference between building work relationships and making personal friends and dating. The core principles behind establishing relationships and earning trust are the same both inside and outside of work.
- **Not every relationship will work out** - Similar to personal relationships, you will often times invest into people who won't return the favor. *Don't let that turn you off from the idea of networking as a whole.* Growing as a software engineer is a marathon filled with ups and downs. Don't let a few toxic coworkers or poor synergy partnerships tear you down.

Related resources:
- [[Masterclass] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/how-to-build-deep-relationships-quickly-in-tech-12172022/) - The full video where this clip was taken from
- [Effective Communication Guide - Building Relationships](https://www.jointaro.com/lesson/488EjOLzU707WhdqMOK4/effective-communication-guide-part-3-building-relationships/)
- ["How do I achieve my goals for this half when XFN is not communicating effectively?"](https://www.jointaro.com/question/Z1MwZ4GOA4XxxZd9ff5n/how-do-i-achieve-my-goals-for-this-half-when-xfn-is-not-communicating-effectively/)

[Case Study] Hypercharging Your Growth At Early Startups (w/ Staff Engineer Seed Zeng)

[Click here for the presentation slides](https://docs.google.com/presentation/d/1ZocNUZJL-feWAKoucVLUcaVxix2Xa1udEL4KpgQRBTo/edit?usp=sharing).

There are a *ton* of great points covered in this session, so we'll only share our Top 5:
- **Startups have massive scope** - In an early-stage startup, there is always an infinite supply of hard, technically deep problems. This allows you to have a lot of freedom choosing an opportunity that works well for you and build up a wide breadth of important skills. This is almost always *not* the case in Big Tech - [Check out this expert career advice on the difference between Big Tech and startups when it comes to learning](https://link.jointaro.com/n57gbTWERveGTQuM9).
- **Don't say "I'm not qualified to work on this"** - The best software engineers are able to adapt to any situation their team faces and add value regardless of what framework or tech stack is needed. In order to do that, you must first flip this fearful mentality. [Here's our masterclass on how to learn quickly in tech](https://link.jointaro.com/S2h95sJvRU8Utjj6A).
- **Don't be afraid to make mistakes** - Recovering from a mistake is one of the most powerful ways to learn, and startups will generally have more tolerance for mistakes as stakes are lower compared to a more mature, massive public company where product issues can make the news. [Here's our advice on how to maximize your growth from mistakes](https://link.jointaro.com/THof1u97Z5t1ovCr9).
- **80% of the journey is just showing up** - Seek out important, complex situations and run towards them instead of away from them, especially with production issues. If you're earlier-in-career, you can learn a lot simply by being a participant in fixing these fires; from there, you can make yourself a core driver more and more. [Here's our advice on how you can be more independent debugging tricky technical problems](https://link.jointaro.com/xE8oMpCaDYjuMhCg7).
- **It's all about the people** - Your career growth is largely a product of the people you surround yourself with, and this is especially true in a startup where the team is small, bonds are deep, and everybody knows each other. [Here's our advice on how to network effectively within a company](https://link.jointaro.com/Hr1nr53D7sfQAEv3A).

To see (and hear) more from Seed:
- [Connect with him on LinkedIn](https://www.linkedin.com/in/seedzeng/)
- [Check out his podcast "Superposition"](https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkLnBvZGJlYW4uY29tL3N1cGVycG9zaXRpb25zaG93L2ZlZWQueG1s?sa=X&ved=0CAMQ4aUDahcKEwjot6up4Zf7AhUAAAAAHQAAAAAQAQ&hl=en)

Related resources:
- [Session #6 - Maximizing SWE Growth: Ownership and Specialization At Startups](https://link.jointaro.com/2ZevbN54MPZPTocH8)
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/n57gbTWERveGTQuM9)

System Design Series: Taro Playlists [Part 10] - This Is Just The Beginning

Congratulations, you made it to the end of our **system design** series! If you liked this series and want to see more like it, give this video and all the others in the playlist a like!

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 working through a **system design** at your job!

Here are the core points from the video:
- Creating the **system design** doc is just the 1st step of the process: The next step is getting aligned from the team!
- Here are the steps to get strong alignment and the technical and overall product direction on a project:
  - Time-box the exercise: Have a firm date in mind on when this alignment needs to happen and work backwards from that date.
  - Share the doc with teammates and stakeholders and push them to leave feedback asynchronously. You can directly cc important people on relevant portions for them to look through.
  - Set up a tech review meeting as a forcing function to solidify all the alignment and talk through any remaining points of content. This meeting should probably be 45 minutes or more. Book it far ahead of time as senior+ engineers, tech leads, and managers tend to have very busy schedules.
  - Remind people before the meeting to go through your system design doc beforehand and try to resolve as many threads before the meeting as possible. You might need to do this several times.
- Everything covered in this system design series is effectively a requirement to be a competent senior+ engineer and tech lead, *especially* if you work at FAANG or some other Big Tech company.
- This can all be done reactively as well. If you're working on a small, tightly-knit team with very high synergy (common in startups), raw tribal knowledge and ad-hoc collaboration may be enough to ship projects consistently well. In this case, doing all this probably doesn't make sense. However, if your last couple projects have been pretty rocky, you might want to consider adding all the processes outlined in this series.

If after all this, you're still hungry for more **system design resources**:
- [How To Ace Your Big Tech Interview [System Design]](https://link.jointaro.com/NoVGhFiEErzfh61f6) - This is a full 1.25 hour masterclass, so prepare yourself for a **ton** of knowledge!
- ["How do I get better at building large scale systems without working directly on such projects?"](https://link.jointaro.com/Dm9wE33YC7ffwAPa6) - Question from a Senior Software Engineer at LiveRamp
- ["How to improve on non-technical skills like writing software design document?"](https://link.jointaro.com/T7GCmM4Z4CZhve4y5) - Question from a Mid-Level Software  Engineer at Microsoft
- ["My team has been doing architecture debates for months and we’re in gridlock."](https://link.jointaro.com/Zzx1NRMJFHvtHcvP8) - Question from a Senior Software  Engineer at Google
- ["How can I better contribute to system design discussions on my new team?"](https://link.jointaro.com/FH7ED2533nSTJSRc6) - Question from a Senior Software Engineer at Google

Claiming Full Credit For Your Projects On Performance Review

- What is the project: Which features did it compose of? How does it work?
- Context behind the project:
  - Why was this project hard/interesting: Complexity of projects is especially important for more senior engineers.
  - What was the business impact: Did it lead to more revenue directly? Did it improve user experience? Was a core KPI increased?
- Role you played in the project: What value did you specifically add to the project, especially that of the deeper kind? For Big Tech companies, this is very important as projects can easily have 15+ people working on them.

What Too Many Companies Don’t Get: Management IS NOT A Promotion

Most tech companies have no idea what they're doing when it comes to engineering managers and overall leadership culture. One of the clearest ways this is reflected is how engineering manager is positioned within the company hierarchy.

Here are the core points:

- **Management is NOT a promotion** - Becoming an engineering manager is about adding value to the overall engineering in a different way. It's not about "moving up" or "controlling the engineers". *A trademark sign of bad companies is that they position the switch into management as moving up the corporate ladder.* The problem with this is that employees then switch into management for the wrong reasons, chasing money and power. This leads to an unhealthy dynamic between engineers and manager as engineers are "beneath" the manager, usually leading to the manager treating them as expendable and burning them out.
- **Top companies have separate SWE and EM tracks** - In companies like FAANG, both staying as an individual contributor (IC) software engineer and becoming an engineering manager are valid career paths with the same ceilings. This means that for every management level (manager, director, VP), there is an equivalent software engineering level with a similar amount of compensation.

Related resources:

- [How Do Effective Engineering Leaders Help Their Teams Achieve More?](https://www.jointaro.com/lesson/xGJDCG7VL4hcZaq5XL92/how-do-effective-engineering-leaders-help-their-teams-achieve-more/)
- ["What do career levels structure in big tech company look like? What are the responsibilities for each level?"](https://www.jointaro.com/question/qV5oikdcgs4GWmGeousX/what-do-career-levels-structure-in-big-tech-company-look-like-what-are-the-responsibilities-for-each-level/)

How Software Engineers Are Measured For Promotion

What does additive value look like for a software engineer?

What's the main metric used to evaluate engineers for promotion and their overall seniority?

What kind of value is the following: Creating a team-wide initiative to write more unit tests, organizing regular hackathons to write hundreds of tests at once alongside creating a dashboard to measure which tests catch the most bugs

What kind of value is the following: Helping the company's ambitious hiring goal for web engineers by interviewing dozens of React developers in just a few weeks

What kind of value is the following: Taking an incredibly vague product idea and refining it into a well-defined product spec by bringing together dozens of engineers, product managers, data scientists, and designers and getting alignment on what the value proposition is and how that manifests as a product experience

What kind of value is the following: Building out the iOS portion of adding Twitter login to onboarding flow for your company's core app after getting high-quality mocks and requirements for it

The Importance of Reflection With Time Management

Why is reflection important when it comes to productivity?

True or false: If you aren't getting as much done as you want, you should just work harder.

Which one of these is a concrete tactic you can use to shore up your reflection?

Establish what you want to get done in a given day or week. But if you don't get it done, then you NEED to reflect on **"why"**? Some possible reasons you might come up with it: 
- Procrastination
- Lack of clarity
- Missing information 
- Ad-hoc meeting

Now use this as learning going forward to make better estimates. Reflection is important enough that you should block time your calendar for it.

Master The DSA Interview [Part 1] - How This Course Works

Hate data structures and algorithms? We do too, which is why we're here to help! Here are the core parts of the lesson:

- Your instructor [Alex Chiou](https://www.linkedin.com/in/alexander-chiou/) walks you through his extensive 10+ year Silicon Valley background with rapid career advancement, ending up as a high-performing tech lead making $750k at Robinhood. More importantly, he goes through how he gave \~100 data structures and algorithms interviews at Meta (codenamed the "Ninja" round) and rejected 80% of candidates

- You'll understand the high-level reasons why engineers struggle with data structures and algorithms problems, particularly with top-level interviews

- We walk you through the course objectives. By the end of the course, you will:

  - 🔥 Be **motivated** to grind DSA

  - 💡 Understand how to **truly learn** DSA concepts

  - 🗣️ Know how to navigate DSA in a **live** interview

  - 🏔️ See how DSA is proctored at **top companies** (FAANG)

  - 🧠 Set up a proper DSA **studying regimen**

If you haven't already, we recommend taking the overall job searching course here: [Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Level Up Your Code Quality As A Software Engineer [Part 4] - What ACTUALLY Makes Code Good

Code quality is one of the most misunderstood topics in software engineering due to a combination of engineering laziness and misinformation. This video will teach you:

- What ACTUALLY makes code good and high-quality and why we're even software engineers to begin with
- How to have proper empathy for the end-user
- The common mistakes software engineers make when determining how good code is, including a very common misconception about how FAANG works
- The true value of clean code patterns and how they add value to the end-user instead of just being buzzwords (that can potentially make the code worse when used incorrectly)
- The #1 guiding principal when it comes to writing truly high-quality code

Every Senior+ Engineer Must Decide: IC vs Management Track

There is one good motivation to become an engineering people manager: to help people. If that's not the priority, you should not become an EM (and you should avoid working with those types of managers).

Daniel toggled between individual contributor (IC) and manager several times in his career. His most fruitful experience was as a very senior IC engineer at Meta -- he had the influence + context of a manager, but none of the headache associated with the job. 

Connect with Daniel on [LinkedIn](https://www.linkedin.com/in/danieltomko/)

Related content: 
- [Questions You Can Ask To Evaluate An Engineering Manager](https://www.jointaro.com/lesson/VOQc7vIzQ4STtw7UrB29/questions-you-can-ask-to-evaluate-an-engineering-manager/)
- [How Do Effective Engineering Leaders Help Their Teams Achieve More?](https://www.jointaro.com/lesson/xGJDCG7VL4hcZaq5XL92/how-do-effective-engineering-leaders-help-their-teams-achieve-more/)

Why You Should Always Negotiate Your Offers

- Negotiation is particularly life-changing, especially if you're early-in-career. It's also really high ROI as the cost is effectively just a couple emails and some potential awkwardness.
- Negotiation doesn't hurt anyone within or outside the company - It's effectively a part of life when it comes to the hiring game.
- What you negotiate for isn't connected to your costs: It's about getting what's fair given the market rate and your current leverage situation (i.e. do you have other offers).
  - Even if an offer is good given your personal situation, you should try negotiating, especially if it's below fair market rate for that level/company/geography and you have competing offers.
  - You can always do something with extra money!

If you need premier negotiation support, check out our 3+ hour negotiation course: [The Insider's Guide To Negotiating Your Tech Salary And Compensation](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/)

Amazing Pull Request Example - Showing The Context

In this video segment, we highlight a real-world example of a **high-quality code review** that demonstrates how providing strong context can dramatically improve the review process. This example reinforces the idea that well-documented pull requests reduce friction and foster better collaboration.

### Key Takeaways:

- **We showcase an exemplary pull request**: Submitted by a community member to the Tech Career Growth app, this PR included everything a reviewer needs—clear references, detailed explanations, and strong rationale.
- **We value clear linkage to issue tracking**: By referencing the related GitHub issue, the diff immediately communicates *why* it exists and what it’s solving—eliminating ambiguity.
- **We appreciate front-loaded context**: The PR offered an in-depth explanation of the author’s approach and alternatives considered, allowing us to understand the logic behind each code decision before even reading the code.
- **We reduce review overhead with context**: This kind of thoughtful diff saves time, prevents unnecessary back-and-forth, and lets reviewers dive straight into meaningful feedback.
- **We encourage others to learn from good examples**: We’re sharing this PR and slide deck so our community can use it as a model for writing better pull requests and improving team productivity.

**Here's why this pull request is great:**

- Has the relevant context behind why this PR exists and what it does
- Goes through the considered approaches to the problem and why the current one was chosen
- Links relevant resources that helped write the code

You can find the pull request that is shared in the video here: <https://github.com/Gear61/tcg-android-archive-and-feedback/pull/19>

DSA Crash Course [Part 4] - Is Prime Approach

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

> Write a function, *is_prime*, that takes in a number as an argument. The function should return a boolean indicating whether or not the given number is prime.
>
> A prime number is a number that is only divisible by two distinct numbers: 1 and itself.
>
> For example, 7 is a prime because it is only divisible by 1 and 7. For example, 6 is not a prime because it is divisible by 1, 2, 3, and 6.
>
> You can assume that the input number is a positive integer.

```
is_prime(2) # -> True
```

```
is_prime(3) # -> True
```

```
is_prime(4) # -> False
```

```
is_prime(5) # -> True
```

```
is_prime(6) # -> False
```

```
is_prime(7) # -> True
```

```
is_prime(8) # -> False
```

```
is_prime(2017) # -> True
```

```
is_prime(2048) # -> False
```

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

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.