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)

Master The Behavioral Interview [Part 2] - You're (Probably) Sleeping On Behavioral

Grinding LeetCode endlessly makes no sense and will not get you a great software engineer job, especially in a bad market. So why does it makes no sense? Because data structures and algorithms (DSA) rounds are far from the most important. This lesson teaches you: 

- The reason why companies weigh behavioral interviews so heavily (usually more than candidates realize)
- Why behavioral interviews are actually the most important interview type
- How engineers waste the precious time they have in behavioral interviews

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

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.

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

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

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)

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

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

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

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

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

How To Earn Respect Fast - Senior Engineer Onboarding Story

Even if you're onboarding, you can earn respect amongst your team. In fact, you should feel empowered to earn this respect despite being new, especially if you're a senior software engineer.

Here are the core points from the video:
- **Help junior engineers** - This is one of the most effective ways to earn respect on a team as a more experienced engineer. The junior engineers may be more fluent in the code than you are, but if you're a senior+ engineer, there is a reason you have this level: You have certain fundamentals and instincts that are applicable everywhere that junior engineers don't really have.
- **Show your depth** - You won't win with velocity and output when you're new. However, you can win with depth and quality as that's largely a function of your effort and time. If you're a more experienced engineer, think about how you can go deeper into something than everyone else on the team.
- **Alex's senior engineer onboarding story** - Here's how a senior Android engineer quickly made a splash after joining Alex's team back at Instagram.
  - They saw a junior engineer struggling with a very complex text layout bug with the Instagram Android app.
  - They volunteered to help with this bug, even though they didn't have to.
  - After many failed debugging attempts, *they slowly extracted the relevant code line by line into an entirely separate Android app to identify the breaking line*. This was a brilliant tactic that nobody else on the team even remotely considered.
  - This combination of goodwill and extreme software engineering depth earned them a mountain of respect pretty much immediately.

This clip is from our masterclass on how to succeed at a new team or company as a software engineer. [Click here to watch the full thing.](https://link.jointaro.com/9sJzfDeH3JdWzZRg9)

Related resources:
- ["How can I quickly gain respect among my team as a senior engineer?"](https://link.jointaro.com/i9j4dtohx2bXc2Sq8)
- ["How do you network effectively within a company?"](https://link.jointaro.com/Hr1nr53D7sfQAEv3A)

DSA Crash Course [Part 18] - Recursion Intro Lecture

In this lecture, Alvin introduces the mental model we should use when applying recursion.

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

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

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

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

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

Introduction To The Course

Welcome to our course on Input Metrics, grounded in our experience at Amazon. Our goal is to help you understand and apply the principles that drive consistent business success. This course is designed to transform how we manage performance—shifting from relying solely on output goals to mastering the inputs that lead to great outcomes.

### Key Takeaways:

- **Course Goals**: We’ll learn how to deeply understand input metrics, identify the right ones for our business, measure and analyze them, conduct effective Weekly Business Reviews (WBRs), and implement the WBR reporting tool to visualize data clearly.
- **Real-World Application**: We share Amazon-proven strategies and offer downloadable templates, documents, and tools to support real-world execution of these practices.
- **Amazon’s Shift in Strategy**: We recount Amazon’s turning point in 2000—moving from output-focused goals to a system of input-driven process control, which delivered lasting results.
- **Input vs. Output Mindset**: Instead of telling teams to just hit output targets, we equip them to understand and improve the specific inputs that lead to success—driving better outcomes like increased sales and customer satisfaction.
- **Why It Matters**: Studying input metrics gives us greater control over operations and helps us empathize with customer pain points—fueling continuous improvement and innovation.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

[Masterclass] How To Navigate Your Performance Review In Tech

The slides provide a great high-level overview of the entire session for your notes, so here's our Top 5 thoughts that aren't entirely in the slides:

- Not deeply understanding your company's performance review cycle is job suicide, especially in the current age of layoffs and stack-rank (the latter being perennial).
- If you're truly working at a top company, you shouldn't be promoted to the next level unless you have been functioning there for at least 3-6 months. Companies that don't do this tend to promote due to raw experience and have many incompetent people at senior+ levels.
- Always have a plan for your performance review, even if your goal is just to be average and survive. Work with your manager at the beginning of every cycle to create a clear and living expectations document.
- Be very deliberate about the peers you want leaving feedback for you on your performance review. Assemble that cast at the beginning of the cycle and start building those deep 1 on 1 relationships once you have done that.
- When you are asked to leave constructive feedback for a peer, flip the question from *"What did they do poorly?"* to *"How can they expand their scope?"*. This will become easier as you reach an L5 (senior) level and more deeply understand what each engineering level means.

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/)
- [\[Masterclass\] How To Get Promoted Faster In Tech](https://www.jointaro.com/lesson/W730BOdrfAIXAEVd8HUf/masterclass-how-to-get-promoted-faster-in-tech/)
- [\[Masterclass\] How To Have Impactful 1:1 Meetings](https://www.jointaro.com/lesson/FEK6JZqW2Jg3rdN9yeGn/masterclass-how-to-have-impactful-1-on-1-meetings/)
- [Presentation Slides](https://docs.google.com/presentation/d/142PsWRJ-fmdP42CrFpR0VD64L1qFP-6nPTmjk5g1DKM/edit?usp=sharing)

Growth And Promotion 3/6: The Career Growth Recipe

The Magic Loop of Rapid Career Growth: a tested, simple process to grow your career. The “Career Growth Recipe” outlines a simple loop of five steps to advance your career: do your job well, ask how to help, fulfill requests, set goals, and repeat.

- 🎩 The Power of the Magic Loop: This framework emphasizes a collaborative approach to career advancement, fostering mutual support between employees and managers. By centering on shared goals, individuals can navigate their career paths more effectively.
- ✅ Performance Matters: Success starts with delivering exceptional work. Regularly assessing your performance through feedback can illuminate areas for improvement and reinforce your value in the workplace.
- 🤝 Building Relationships: Asking how to help is a proactive strategy that not only strengthens relationships with leadership but also positions you as a valuable team member willing to contribute beyond your immediate responsibilities.
- 🔄 Commitment to Tasks: Following through on tasks assigned by your boss demonstrates reliability. This commitment can pay off in terms of trust and future opportunities, making you a preferred team member for significant projects.
- 🎯 Goal-Oriented Conversations: Once trust is established, discussing your career goals with superiors can lead to tailored support for your ambitions, fostering a clear path to advancement.
- 📈 Continuous Learning: Embracing feedback as a tool for growth is crucial. It helps you identify blind spots and improve your performance, making you a stronger candidate for future opportunities.
- 💡 Adaptability and Initiative: Taking on tasks outside your comfort zone and asking for help when needed not only aids personal growth but also enhances your skill set, making you more versatile in your career.

Starting at Amazon as a Senior Manager, then Director, then Vice President, Ethan has decades of experience at top tech companies. This career growth course is developed from his own knowledge and input from his extensive network of fellow coaches and executives.

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

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.