Level Up Your Code Quality As A Software Engineer [Part 13] - Lay Out The Plan

It's tempting as a software engineer to leap straight into the code and start being productive. However, this can often cost you time in the long-term, especially with more technically complex tasks. This lesson will teach you:

- Why it's important to create a plan to increase your code quality, move faster, and build up relationships with your teammates
- What goes into a rock-solid coding plan (hopefully you were paying attention during the prior parts of the course!)
- Exactly what a good technical plan looks like with a concrete, real-life example from Taro

[Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free

Here are our Top 5 points from this session:
- **Side projects are incredibly powerful** - They improve your portfolio, increase your coding velocity, and give you holistic experience around building products end-to-end.
- **Care deeply about quality** - Users notice when your app or website is buggy. Strive to cover all edge cases and provide a truly polished experience.
- **Eat your own dogfood** - The best way to know how to improve your product is to use it yourself. This was a staple of Meta's engineering culture.
- **Least clicks design** - At the end of the day, it doesn't matter how "pretty" your product looks if it isn't efficient. Think about how you can have your "hero flow" take as few clicks as possible.
- **Understand SEO** - Work backwards from what people will be searching for when they need a product like yours. Then have those words in your product title and relevant metadata.

Related resources:
- [Presentation Slides](https://docs.google.com/presentation/d/1lfSCWI_OUtchWpIEKwG8JkII8IUvBeACRqEJlnTErjU/edit?usp=sharing)
- [How To Come Up With Product Ideas That Get 100k+ Users](https://link.jointaro.com/7Q8cDrda23zv2omU9)
- [How Side Projects Make Recruiters Come To You](https://link.jointaro.com/rxqDDu4sgMQbP6LT8)
- [Why Side Projects Are So Powerful For Junior Engineers](https://link.jointaro.com/cFo3doiWDeE5dpa67)
- [How To Split Your Time Properly Between Work & Side Projects](https://link.jointaro.com/YFCmNrsdqhuMSeUw5)

Write A Stellar Resume As A Software Engineer [Part 4] - 1 Resume To Rule Them All

Writing tons of different resumes is one of the easiest ways to waste time and overwhelm yourself on the software engineer job search. This lesson teaches you:

- Why you should only have 1 resume, especially if you're an earlier-in-career engineer
- Why "full-stack" engineer is often a trap for more junior engineers
- How to figure out the 1 resume you should write
- What to do if you really can't write just 1 resume (i.e. how to break the tie)

[Case Study] Solving A Multi-Million $$ Instagram Bug

- A big part of moving from L4 (mid-level) to L5 (senior level) is being able to create your own scope. You can't just expect a perfect suite of projects to come from your manager.
- Like in this session's case study, bugs are a great source of finding your own scope!
- The bug was very slight: Instagram story ads started off on the wrong part when they were resurfaced to a user. As an Android engineer, Alex discovered this in IG Android initially. This bug had been in production *for over a year* at this point.
- How Alex expanded the scope after finding this bug:
  - Worked with iOS to see if the bug was there (it was)
  - Worked with PMMs to confirm that this violated the advertiser contract and merited a refund. This made the bug an immediate SEV.
  - Worked with a data scientist to figure out exactly how many times this bug occurred and calculate the exactly refund to advertisers ($2M+)
  - Put the fix behind an A/B test to measure impact and make sure it was working
- How you can incorporate the learnings from this case study:
  - Be detail-oriented. At Big Tech in particular, seemingly small issues can have massive impact.
  - Don't just silently fix bugs. Take the time to figure out its entire scope - It could be a SEV!
  - Understand the world outside of yours. Look for opportunities to bring in others (especially those of different roles) into what you're working on to expand scope for everyone!

Here's the [link to the slides](https://docs.google.com/presentation/d/1vPtelhi5caMsZNC-XFGhy1FtRveIbNxg0k3LZctRPOs/edit?usp=sharing).

For more resources around creating scope:
- ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://link.jointaro.com/uBcb5LjZiD5DasfB9)
- ["How can I come up with big initiatives, especially those at a Staff level?"](https://link.jointaro.com/6MWig3VSr3nVo81w9)

Amazon Case Study: The Ultimate Guide To Navigating A PIP

Case studies are valuable to (1) realize that you are not alone and (2) learn from the experiences of others and see what you can apply.

We’ll start with a new grad Amazon engineer who joined during the pandemic.

- **Before**: First job out of college, was on Focus after 6 months
- **During**: Shocked when they found out (URA quota suspected). Manager became more “HR-like”, less candid
- **After**: Went through the PIP and failed, even though they showed improvement

Grow From Senior To Staff Engineer [Part 3] - At A Glance: Senior Vs. Staff

As a senior engineer, you have probably gotten generic guidance on how to get to staff, advice like *"Do more leadership"*. Let's rise above the meaningless engineering career matrix standards and provide something concrete. This lesson teaches you:

- How the dynamic evolves between an engineer and their manager as they grow from senior to staff
- The core behavioral difference between senior and staff engineers as they tackle problems
- The difference between senior and staff engineers with the projects they work on
- The difference between senior and staff engineers with their ownership reach
- The difference between senior and staff engineers with their organizational reach

You did everything right. That wasn’t the problem.

Some people move up because they ask for more.\
Others move up because they already act like they own more.\
Then there’s the third kind—the ones still waiting for someone to notice.

If that feels familiar, this section will explain why hard work alone isn’t the lever you think it is.

**Want to go deeper?**

- Explore more tools and courses at [**Taha’s Method**](https://www.tahasmethod.com/) — from interview prep to leadership development.

- Follow me on [**LinkedIn**](https://www.linkedin.com/in/tahahussain/) and subscribe to my weekly newsletter, [**The Conscious Leader**](https://tahahussain.substack.com/), for more lessons like these. 

- **Taro members get 30% off** my flagship course [**Top Tech Leader**](https://bit.ly/tarotopleader)*. Discount available later in the course.*

Grow From Mid-Level To Senior Engineer [Part 3] - At A Glance: Mid-Level Vs. Senior

What exactly does it mean to be a mid-level engineer vs. a senior engineer? What's the gap? This lesson teaches you:

- What it means at a high-level to be a mid-level engineer vs. a senior engineer
- The types of projects mid-level engineers work on vs. a senior engineer
- The ownership and scope difference between a mid-level engineer vs. a senior engineer
- The difference in organizational complexity between mid-level engineers and senior engineers

[Masterclass] How To Choose A Good Company And Team As A Software Engineer

Choosing the right company (or team) is one of the highest leverage decisions you'll make in your career, so it's worth doing some reflection!

It’s all about your priorities

- Figure out what’s important to you and what’s not. Create a stack-ranked list of all of these and work backwards from the top 2-3 to figure out the best opportunities for you
- People don’t realize how many angles there are to this. Here’s all the ones from the presentation: *Compensation, work-life balance, company prestige, supportiveness of team, growth opportunities, stability, maximum outcome (risk), remote work, product space, company ethics, technical space, level/title, benefits, location*

Supportiveness and overall quality of the team are often underrated

- It’s really hard to grow and have a healthy work life without this
- If you like your manager/teammates and you feel like you’re regularly learning/being challenged by them, deeply cherish that. People underestimate how hard it is to find an environment like this. Even in a prestigious company like Big Tech, this is difficult to find.

Big Tech vs. Startups

- At the end of the day, it’s all about your risk tolerance - Startups can have insane monetary/promotion outcomes, but they also might collapse the next year.
- In a vacuum: Start off at a Big Tech company to build a good foundation and then switch into smaller companies to have more scope/ownership

Some things you should NOT spend time on:

❌ Don't focus on how much you liked (or did not like) the people in the interview process. The recruiter/interviewer is NOT representative of your life at the company. Instead, focus on trends of the people joining the company, rather than individual data points.

❌ Don't spend time looking at the financials of the company. Even if you do decide to dig into the numbers, there's a good chance you'll screw up the interpretation -- humans have a really hard time with exponential growth.

Learning the quality of a team

- Talk to engineers/ICs if you can - The manager will inherently be biased towards their own team as they are often goaled on hiring
- Make sure that the team has a healthy oncall process and fast code review iteration

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/)
- [“How can you tell if a large public company is going in the right direction?”](https://www.jointaro.com/question/TrlweQQ7DveTnYBP9VUH/how-can-you-tell-if-a-large-public-company-is-going-in-the-right-direction/)
- [“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/)
- [“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/)
- [Presentation Slides](https://docs.google.com/presentation/d/1S_kULq5zzVLkcoKy0bKJ2IHSrjL3s2VbOLe8p1TQJ7s/edit?usp=sharing)

[Masterclass] How To Learn Quickly In Tech

Related resources:
- ["How do I identify the core things to learn when picking up a new tech stack?"](https://www.jointaro.com/question/0VfjTWl2gxCKS0PRHpRT/how-do-i-identify-the-core-things-to-learn-when-picking-up-a-new-tech-stack/)
- ["What’s the most effective way to switch domains in tech?"](https://www.jointaro.com/question/eFr9vsyTSiYLCbtsj7RR/whats-the-most-effective-way-to-switch-domains-in-tech/)
- [Presentation Slides](https://docs.google.com/presentation/d/1C0RYphpovijVp8s3JVjG9iYFT6hgPJNHabIeP8WF7V4/edit?usp=sharing)

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 Write A Stellar Tech Resume That Gets You More Job Opportunities

Writing an effective resume is crucial for succeeding within the tech industry, especially for software engineers. It's the primary step you need to clear before getting a chance with an interview opportunity. Unfortunately, there is a lot of misinformation around how to write a good resume: For 80%+ of junior software engineers struggling to break into tech, a poorly written resume is one of the main causes.

All that being said, here are our Top 5 points from the sessions (in no particular order):
1. *Remember that a recruiter is reading your resume and will, on average, only spend ~10 seconds on it*
    - They are almost certainly non-technical. Make things very accessible and easy to understand: Avoid jargon!
    - Be ruthlessly concise. For the vast majority of cases, your resume should only be 1 page.
2. Having a spelling or grammar mistake is the easiest way to get your resume thrown out
    - You have an effectively infinite amount of time to polish your resume. If you can't even catch basic mistakes like these, it shows that you have poor attention to detail or bad prioritization.
3. Show, don't tell
    - Don't just say that you're great, prove it
    - Example: Talking about the Android apps you've built with 100k+ users is much more effective than just saying you're a great Android engineer
4. Traps to avoid:
    - Having a summary section at the top
    - Self-rating yourself across skills
5. In the end, your resume needs to be approved by a human, not just an ATS
    - Making your resume very weird to "optimize" for the ATS is the epitome of winning a battle to lose the war. It's pointless

For an effective example + template you can use, [check out Alex's latest resume here.](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/articles%2FAlex%20Chiou%20Resume%20-%20FINAL%20FOR%20SHARING.docx?alt=media&token=3a75b8b2-09e8-4b68-b80d-22761055c3b2) You can import it into Microsoft Word online and swap out all of his content with yours.

Related 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/)
- [Presentation Slides](https://docs.google.com/presentation/d/15eLqE_WmePLA--lYTG0ZJVcHhpEld2qNTck_w0t_E9k/edit?usp=sharing)

DSA Crash Course [Part 9] - Anagrams Walkthrough

In this lesson, Alvin walks through the python implementation for the *anagrams* problem.

Code along and test your work in the following editor workspace <https://structy.net/problems/anagrams?language=py>

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

Level Up Your Code Quality As A Software Engineer [Part 11] - Case Study: Signup Form Edge Cases

So how exactly do you figure out the edge cases with a piece of software? Well, it's hard work, especially as the volume of edge cases scales up exponentially with the complexity of the underlying feature. This video will teach you:

- A process to think through edge cases step-by-step through the stack with an *incredibly* in-depth example covering one of the most classic features virtual every tech company ever has: The email and password signup flow
- Why Big Tech companies hire so many software engineers to build out seemingly basic CRUD applications (hint: They're not basic, not at all, and the signup form case study will prove that to you)

Ship & Grow 500k+ User Side Projects [Part 2] - Done Is Better Than Perfect

Code quality is important, but side projects sort of break the rules here. This lesson teaches you:

- How good engineers often mess up their side projects from the very beginning
- Why making mistakes is perfectly fine (good even) when starting a side project
- How fast you should launch the v1 of your side project

[Masterclass] How To Ace Your Big Tech Interview - System Design

System design is a crucial software engineer interview skill, especially for FAANG and Big Tech in general. It is effectively a requirement to be leveled at a senior software engineer or higher and will show up in mid-level engineer interviews as well (with the occasional appearance in even junior engineer interviews). The cool thing about system design (unlike data structures and algorithms) is that it's something you actually need to do on the job.

Here are our Top 5 points from the session (in no particular order):
- **Leverage engineering blogs of top companies** - And if you're applying to one of these companies, definitely read their blog. This will help you understand their high-level design and gives you a real-world example to anchor off of, as opposed to something more abstract and high-level that you would get from a traditional book.
- **Do NOT write code** - System design is a *high-level* exercise meant to gauge seniority. Writing raw code is the mark of a more junior software engineer, which is why you should never be writing code in a system design interview. Instead, draw boxes with arrows where the boxes represent components and the arrows represent how they interact.
- **There is no right answer** - One of the main reasons software is hard is because of how open it is. For any complex technical problem, there will be several good solutions, each with varying tradeoffs. System design is not like school or DSA where there is a singular right answer.
- **Understand the problem requirements** - System design problems are, by design, very open-ended. For example, if you get "Build the Twitter feed", there are so many features that make it up: There is no way you can design the entire thing in 1 interview round. Work with your interviewer to understand the scope of the problem and which parts should be prioritized.
- **Follow mature software principles** - The 5 covered in this presentation are robustness, scalability, performance, extensibility, and resiliency. Don't just get the happy flow working - Think about how your system will react when edge cases are hit and things go wrong.

Related resources:
- [How To Ace Your Big Tech Interview [Data Structures & Algorithms]](https://link.jointaro.com/iTNxPCvkdGite4wT9)
- [System Design Series: Taro Playlists [Part 1] - What REAL System Design Looks Like](https://link.jointaro.com/4obaFizTZAdAcStY6)
- [Presentation slides](https://docs.google.com/presentation/d/1z4yX5LiiSxbHiNrBOTPIiDfhBL5qmwRUrDojT71OROY/edit)

Don't Learn Code In This Way - How Software Engineers Waste Time

So many software engineers mess up when they're trying to learn code by bringing over a bad habit from school: Studying. This is simply not how software works, and this video's here to explain why.

Here are the core points:
- **Reading code and documentation is ineffective** - You can't purely read your way towards a good understanding of a codebase; it will get you 10-15% of the way tops. Software is fundamentally about doing - The actual learning begins when you jump in and start playing with the code. On top of all this, it's much better to get a high-level understanding of the codebase by asking your teammates for it instead of trying to infer it yourself from raw reading.
- **Documentation gets worse the better the company is** - Good software companies are fast-moving. This is a big reason why FAANG is successful: They are able to still move quickly despite their immense size. Because of this, documentation is rarely kept up to date due to how fast the codebase evolves. In fact, excessive reading of documentation may actively harm you if it contains legacy patterns that aren't accepted at your company anymore.

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. You can watch it here: [[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer](https://www.jointaro.com/lesson/n384HdJuDgulSHbHQLnf/masterclass-how-to-succeed-at-a-new-team-or-company-as-a-software-engineer/)

So now that you know how NOT to learn a codebase, here's some resources on how to actually learn a codebase:
- [How To Learn A New Codebase Fast](https://www.jointaro.com/lesson/DX27hiXPJ4G7Czk2mwLL/how-to-learn-a-new-codebase-fast/)
- [Learning A New Codebase? Here's How To Figure Out What Matters](https://www.jointaro.com/lesson/dQXKZNqivtoByEHV9V17/learning-a-new-codebase-heres-how-to-figure-out-what-matters/)
- ["How can I learn a large codebase fast as an intern?"](https://www.jointaro.com/question/F2rJZgdUBxdGZilFTR6k/how-can-i-learn-a-large-codebase-fast-as-an-intern/)

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.

Level Up Your Code Quality As A Software Engineer [Part 6] - Embrace The Pain

A defining characteristic of mediocre software engineers is that they run away from problems in their code and avoid confronting hard problems in general. This lesson will teach you:

- Why (and how) you should embrace the pain if you truly want to write better code as a software engineer
- The process to follow to go from writing bad code to good code
- What it means to actually learn system design
- How to level up your technical understanding with an in-depth example from Alex's past about how he truly mastered a deep Android concept and applied that mastery to learn iOS development almost instantly

Create An Onboarding Doc

The **onboarding doc** is a reference guide as you join the company. This document is literally designed for you, outlining your role + team, people to meet, and how you can get started. Generally, your manager will provide an onboarding doc for you, but you should feel free to augment or create your own if the doc is lacking. This is a great place to collaborate and deepen your relationship with your manager -- point out further areas of discussion.

Components of a good onboarding doc:

1. Team charter (translated down from the company mission)

2. Partner teams + people

3. Expectations + milestones 

   1. These should be clearly defined so it'll be clear if you achieved the expectation or not

4. Project ideas with t-shirt sizing

5. Engineering rubric or career matrix for your role, if one exists

Reference question: [What should be part of an onboarding doc?](https://www.jointaro.com/question/FL7XdfLsG9Da6YyfbjZ3/what-should-be-part-of-an-onboarding-doc/)

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.