DSA Crash Course [Part 10] - Most Frequent Char Approach

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

> Write a function, *most_frequent_char*, that takes in a string as an argument. The function should return the most frequent character of the string. If there are ties, return the character that appears earlier in the string.
>
> You can assume that the input string is non-empty.

```
most_frequent_char('bookeeper') # -> 'e'
```

```
most_frequent_char('david') # -> 'd'
```

```
most_frequent_char('abby') # -> 'b'
```

```
most_frequent_char('mississippi') # -> 'i'
```

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

How To Be An Effective Tech Lead [Part 1] - How This Course Works

As a software engineer, you need to eventually grow into a tech lead to pursue more senior levels. However, it's much easier being a bad tech lead instead of a good tech lead - This course is here to help you be the latter. Here are the core parts of the lesson:

- Your instructor [Jocelin Ho](https://www.linkedin.com/in/jocelinho/) walks you through her extensive 10+ year tech background as a Meta tech lead and the CTO/Cofounder of Cooby (Sequoia-backed startup), where she built engineering teams from scratch and mentored other tech leads

- You'll understand if this course is a good fit for you

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

  - 💡 The full definition of an effective tech lead

  - 💻 What technological skills tech leads must possess

  - 🙌 How tech leads demonstrate true leadership

  - ✅ Practical tips to start acting as a tech lead

Why Onboarding Matters

This video discusses the importance of onboarding and how it can significantly impact your reputation and career growth. 

If you imagine a "**Trust Meter**" where 0 means you have no trust and 100 means absolute trust, your default score as the new engineer will be around 50. Existing employees will think you are smart and have good intentions, but you need to work hard to increase the score and unlock larger-scoped projects. This hard work begins in onboarding.

The other reason the initial months in the company are important is because the tech industry is changing increasingly rapidly. When the average tenure at a company is &lt; 2 years, you need to figure out how to fully ramp up in a fraction of that time. Even within the same company, you will likely switch teams multiple times. Re-orgs are so common!

By approaching onboarding with a proactive plan and a sense of urgency, you can set yourself up for success and build strong relationships quickly.

1 on 1s Are The Time To Be Awkward

Why should you be awkward and even a little bit uncomfortable in 1 on 1 meetings?

True or false: 1 on 1 meetings are great for staying in sync, so status updates are one of the best things you can talk about during them.

Which of the following are good things to talk about in 1 on 1 meetings?

The 1 on 1 meeting is one of the most important usages of time in the workplace. Even the most junior engineer will generally have at least a 1 on 1 meeting series with their engineering manager. However, 1 on 1 meetings are often completely wasted by software engineers - Here's how to avoid that.

Here are the core points from the video:
- 1 on 1 meetings are the most inefficient way to communicate anything that is non-controversial
  - The main culprit here is detailed status updates. If you're using the majority of the time to share these and talk tactics, you are doing 1:1s wrong.
- The most effective way to leverage 1:1s is to talk about things that are *awkward and maybe even make you uncomfortable*. Here are some examples of "awkward" topics:
  - Feedback to improve
  - Emotions (both positive and negative)

Related resources:
- [Having The Proper Mentality For Manager 1 on 1s](https://link.jointaro.com/p8ysLGYUj7KhoGND7)
- [Effective Communication Guide](https://link.jointaro.com/kWQkRyRhLqbTWBty7)
- [The Art of the Awkward 1:1](https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c)

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

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

Making The BEST Case For Yourself In Performance Review: The Self Review

- Your self-review is the most important feedback for you come performance review season: Ignore the weirdness you may feel hyping yourself up and take it very seriously.
- The onus for representing yourself well falls mainly on you, not your manager or peers. Nobody knows you better than you. It's your job to make sure that none of your awesome achievements fall through the cracks.
- Start your self-review early and refine it across several iterations with your manager.
- Use [your brag journal](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/brag-journal/) to seed the self-review.
- Show the impact. Attach links to proof as much as you can (e.g. linking a dashboard with positive metrics to show that the project you launched added business value).

Related resources:

- ["How can I most effectively talk about my projects?"](https://www.jointaro.com/question/c0CDYi5VCRXz0gHHLiGP/how-can-i-most-effectively-talk-about-my-projects/)
- ["How to figure out what the most important projects are?"](https://www.jointaro.com/question/CgCPA60bDDHoOteN7Lmb/how-to-figure-out-what-the-most-important-projects-are/)

DSA Crash Course [Part 7] - Big-O Examples Lecture

In this lecture, Alvin shows examples of code with different Big-O complexities.

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

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

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

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

Engineer Your Ideal Tech Career [Part 2] - How Do You Spend Your Time?

In this video, we explore key areas that software engineers spend their time throughout their day, and we talk through the differences between each.

Depending on which areas you want to optimize to spend your most time, your long-term career path can vary. Try to assign a different rating to each to give yourself a clearer picture!

We cover what it really means to:

- Be making product/business decisions
- Be architecting solutions
- Be hiring
- Be mentoring

Looking for mentorship from tech’s top engineers + personalized job hunt assistance and interview prep? [Formation.dev](http://Formation.dev) can provide you unlimited career coaching, technical mentorship, personalized practice, and mock interviews. Join us here: <https://formation.dev/partners/taro>

Worksheet: [Formation - Coding Your Career](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/courses%2Fslides%2FFormation%20Career%20Direction%20Worksheet.pdf?alt=media&token=f6344b78-529a-411e-a449-7a34a8d55fc8)

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

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

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

The Talk & Observe Framework

This framework ([Talk & Observe](https://www.jointaro.com/blog/talk-and-observe-a-framework-for-engineering-onboarding/)) captures the two most important ways you’ll learn as a new engineer.

1. **Talk** with various people on the team to learn what they do and what you need to know.

   1. To add more structure to this conversation, follow the advice from Boz (CTO at Meta): [Career Cold Start Algorithm](https://boz.com/articles/career-cold-start)

   2. Ask people’s priorities and what concerns they have.

2. **Observe** how others operate at the company by studying the artifacts of their work. As engineers, we naturally have tons of markers to our progress.

   1. Look at code commits, comments on code reviews, design docs, calendar blocks, team meeting notes, etc.
   2. Spending 10-15 minutes to observe ("*stalk*") every person on your team will reveal tons of insight. For example, someone may say that project A is the top priority, but all their time is spent on project B -- this mismatch is an opportunity for you as the new person.

Level Up Your Code Quality As A Software Engineer [Part 9] - Focus, Focus, Focus

A lot of software engineers falsely believe that having every tech stack ever on your resume means that you are the perfect interview candidate as you qualify for the most jobs. The reverse is actually true, and championing that strategy leads to massive gains in both your code quality and job prospects. This lesson will teach you:

- The real recipe for being highly paid and easily hired as a software engineer
- Signs that you have become a true technical master in your domain and are now ready to move on to other tech stacks
- How to structure your journey as an earlier-in-career software engineer (5 years of experience or less)
- How to navigate the junior engineer career trap that is "full-stack" engineer
- What hiring managers look for in engineering candidates, especially at Big Tech
- The overall technical mastery trajectory for software engineers and how you can reach the top
- Why focus is so important for your longer-term learning as a software engineer

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

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)

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

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.