Write A Stellar Resume As A Software Engineer [Part 9] - I Know (Suck At) Everything

When it comes tech stacks on your resume as a software engineer, less is usually more. This lesson teaches you:

- What employers are looking for when it comes to an engineer's technical skills on their resume
- Why it's dangerous to put a bunch of technical terms (i.e. keyword stuffing) on your resume
- A simple framework to determine whether or not you should put a technical term (programming language, library, domain) on your resume

Take the code quality course here: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

Grow From Mid-Level To Senior Engineer [Part 5] - Finding The Right Team

Not every engineering team can support an additional senior engineer. This lesson teaches you:

- What to look for in terms of product scope when choosing an engineering team to grow to senior
- The people ingredients of a team that's good for senior promotion
- Exactly what a great team for senior promotion looks like

To dive deeper into how to find a great team for senior promotion, check out the discussion here: ["What questions can I ask a potential new team?"](https://www.jointaro.com/question/dLS6KcDwKNdMDlJwYdBw/what-questions-can-i-ask-a-potential-new-team/)

Level Up Your Code Quality As A Software Engineer [Part 5] - Fake "Clean Code" Shortcuts

A lot of software engineers want shortcuts: They want to find the optimal tech stack, programming language, and framework to slot into their code so it's automatically the best and they have conquered code quality. Unfortunately, that's just not how code quality works. This lesson will teach you:

- Why having truly good code quality is so, so hard and more about building up fundamental technical skills
- How to have a proper senior engineer mentality around "clean code" and how to extend a codebase
- Common fake "clean code" shortcuts that engineers desperately want to believe but ultimately aren't true (often stemming from obsession with FAANG and Big Tech)

Senior Engineer (L5) Describes Most Important Skill - Richard Chen

Richard is a Senior Engineer (E5) at Meta.

- **Most important skill**: correct project selection. This requires balancing outcomes, priorities, and risks.
- **Advice**: bring people along with you. Careers are built over the long-term, so it's important to treat partners and work colleagues well.

Here's the full playlist asking engineers what the most important skill is for their level: [Asking 7 Levels Of Engineers The Most Important Skill](https://www.jointaro.com/playlist/J9Io5lDGaYUpI8vGrUyI/)

Helpful links:
- Taro's top 10 to get promoted from [entry-level to mid-level engineer](https://www.jointaro.com/playlist/iBKHYpkjd0BRWWLKQG2j/)
- Taro's top 10 to get promoted from [mid-level to senior engineer](https://www.jointaro.com/playlist/AUMiBTvYUv0gcOzuu26V/)
- Taro's top 10 to get promoted from [senior to staff engineer](https://www.jointaro.com/playlist/YD8LMCSlE71VUGUbNAWM/)
- [Richard on LinkedIn](https://www.linkedin.com/in/r-x-c/)

System Design Series: Taro Playlists [Part 4] - Covering Edge Cases

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

- You should *always* at least try to cover all the edge cases when building out a product, even if you're a small startup.
  - If you're at Big Tech in particular, you absolutely need to have amazing coverage on edge cases as even an issue affecting just 1% of users could be breaking the experience for 10 million+ people.
- A lot of edge cases are quite easy to cover and are low-hanging fruit. Bad engineers will be lazy and ignore these, supposedly in the name of velocity.
  - **Example:** You have a login form that takes in email. Instead of no-oping, throwing a generic error, or letting them login with an invalid email, validate the email upon submission and show an error message if it's invalid. This will almost always be a 5-10 minute change.
- There's many "playbooks" of edge cases, so coming up with edge cases isn't rocket science - It's largely a solved problem. Here are some examples:
  - **Generic edge cases that apply to any user input:**
    - Input is blank
    - Input is overly long
    - Input is very strong
  - **Generic edge cases that apply to any content collection:**
    - No content
    - A lot of content
    - Content fetch fails
- *Being very diligent around edge cases is also crucial for interviews, both DSA and system design, and is often how Big Tech interviewers differentiate the great candidates from the mediocre ones.*

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're designing systems at your job!

[Case Study] Maximizing SWE Growth: Ownership and Specialization At Startups

**Huge** thanks to [Henry Prior](https://www.linkedin.com/in/henryprior/) for joining us and sharing his perspective and insights!

This was a *massive* session, so here are just some of the highlights:
- **Henry's core learning**: Bias towards action. You aren't really going to truly understand what is and what isn't fruitful to you until you just start trying things.
- **Story #1** - At his first startup job, Henry found a project to upgrade from Tensorflow 1 to 2. This ended up moving the metric he cared about, but he found out later that the business impact wasn't great. The company's clients were non-technical and didn't really care about the company's model being ultra-accurate.
- **Story #2** - Found a reinforcement learning project at his next company where he did all the modeling on his own and worked closely with an infra engineer to ship. The work was very complex and had huge impact, saving ~25 hours per week in Data Scientist cycles. He got massive recognition from the company, and this project was a big part of his move to senior.
- You have a lot of autonomy in early stage startups. Take advantage of this and actively look for large problems to solve, doing so as early as the interview process. It's not like Big Tech where you are generally given a good amount of direction on what to do (at least until you get to staff).
- *It's in your best interest to be completely authentic when interviewing with a startup.* It's not like Big Tech where you're putting on a facade to meet their interview requirements. A startup might not be the right for you due to a lack of work in your interest area: Big Tech in contrast has a little bit of everything.
- *If you're going to get into machine learning, you should understand the underlying math first.* This puts you in a much better position to work on the modeling part of ML vs. the more tertiary tasks like data wrangling. The math is a combination of probability/statistics, linear algebra, and calculus.
- **You can't study your way to being good at system design.** Resources like books and blog posts help, but system design is something you very much have to get good at by doing. Instead of just leaping into the code, start planning out your tasks and doing technical writing. From there, share your material with your team and get feedback.

Related resources:
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://link.jointaro.com/yzWgzTF4WFzfXjS29)
- ["Does it make sense for me to choose a specialization like ML? If so, what's the impact?"](https://link.jointaro.com/jV34Jz7cJqQv2MpD8)

Easily Level Up All Your Meetings By Taking Notes

What is the most straightforward way to level up a meeting?

True or false: Maintaining a good set of meeting notes can help you substantially with promotion.

Which of the following are benefits of maintaining meeting notes?

Meetings are extremely expensive, because they take time. To make sure that you're not wasting time with your meetings, you should always be doing the simple yet effective task of taking notes.

Here are the core points from the video:
- **For recurring meetings, maintain a running doc** - This applies especially to 1 on 1s and team meetings. *If you're not talking during a meeting, you should be writing*. These notes allow everyone in the meeting to quickly absorb prior context and hit the ground running in the current meeting.
- **Come into every meeting with a written agenda** - >24 hours before the meeting, write down an agenda into the meeting notes doc and let the other other in the meeting know. This will anchor the discussion to minimize its chances of going off-track and shows great initiative on your end. 

Related resources:
- [[Masterclass] How To Get Promoted Faster In Tech](https://www.jointaro.com/lesson/W730BOdrfAIXAEVd8HUf/masterclass-how-to-get-promoted-faster-in-tech/) - The promotion talk referenced in the video
- ["How can I be more active in meetings and earn the respect of senior engineers?"](https://www.jointaro.com/question/RtISfsqipLWBhZxvyl69/how-can-i-be-more-active-in-meetings-and-earn-the-respect-of-senior-engineers/)
- ["How to hold people accountable for Action Items/decisions from meetings?"](https://www.jointaro.com/question/Jh8xg2KYi9utvUv9jUeO/how-to-hold-people-accountable-for-action-itemsdecisions-from-meetings/)

Top System Design Interview Mistakes [Part 5] - Don't Over or Under-Engineer a System

In system design interviews, it's crucial to strike the right balance between complexity and simplicity in your solutions. This video highlights the importance of avoiding both over-engineering and under-engineering:

- Designing systems with unnecessary complexity can lead to wasted resources, higher risks of bugs, and an impractical solution
- While caching can improve performance, indiscriminately adding caches without careful consideration can introduce inconsistencies and unnecessary complexity
- Rather than adding complexity for its own sake, stay focused on the unique challenges of the problem at hand to identify the most effective solutions
- Thoughtfully evaluate where to apply caching or other optimizations by weighing the benefits against the potential downsides
- Ensure that your design decisions are driven by the specific needs of the problem, rather than trying to impress the interviewer with buzzwords or unnecessary tools

This approach helps create efficient and practical solutions tailored to the specific challenges of the interview prompt.

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>

Asking Great Questions [Part 1] - How This Course Works

As a software engineer, you need to learn fast, and in order to do this, you simply have to ask a *ton* of questions. This course is here to teach you how you can ask high quality questions that get you the answers you need while *increasing* your reputation among the team. 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 across top companies like Meta and Robinhood, explaining how he was able to raise new-grad Meta engineers \[E3\] all the way to high-performing tech leads \[E5, Greatly Exceeds Expectations\] in just 3 years

- You'll understand why asking questions is an art with a high skill ceiling, not a binary choice between *"Do I ask"* and *"Do I not ask?"*

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

  - 🧠 Have the right **mentality** behind asking questions

  - 💡 Turn questions into a **strength**, not a weakness

  - ✨ Understand the difference between a **high-quality** question and a **low-quality** question

  - ⚙️ Ask stellar **technical** questions

  - 🙏 Ask for **favors** effectively

If you want to learn how Alex got his mentees promoted so quickly: [\[Case Study\] Mentoring Junior SWEs \[E3\] to Senior \[E5\] In Just 2.5 Years At Meta](https://www.jointaro.com/lesson/EX9563YnxcJb62cCmetg/case-study-mentoring-junior-swes-e3-to-senior-e5-in-just-25-years-at-meta/)

Master The Behavioral Interview [Part 13] - Good Vs. Bad Questions To Ask

You're a software engineer and you have slogged through the behavioral round, answering many grueling questions. And now the interviewer opens up the floor to you: "Do you have any questions for me?". What do you do here? This lesson teaches you:

- What a good behavioral interview question to ask looks like through many examples, which you can ask word-for-word in your next behavioral interview
- What a bad behavioral interview question looks like (avoid these)
- The attributes of a high-quality question vs. a low quality question in a behavioral interview

[Distributed Systems Deep Dive] Design a KV such as Dynamo DB

This is a session on DynamoDB if you're looking to understand how to design a distributed key-value stores. We'll start with what DynamoDB is and why people are using it. Expect a run-through of its architecture and a straightforward explanation of how data gets sliced for efficiency. We'll also cover what happens when things go south and how DynamoDB keeps data consistent and up-to-date as well as the pros and cons.

If you write code and care about making it scale, this will be worth your time.\
\
**Dynamo Basics:** Understand what DynamoDB is built for and when to use it over other databases.

1. **Architecture:** Get to grips with DynamoDB's architecture - how it's built to scale effortlessly and provide consistent performance.

2. **Data Handling:** Learn about partitioning strategies that spread data across nodes effectively and replication techniques that prevent data loss.

3. **Resolving Conflicts:** Master vector clocks for resolving data conflicts in a system designed for eventual consistency.

4. **Operational Workflow:** Gain insight into the lifecycle of 'put' and 'get' operations and how DynamoDB handles data under the hood.

5. **Merkle Trees:** Understand how DynamoDB uses Merkle trees to synchronize data across distributed systems efficiently.

6. **Gossip Protocol:** Learn the workings of the gossip protocol for node communication and how it contributes to DynamoDB's robustness.

Thanks to [Alex Poon](https://www.linkedin.com/in/thealexpoon/) for leading this session!

Level Up Your Code Quality As A Software Engineer [Part 18] - Have A Test Plan

Test plans are something many tech companies don't do, and it's a shame. Pull request test plans are one of the easiest things you can do as a software engineer to really level up your code review experience and ultimately the quality of your code. This lesson will teach you:

- What a test plan is and the many, many benefits it provides. There's a reason Meta requires engineers to have a test plan in their diffs (pull requests)
- How to creative with your test plans when your code is hard to demo (very applicable for back-end facing engineers)
- The many benefits of having a thorough test plan and the many downsides of not having a test plan
- What the ideal test plan looks like, which we'll cover through a couple in-depth examples

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)

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)

The Journey to Staff Engineer In Big Tech - Q&A

This is the Q&A portion of the Staff Engineer Panel discussion. Watch the [main content here](https://www.jointaro.com/lesson/SaYyJGLYvrAy4XGrDhy7/the-journey-to-staff-engineer-in-big-tech-panel-discussion/).

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. 

Questions answered in the video: 
- I'm making a career change into Software Engineering -- what advice would you have? I want to get into Augmented/Virtual Reality.
- I'm already a Staff Engineer, but I'm struggling with performance management. What advice would you have to exceed expectations?
- What resources would you recommend to improve at communication? What is an effective way to find a mentor?
- I'd like to first become a Tech Lead (TL) and then transition into a Staff Engineer role. What advice would you have for me?
- I'm a Data Engineer (DE) and big fan of Zach! How do I show the impact of my work to a manager who may be unfamiliar, especially since I don't do frontend?

See discussions about Staff Engineers on Taro: [https://www.jointaro.com/topic/staff-engineer/](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/)

[Case Study] Building An App With 1,000,000+ Users To Get Into Facebook

If you want to hear an in-depth \~30 minute breakdown of Alex's entire journey getting the Facebook offer, watch our video here: [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/)

To learn more about how to build effective side projects, check out these 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/)
- ["How Long to Crank Out a Decent Side Project?"](https://www.jointaro.com/question/QA6lCGdPpwAd3xRrpjZ7/how-long-to-crank-out-a-decent-side-project/)
- [How Alex Made An App That Got 80k+ Users In 1 Month](https://www.jointaro.com/lesson/GlSjjLhuUdHt5drq3l5F/how-alex-made-an-app-that-got-80k-users-in-1-month/)
- [Presentation slides](https://docs.google.com/presentation/d/1MJU_LPnfc_QEu7386eSFvIbopG2VVUE3lTzkA458bYU/edit?usp=sharing)

If you want to dive deeper into the Random Name Picker app:
- [Download it on Google Play](https://play.google.com/store/apps/details?id=com.randomappsinc.studentpicker)
- [GitHub Source Code](https://github.com/Gear61/Random-Name-Picker)

The Biggest Benefit Of Working At Big Tech - Learning Proper Engineering Skills

We all know how powerful Big Tech is when it comes to its top-of-market compensation and resume power. However, there is a much bigger long-term benefit these prestigious companies have when it comes to software engineers.

Here are the core points from the video:
- **Big Tech is stellar at teaching proper engineering** - You simply can't reach 100 million+ users without being great at software engineering. These companies have the experience and history to show software engineers how things should be done.
- **You will be pushed to be better** - Big Tech invests billions in hiring the absolute best tech talent in the world. In order to ship quality products at scale, these engineers push each other constantly to do the right thing. When you work at Big Tech, you become a part of this process and peer pressure.
- Here are just some of the ways this learning manifests:
  - Thorough release process with staged rollout and deep analytics
  - Code review where you get tons of comments on how to improve
  - Great internal tooling showing you what parts of the engineering experience can be made seamless

Related resources:
- ["How do I get better at building Large scale systems without working directly on such projects?"](https://www.jointaro.com/question/k9MR0UBCtVXvyZrOdPLw/how-do-i-get-better-at-building-large-scale-systems-without-working-directly-on-such-projects/)
- ["How to Learn/Practice Clean Code, particularly by oneself?"](https://www.jointaro.com/question/6DcTkiS9UJhDkQz1HIAL/how-to-learnpractice-clean-code-particularly-by-oneself/)
- ["What are the best resources to learn system design in a structured way?"](https://www.jointaro.com/question/SeCsb4IRTijs2hg4XHxo/what-are-the-best-resources-to-learn-system-design-in-a-structured-way/)

This Is What A Good Code Review Test Plan Looks Like

In this segment, we highlight a real-world example of an **exceptional test plan** that showcases how thoughtful demos not only validate functionality but also build confidence and trust before a single line of code is reviewed.

### Key Takeaways:

- **We use test plans to demonstrate functionality and edge cases**: In this example from the Random Name Picker app, the test plan includes both the core feature (removing images from names) and handling an edge case (screen rotation), showing completeness and attention to detail.
- **We treat test plans as trust tokens**: A strong demo assures reviewers that the author has thoroughly tested their changes, reducing fear or hesitation around approving the diff.
- **We provide a positive starting point for reviewers**: Watching the video demo first puts reviewers in the right mindset—making them feel confident that the code works as intended, even before reading the diff.
- **We recommend test plans for all product-facing diffs**: Especially when there’s a visual or user-facing component, attaching a video or GIF dramatically improves understanding and quality of collaboration.
- **We invest a few minutes to add a lot of value**: Creating a short demo takes just 5–10 minutes, but it adds context, transparency, and professionalism that elevate the entire code review experience.

Master The DSA Interview [Part 17] - How To Pass FAANG DSA Rounds

Why is it so hard to break into FAANG? Well, it's because FAANG tends to push engineers far harder on data structures and interviews problems. This lesson teaches you:

- The score spectrum FAANG interviewers use to grade candidate
- What it means to get a "Yes" vote on a data structures and algorithms round
- What it means to get a "Strong Yes" vote on a data structures and algorithms round (very important when the market is bad)
- What a strong passing data structures and algorithms interview performance looks like, explained with an in-depth example

Maximize Your Productivity As A Software Engineer [Part 9] - Focus Blocks

Context switching is one of your biggest enemies as a software engineer. This lesson teaches you:

- What a focus block is
- Why getting back into coding is so difficult, especially at Big Tech
- The power of focus blocks with involved tasks, particularly with writing code

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.