How To Find A Good Team With Career Growth Opportunities

Not every team will have the scope you need to get to the next level, especially at FAANG and Big Tech. If you're looking to get to senior engineer levels and beyond, here's what to look out for in a team:
- **Past launches** - If the team has frequent, meaningful launches from the past year, it's likely this will continue.
- **Healthy balance of levels** - You want folks more senior than you to learn from and folks more junior than you for you to mentor and work through.
- **Strong engineering manager track record** - In particular, see who they have been able to get promoted. If there are examples of senior and staff engineers grown organically within the team, that's another good sign.

This clip was taken from our team selection masterclass. You can watch it here: [[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:
- ["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/) - Question from a Google L4 engineer
- ["How do I find a good team that sets me up for the mid-level -> senior level promotion?"](https://www.jointaro.com/question/oHJWlzm1qdHUZx66moaT/how-do-i-find-a-good-team-that-sets-me-up-for-the-mid-level-greater-senior-level-promotion/) - Question from an Amazon SDE 2
- ["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/)

Asking Great Questions [Part 4] - Make Questions Your Superpower

Many engineers see asking questions as a sign of weakness, which is why they don't do it. What these engineers don't realize is that if you do it properly, asking questions can actually become your *strength*. This lesson teaches you:

- The different levels of skill when it comes to asking questions
- The *massive* career benefits you can get when your question asking skills are truly top-notch, particularly around mentorship
- How expertly crafted questions build up your trust and reputation

To learn more about how to attract the best tech mentors: ["How does one attract a sponsor who is invested in their growth?"](https://www.jointaro.com/question/pRX7I8QC5YPOEDNX5q87/how-does-one-attract-a-sponsor-who-is-invested-in-their-growth/)

Level Up Your Code Quality As A Software Engineer [Part 12] - Break It Down

Software is scary, especially when you get big projects that require thousands of lines of code to implement. This lesson will teach you:

- The steps to turn any tough technical problem into something that's quite manageable (and even easy)
- Why decomposition is one of the important skills for a software engineer to have at all levels
- A framework to plan out your commits and create a crystal clear roadmap for your code
- How to decompose coding projects in a systematic way, demonstrated through an in-depth example covering a classic software flow: User login

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

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

The Rare Insight Top Tech Companies Have About Engineering Managers

Most engineering managers [EMs] are bad and aren't much more than glorified, overpaid whip-crackers. Here's what the world's best tech companies realize about engineering management that other companies don't.

Here are the core points:
- **Good EMs think long-term** - It's really easy to burn out the team for short-term gains, just working them harder and harder so everything ships quickly. However, this isn't hard to do and sacrifices the future of the team. Teams run this way eventually reach a state of weak productivity due to high turnover and completely drained engineers. Good EMs strive to operate their teams in a sustainable way, taking care of their engineers while also pushing for velocity.
- **Good tech companies hold EMs accountable** - In particular, EMs are expected to uphold the overall health and integrity of their teams. Companies like Meta explicitly score managers on how well they are able to give their engineers growth opportunities, preserve their work-life balance, and shield them from thrash so they have the focus to execute.

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/) - The full video where this clip was taken from
- [How Do Effective Engineering Leaders Help Their Teams Achieve More?](https://www.jointaro.com/lesson/xGJDCG7VL4hcZaq5XL92/how-do-effective-engineering-leaders-help-their-teams-achieve-more/)
- ["How do I figure out whether I should stay as an IC engineer or explore management as an EM?"](https://www.jointaro.com/question/Y6qIop9wpOlCYUL0nGs0/how-do-i-figure-out-whether-i-should-stay-as-an-ic-engineer-or-explore-management-as-an-em/)
- ["What are the commonalities and differences between tech leads and engineering managers?"](https://www.jointaro.com/question/c3MLGlkQgOQ6OUHANAxT/what-are-the-commonalities-and-differences-between-tech-leads-and-engineering-managers/)

Master The Behavioral Interview [Part 6] - STAR

Behavioral interviews are ultimately an exercise in story-telling, something that many software engineers unfortunately struggle with. This lesson teaches you:

- The STAR format, how it works, and why it's important
- What to include with S(ituation)
- What to include with T(ask)
- What to include with A(ction)
- What to include with R(esult)
- What a stellar behavioral interview answer following the STAR format looks like

Avoid These Junior Engineer Mistakes With Code Review

In this video segment, we reflect on common mistakes and best practices around code submissions, especially relevant to early-career engineers. The discussion centers around how to be thoughtful and intentional in code reviews to earn trust and increase velocity over time.

- **We don’t treat code review as a speed game.** Moving fast at the cost of quality—like deferring fixes or separating tests from the initial diff—often backfires. We strive to bundle fully thought-out changes with tests as one atomic, reviewable unit.
- **We use RFC diffs to gather early feedback.** When we're unsure of direction, we create “Request for Comment” diffs clearly labeled as such. This helps reviewers give high-level input without getting stuck on minor details.
- **We always show proof of testing, even for small changes.** Even if our change is minimal (e.g., a refactor or doc update), we still confirm it compiles and passes existing tests to signal due diligence.
- **We think like reviewers.** Providing context, test signals, and clarity up front not only earns trust but speeds up the feedback loop and helps us land code more efficiently.

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

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

Your Onboarding Buddy

An onboarding buddy is someone who can help you adjust to cultural norms and direct your questions as a "catch-all." In addition to answering basic technical questions around workflow or code, the onboarding buddy is effectively lending their social capital to you to get you started. They are the safety net when you don't know who else to turn to. 

Rahul recommends that the onboarding buddy and manager be two different people. Your manager relationship contains a power dynamic in that you're interacting your boss, so you may not be fully vulnerable with them. The onboarding buddy is closer to a peer, which means you can get the help you need.

One of the most important roles for the onboarding buddy is to help you **figure out your support channels.**

Master The Behavioral Interview [Part 7] - The #1 Behavioral Interview Question

In life, many things follow a power law where a specific group of things are far more important than all the others. This applies to behavioral interviews as well. This lesson teaches you:

- The most important behavioral interview question you absolutely must know and the many forms it can take on
- How to answer it properly, especially if the true meaning is hidden
- What a great project to talk about during a behavioral interview looks like

Go through the "Project Credit And Scope" section of the [promotion course here](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/): <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/its-not-just-about-impact/>

Grow From Mid-Level To Senior Engineer [Part 6] - The Goggles

Here's the harsh truth: The *vast* majority of mid-level engineers who are stuck at that level and unable to reach senior are holding themselves back (at least to some extent). This lesson teaches you:

- The classic unhealthy mindset that mid-level engineers have that keeps them from ever reaching senior
- How to correct the novice mid-level engineer mindset and evolve towards a senior engineer one by putting on **The Goggles**
- How to think about The Goggles after you are aware of them (which you will be after going through this lesson)
- The general way high-performing senior engineers (and beyond) view the world

Learn how to create scope with our playlist: [\[Taro Top 10\] How To Create Scope As An Engineer](https://www.jointaro.com/playlist/EWIo3USNcsgXbCs5PS0h/)

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

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

Ace Your Tech Interview As A Software Engineer [Part 5] - Dynamic State vs. Prepared State

The overwhelming majority of software engineers went to college and grew up in a very academically-inclined environment. Bringing the mentality cultivated from that experience to the job search often unfortunately has bad consequences. This lesson teaches you:

- Why traditional learning methods don't translate well to software engineering
- The difference between *prepared state* (how you grew up learning) and *dynamic state* (how you should actually learn)
- A defining trait of the most successful interviewers, which most candidates don't have
- How to train yourself properly when it comes to your interview preparation and overall learning

Effective Communication Guide [Part 3.1] - The Power Of Thanks

- Alex's story:
  - At Meta, there was a tool called "Thanks Bot" where you could publicly thank a coworker, and it would alert them, their manager, and your manager.
  - Given that this tool was more "heavy", people at Meta tended to use it for thanking fairly large efforts.
  - Alex had a great coworker back at Portal who would use it to thank people whenever they just spent 5-10 minutes helping him with something. This took people by surprise as they weren't expecting such a thanks for something relatively minor.
- Thank people for small and medium sized good deeds, whether they helped you or just did some really good work. Thanks is cheap - You always come out hugely "on top" in interactions where you give thanks: Giving thanks takes a few minutes tops and receiving helping often requires 10+ minutes of the other person's time.
- If someone really went out of their to way to do something great, reach out to their manager and thank them there as well. This really deepens your thanks, and it helps them receive proper credit, which could even be reflected in performance review.

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)

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

Top System Design Interview Mistakes [Part 11] - Don't Assume the Happy Path

In this segment, we focus on a common issue often seen with more junior engineers - Only considering the happy path when designing systems. Here’s the core points from the video:

- As engineers, our goal is to design systems that work reliably even when things go wrong. A system that fails 1% of the time is often unacceptable

- We need to anticipate and design for potential issues, not just ideal scenarios

- Proactively identifying weaknesses and planning solutions demonstrates strong engineering skills and foresight

- Documenting our design and potential problems as we go helps manage complexity and ensures we address edge cases effectively

- We go through a detailed example of all this with a ride-sharing system design 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>

Top System Design Interview Mistakes [Part 14] - Don't Save the Hardest for Last

In this lesson, we focus on the importance of addressing the most challenging aspects of a system design problem early on:

- We often make the mistake of delaying the hardest parts of the problem. While starting with simpler tasks might seem productive, it can lead to incorrect design choices and suggest we're unaware of the core challenges

- We should immediately focus on the most complex parts of the problem. Tackling these challenges first demonstrates our understanding and prevents us from getting sidetracked by less critical aspects

- In our interview example, we show how the candidate misses the core problem behind the messaging app, tackling the simpler pieces instead

- Effective problem solving involves working through strategies for the hardest issues, like the message-to-notification fan-out, and evaluating their pros and cons

- By focusing on the toughest problem first, we show strong judgment and prioritization skills. This approach ensures that we manage our time well and address the most critical aspects of the design effectively

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>

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.