Grow From Mid-Level To Senior Engineer [Part 17] - Meetings

Every tech company needs a ton of meetings in order to function. The tricky thing is that a lot of software engineers are introverts, so they have trouble participating in meetings, especially when they're more junior. This lesson teaches you:

- The differences between junior, mid-level, and senior engineers when it comes to meeting presence
- The difference in types of meetings mid-level engineers participate in vs. those of senior engineers
- How meeting ownership shifts as engineers grow from mid-level to senior
- Tips to run an effective meeting which is an efficient use of time

To dive deeper into how to run a good meeting: ["What are some thoughts on maintaining good meeting hygiene?"](https://www.jointaro.com/question/CModSkZ4LWzw9bdaiakt/what-are-some-thoughts-on-maintaining-good-meeting-hygiene/)

The First Thing You Need To Do Before Figuring Out Your Next Company And Team

Choosing the right company and team for you as a software engineer is one of the most important decisions you'll make, and given the high turnover in the tech industry, is a decision that you will have to make multiple times. This is why having the right mentality here is so crucial, which is what this video covers.

Here are the core points:
- Everyone is different - There is simply no "one size fits all" career path for everyone. FAANG companies are great overall of course, but there are going to *many* people and situations where it doesn't make sense to go there.
- Before thinking about your next move, have an honest conversation with yourself and those close to you about your priorities. *Your goal is to create a stack-ranked lists of your priorities.*
- Prioritization is a much harder exercise than people realize as there's simply so many angles to it. Here the ones mentioned in the video:
  - Compensation
  - Work-life balance
  - Company prestige
  - Supportiveness of team
  - Growth opportunities
  - Stability
  - Maximum outcome (risk tolerance)
  - Remote work
  - Product space
  - Company ethics
  - Technical space
  - Level/title
  - Benefits
  - Location

This clip was taken from the following masterclass: [[Masterclass] How To Choose A Good Company And Team As A Software Engineer](https://www.jointaro.com/lesson/0WEmTNZOMIh8xAdfO3JH/masterclass-how-to-choose-a-good-company-and-team-as-a-software-engineer/)

Related resources:
- ["How do I know when it's time to leave a team/company?"](https://www.jointaro.com/question/2Ahiy6ZtUYWDjkSoG3Zk/how-do-i-know-when-its-time-to-leave-a-teamcompany/) - This is the Q&A that Rahul mentioned in this video.
- ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://www.jointaro.com/question/KWXIrFIR1EIJsvdOdo7u/whats-the-difference-between-big-tech-and-startups-in-terms-of-learning-and-growth/)

This Is How You Get Feedback - Making The Process Smooth

The best way to improve as a software engineer is to get feedback, especially when you're new to a team or company. However, this is much easier said than done - Simply having the mentality of being open to feedback isn't enough.

Here's the core points from the video:

- **Don't just ask "Do you have any feedback for me?"** - The cognitive load for the person you're seeking feedback from is simply too high: They need to mentally comb through everything you're doing and then think through every aspect of it to find feedback to give you. Instead of doing this, they'll often default to the "lazy" response of "Nope, you're doing great!". Lazy inputs result in lazy outputs, and you definitely shouldn't be lazy when asking for feedback.
- **Reduce feedback requests to yes/no questions** - Regularly retrospect on your own and use that to craft more pointed questions when asking for feedback. Let's say you're not happy with how clean your code is, evidenced by a lot of pushback when you submit it for review. Using this, you can ask something like, *"I feel like I could do a better job polishing my code; my PRs get a lot of thrash. Do you think I can improve here?"* If they say "Yes", you can then ask for tactics you can apply to get better here.
- **Core areas for onboarding feedback**
  - Overall velocity and output
  - Code quality
  - How good your questions are

Related resources:

- [Suppress Your Instincts And Treat All Feedback As A Gift](https://www.jointaro.com/lesson/dpTu1KBbXJdnHdrQLxsG/suppress-your-instincts-and-treat-all-feedback-as-a-gift/)
- [How To Get Real Feedback So You Can Actually Improve](https://www.jointaro.com/lesson/srTbalkn0HMwEH7HoOpY/how-to-get-real-feedback-so-you-can-actually-improve/)
- ["How can I find more opportunities to grow when I'm getting very little real feedback?"](https://www.jointaro.com/question/7nrslKZuiFdYeutpeX5k/how-can-i-find-more-opportunities-to-grow-when-im-getting-very-little-real-feedback/)

DSA Crash Course [Part 16] - Intersection Approach

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

> Write a function, *intersection*, that takes in two lists, *a*,\_b\_, as arguments. The function should return a new list containing elements that are in both of the two lists.
>
> You may assume that each input list does not contain duplicate elements.

```
intersection([4,2,1,6], [3,6,9,2,10]) # -> [2,6]
```

```
intersection([2,4,6], [4,2]) # -> [2,4]
```

```
intersection([4,2,1], [1,2,4,6]) # -> [1,2,4]
```

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

Creating A Portfolio That Makes Recruiters Come To You

Building a personal portfolio looks nice and feels good, but it *rarely* helps engineers find jobs. In this video, we cover how you can truly stand out as a software engineer and make the jobs come to you (instead of the other way around).

Here are the core points:
- Building a portfolio website can be a nice exercise, but don't spend too much time on it. *Don't expect to get any inbound recruiter reach outs due to your portfolio site*. There is no real central repository of them that recruiters browse.
- In terms of what recruiters do browse, it's primarily LinkedIn. If you have this portfolio energy, it's much better spent polishing your LinkedIn profile instead.
- At the end of the day, a portfolio website is resume++. This means that your foundation is still your resume: Make sure your resume is *extremely* sharp before you even consider building a portfolio website.
- Alex found a lot of success having his Google Play developer page be a portfolio as it hosted real, verifiable products on it. Since his side projects got millions of installs combined, he's gotten reach outs from top companies like Uber, Square, and Instacart through his Google Play developer email.

Related resources:
- ["What technologies or stacks should I create a project to add in my resume for entry level software jobs?"](https://www.jointaro.com/question/c0DiG5ureLbkZ1mKD9Rf/what-technologies-or-stacks-should-i-create-a-project-to-add-in-my-resume-for-entry-level-software-jobs/)
- ["I want to land a job in a big tech as a SWE - How to do it?"](https://www.jointaro.com/question/MWJfUBnnUr8CKYFCO8bp/i-want-to-land-a-job-in-a-big-tech-as-a-swe-how-to-do-it/)
- ["Can Github stars grab big tech recruiters' attention?"](https://www.jointaro.com/question/XaUn4XuIBMSmrr5fcHIT/can-github-stars-grab-big-tech-recruiters-attention/)

Become An Open Source Master [Part 5] - The Benefits Of Open Source

We'll discuss the reasons why you should get involved in open source and the benefits it can bring, both professionally and personally.

- **Work on code that matters:** Contribute to projects used by others, gaining a sense of achievement and pride.
- **Improve your coding skills:** Receive feedback and learn from experienced developers, improving your coding abilities and knowledge.
- **Build relationships:** Connect with maintainers, contributors, and users, expanding your network and learning opportunities.
- **Enhance your professional portfolio:** Showcase your skills and experience to potential employers through your open source contributions.
- **Grow your personal reputation:** Gain recognition and build valuable connections within the open source community.

Connect with James: 

- GitHub: <https://github.com/jamesgpearce>
- Twitter (X): <https://twitter.com/jamespearce>

I Sucked At This For 25 Years As An Engineer – 8 Tips For Communication

Communication is the skill that separates the best engineers from the mediocre ones. 

**Nothing great is built alone**, so even if you’re the best coder in the world, at some point in your career you will have to work with others. When you get to that point, communication is how you get things done. 

Here are 6 tactical communication tips for engineers (and there are two more in the video!)

**1. Learn how to say no. If your PM or manager comes to you with a request, don't just say no.**

Instead, say "not right now" and explain why you're choosing to do other high-priority work. This approach lets you acknowledge the request or the idea, but you’re able to firmly/politely say no by explaining why you want to stay the course. 

**2. Use tentative language**

Especially for critical feedback, leave room for discussion. One way this manifests is during code review: some of the best engineers at Meta actually ended their feedback with a question mark:

"Crash with negative input" ➡️ "Crash with negative input?" One character makes a big difference!

**3. Make people feel heard**

In 1:1s, I’ll literally say "Let me say that back to you" and repeat back what they said to me. This works magically well.

Even if you disagree, this strategy lets you start from a place of agreement -- the person was heard.

**4. Say thank you**

*Proper* thank yous are about more than sending a one-line message. A proper thank you involved thanking them in your launch post or sending them a thank you when you hit a milestone. That's how you build deep relationships.

**5. Advance the conversation**

This is a personal pet peeve for Rahul. If we're talking about where to get lunch, and I propose Indian food, don't just say "I don't like Indian." You need to propose some alternatives in that response. Also, google the ["no hello"](https://nohello.net/) philosophy.

**6. Know your audience**

Many engineers either provide too much or too little context. Communication is an exercise in empathy. You have to figure out what your audience cares about and deliver value to them.

Related links:
- [Taro's communication guide](https://www.jointaro.com/playlist/hVdLQQzfslaYarLSCmmy/)
- ["When should you offer to help a colleague?"](https://www.jointaro.com/question/u4GMlmLOuaU4Olhh2XAy/when-should-you-offer-to-help-a-colleague/)

Overcoming Imposter Syndrome - You Have So Much More Value Than You Realize

One of the biggest factors holding software engineers back is a simple one: They don't believe in themselves. This is very common in the tech industry where being surrounded by talented peers makes it very easy to end up with a case of imposter syndrome. This video explains why every single person in tech is wrong when they believe they can't add value.

Here are the core points from the video:
- **You can't be alive for 20+ years and not have something to share** - 2 decades is a long time. A lot of people don't believe they can share value when they're early in career, which completely discards all their years prior to their career. It's not like you only started generating value in the world after you embarked on your tech career journey. It is mathematically impossible to have been on planet Earth for so long and not have something cool you can share with others.
- **Believe in yourself** - You are limited by what you think of yourself: If you don't believe that you can offer value, then you won't offer value. The absolute first step to successful networking is recognizing your own potential and feeling empowered to help others.
- **Accessible ways that *anyone* can add value**
  - Interesting experiences
  - Odd talents
  - Learnings from failure
  - Being a friendly face

Related resources:
- ["How can I bridge my confidence gap to put myself out there more and ask for help more aggressively?"](https://www.jointaro.com/question/mLKUkNXpLcCxQMfWopqU/how-can-i-bridge-my-confidence-gap-to-put-myself-out-there-more-and-ask-for-help-more-aggressively/)
- ["I've felt imposter syndrome from seeing super talented peers - How do I deal with this?"](https://www.jointaro.com/question/MPUkGXFDaBixmxfjOg9i/ive-felt-imposter-syndrome-from-seeing-super-talented-peers-how-do-i-deal-with-this/)

Top System Design Interview Mistakes [Part 13] - Identifying Key Issues

In the final segment of the system design series, we focus on the importance of driving the design of your system during interviews. In this video, we cover how to identify key issues. Here's the video's core points:

- Avoid following a rigid structure. For example, don't just jump into a data model or architectural diagram without considering the unique requirements of the system you're designing, such as group messaging dynamics
- Actively ask clarifying questions to understand the requirements better. This helps in identifying and addressing key issues specific to the problem, rather than sticking to a generic approach
- Tailor your approach based on the specifics of the problem. If dealing with a unique system, like a group messaging app, adapt your design to handle unique challenges, such as managing multiple notifications from a single message
- Lead the discussion by probing into requirements and challenges. This ensures that your design addresses the most critical aspects of the problem

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>

Grow From Senior To Staff Engineer [Part 4] - Structuring Your Growth

When going from senior to staff, you need to develop a *ton* of new skills across several difference categories. This lesson teaches you:

- A framework for organizing the improvements you need to make to grow to staff, based off of Meta's engineering performance axes
- The most important axis engineers need to grow in order to get to staff
- A healthy way to understand this course and your overall progression to staff in general

Take Jordan's course here: [\[Course\] Become The Go-To Expert As A Software Engineer](https://www.jointaro.com/course/become-the-go-to-expert-as-a-software-engineer/)

Ace Your Tech Interview As A Software Engineer [Part 9] - Polish Your Resume

Your resume is the most important professional document in your life. However, a lot of software engineers are severely lacking in this department. This lesson teaches you:

- The perspective of the often underappreciated tech recruiter and why they automatically reject the overwhelming majority of resumes, especially if they work for a top company like Big Tech
- How to write a resume that recruiters won't hate and instantly throw in the trash, leveraging that empathetic mentality from before
- The steep, underestimated cost of basic resume mistakes, which are incredibly common among immigrant engineers where English isn't their first language
- Why you should make just 1 focused resume instead of several, especially if you're earlier-in-career
- How recruiters hyper-efficiently read resumes (spoilers: they often don't read the entire thing)

13 minutes isn't nearly enough to fully understand all the mechanics of a good resume, so you should dive deeper here: [\[Masterclass\] How To Write A Stellar Tech Resume That Gets You More Job Opportunities](https://www.jointaro.com/lesson/OnQV2V3J8DYVBBuGbZx6/masterclass-how-to-write-a-stellar-tech-resume-that-gets-you-more-job-opportunities/?playlistId=PJqfgn35DG82NSm3QyfT)

Getting To The Top 1% Of Amazon Engineers - Productivity Tips From A Life Engineered

Steve Huynh, from the popular channel A Life Engineered, talks about the 3 parts of his productivity system. After spending more than 17 years at Amazon and obtaining the coveted Principal Engineer title, Steve spends a lot of time thinking about peak productivity. 

Timestamps:
- 0:00 - Intro to Steve
- 0:40 - Why invest in a system for time management?
- 2:30 - Have a healthy relationship with notifications
- 6:02 - Optimize your schedule
- 9:00 - Optimize for impact (not comfort)
- 11:25 - How Steve organizes his time

Related questions:
- [When to check email to maximize productivity?
](https://www.jointaro.com/question/aBmMAXWqsQ8gYxyAJcpq/when-to-check-email-to-maximize-productivity/)
- [Is typing speed important as an engineer?](https://www.jointaro.com/question/JeBsvDeGQf01ritm98W0/is-typing-speed-important-and-what-speed-is-acceptable-for-a-dev-looking-to-work-at-faang/)
- [How do I estimate my sprint tasks better?](https://www.jointaro.com/question/3R6yRStSzDMmvLRCiMVV/how-do-i-estimate-my-sprint-tasks-better/)

Connect with Steve: 
- [Taro](https://www.jointaro.com/profile/aZJL3ucq9dQnscO09F4JDRkgPo72/)
- [YouTube](https://www.youtube.com/@ALifeEngineered)

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)

PIP In Big Tech -- Amazon, Meta, Google

In this section, we cover the path for employees to enter a PIP for three Big Tech companies — Amazon, Meta, and Google.

At **Amazon**, the poor performance rating is called **Needs Improvement (NI)**. Poor performers are put on a Focus, which is a development plan to get back on track. Think of it like a warning. If the focus does not do well, the employee is put on a Pivot, at which point the options are to leave the company or accept a PIP. Learn more here: <https://www.jointaro.com/topic/amazon/performance-review/>

At **Meta**, the poor performance rating is called **Meets Some (MS)** or **Meets All (MA)** Expectations. If the HRBP (Human Resources Business Partner) is part of your review meeting, a PIP is likely. One unique policy of Meta is something called "up or out." This requires engineers to get promoted every few years until hitting Senior Engineer \[E5\]. Learn more at <https://www.jointaro.com/topic/meta/performance-review/>

At **Google**, the poor performance rating is called **Not Enough Impact (NI)** or **Moderate Impact (MI).** A "Support check-in" indicates poor performance and candidate for a PIP. Google is generally more laid-back when it comes to performance compared to other companies. Learn more here: <https://www.jointaro.com/topic/google/performance-review/>

Being New Is A Superpower

Instead of treating your newness as a liability, view it as a superpower.

- Nobody wants to be mean to the new person, so you have the perfect excuse to request resources aggressively.
- You can observe problems with the codebase, processes, or tools that tenured employees have learned to tolerate.
- You can connect the dots between different teams or ideas that would be harder for people entrenched in their roles.

Approach your onboarding with the urgency that "**You will never have fresh eyes again**."

As the most clueless person, if you revamp a resource (wiki, code, etc) to be easy to understand for yourself, you are making it easy for **everyone** to understand.

Part 0 [RBP] React Best Practices - Course Intro

Florian Walther, from Coding In Flow, shares the common pitfalls and best practices in React development. This course will help developers write cleaner and more robust React code by addressing frequent mistakes. The lesson also highlights additional resources available, including a YouTube channel, newsletter, and a GitHub repository with code examples.

- Florian’s free web development playlist on YouTube: <https://www.youtube.com/playlist?list=PLrnPJCHvNZuDG6BWjUFVxeWyYlve_SVJO>
- Code link: <https://github.com/codinginflow/react-best-practices/branches/stale>

[Masterclass] How To Get Promoted Faster In Tech

Related resources:
- ["How to drive my promotion discussion with my new manager?"](https://www.jointaro.com/question/nbYTuVbu3dqGlPALRGbR/how-to-drive-my-promotion-discussion-with-my-new-manager/)
- ["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/?playlistId=eZOEUatYEe7BBAZByuha)
- [Presentation Slides](https://docs.google.com/presentation/d/1LceOHzKxQ12LCtZvNu9OIXIE18UH_ldvW4gGZQewunA/edit?usp=sharing)

Tech Lead Blueprint 3/17 - Why do TLs exist?

Connect with Lalit on LinkedIn: <https://www.linkedin.com/in/lalitkundu/>

DSA Crash Course [Part 11] - Most Frequent Char Walkthrough

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

Code along and test your work in the following editor workspace: <https://structy.net/problems/most-frequent-char?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/>

Properly Learning From Software Engineers More Senior Than You

True or false: What is built by a very senior engineer is more important than how they built it.

When observing very senior engineers, what should you look for to properly learn from them?

True or false: At the top tech companies, the very senior engineers make 5-10x more than their very junior counterparts because they work 5-10x harder than they do.

Which are good examples of questions you can ask when understanding a very senior engineer's behavior?

True or false: At the top tech companies, you are told less and less what to do as you grow more senior, working on more ambiguous projects while having greater freedom to choose what you work on.

As a junior software engineer, it can be daunting understanding the senior and staff engineers on your team. This video covers the mindset shift to make to start leveling yourself from properly observing them, achieving career growth without these engineers having to formally mentor you.

Here's the core points:
- **Observe more senior teammates' behavior** - Principal engineers will usually have 10x the impact of a junior engineer. They don't get there by working 10x as hard - We all have the same 24 hours in a day. Instead of asking yourself *what* these great engineers are getting done, ask yourself, "*How* do these engineers get stuff done?". Marveling over their much larger impact won't get you anywhere - You start really learning from these engineers when you start breaking down the path they took to achieve that impact.
- Here are more specific axes to observe:
  - **Communication** - How do these engineers share status updates and rally the team around their ideas?
  - **Direction** - How do they prioritize projects and select the best ones?
  - **Quality** - How do these engineers protect the sanctity of launches? What kind of feedback are they leaving in code review? What good habits do they have when they submit code? How do they facilitate system design discussions?

Related resources:
- ["What's the core insight behind quick growth?"](https://www.jointaro.com/question/nJ762p255cGyuth36H6w/whats-the-core-insight-behind-quick-growth/)
- ["How do you get the most out of mentorship?"](https://www.jointaro.com/question/IbuZydz0QzsVVqESVaxQ/how-do-you-get-the-most-out-of-mentorship/)

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.