Don't Waste Your 1 on 1s. Build The Relationship

Why should you build the relationship in 1 on 1 meetings?

True or false: Small talk is okay in 1 on 1 meetings to break the ice and learn more about the other person's life outside of work.

Why are deep relationships needed in tech, especially at senior levels?

One-on-one meetings are a foundational tool for building trust and social capital within a company. Especially in medium to large organizations, relationships drive execution—and one-on-ones provide a structured, intentional space to cultivate those relationships.

- **Build social capital early**: Scheduling one-on-ones with key teammates—engineers, designers, PMs, and adjacent team managers—early on helps lay the groundwork for future collaboration. This “trust bank” can be drawn on when challenges inevitably arise.
- **Treat relationships as human endeavors**: There's no formula for connection. These conversations are opportunities to build real understanding, not just to exchange project updates.
- **Welcome small talk, especially at first**: In early one-on-ones, light conversation about emotions, hobbies, and general well-being helps establish rapport. This human connection builds the trust needed for deeper collaboration later.
- **Shift toward deeper conversations over time**: Once a working relationship is more established, focus should evolve toward more meaningful topics—emotions, motivations, and work challenges—while still leaving space for the personal.
- **Listen with genuine care**: The most effective relationships are built on authentic interest. It’s not enough to ask personal questions—true connection comes from caring about and following up on what others share.

By using one-on-ones intentionally and empathetically, it's possible to create strong, lasting connections that enhance both individual performance and team effectiveness.

Managing ADHD as an Engineer

Attention-deficit/hyperactivity disorder (ADHD) is marked by an ongoing pattern of inattention and/or hyperactivity-impulsivity that interferes with functioning or development.

Handling ADHD as an engineer is hard. Juggling job demands, with everyday ADHD struggles, can feel overwhelming. But, you're not alone.

This collaboration between Shimmer and Taro explores the intersection of ADHD and Engineering. You'll see a live conversation between a Shimmer ADHD coach and their engineer client. Alex (coach) and Ashley (student) share how ADHD shows up in the engineering field, along with science-backed strategies to overcome common challenges. 

Some of the common presentations of ADHD: 
- Emotional regulation
- Procrastination
- Establishing routines

Ways to find and keep motivation: 
- Find your drive
- Break it down
- Create accountability
- Utilize external motivation

Energy and time management: 
- Know when your energy fluctuates
- Determine the level of cognitive effort for a task
- Use the minimum amount of cognitive effort necessary

Understand the front-end and back-end of procrastination: 
- **Front-end**: conditions must be perfect to get started, lack of direction/motivation, underestimating time needed
- **Back-end**: perfectionism, loss of novelty, fear of feedback, waiting for the final push

Get Shimmer through Taro Perks for a discount: [joinTaro.com/perks](https://www.jointaro.com/perks/)

Ace The ML System Design Interview [Part 3] - Big Picture Design

A strong big-picture system design is crucial for success in machine learning system design interviews. It's not about drawing a perfect diagram immediately, but about demonstrating an understanding of the system's components and their interactions. Here are the core points from this lesson:

- Identify the inputs and outputs of the system during the alignment phase to establish a foundation for building the diagram
- Start with the user and the service, then progressively add components, especially those involving machine learning, to illustrate the flow of data and processes
- Break down machine learning components beyond a single "ML system" box to show the different stages and types of models involved
- Include essential infrastructure elements, such as feature stores, to demonstrate a comprehensive understanding of the system
- Iterate on the diagram, adding or modifying components as a deeper understanding of the problem and its requirements develops

If you like what Ilya has to say, subscribe to his YouTube for more high-quality ML/AI career guidance: [MLEpath - YouTube](https://go.mlepath.com/taro-youtube-mlepath)

If you want hands-on support from Ilya to crack the FAANG ML interview, join his coaching program: [MLEpath - Coaching Program](https://go.mlepath.com/taro-march-25)

DSA Crash Course [Part 25] - Linked List Values Walkthrough

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

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

Performance Bonus Explainer With Meta Senior Software Engineer [E5] Example

This video breaks down how **performance bonuses** work in the tech industry, focusing on their structure, key variables, and real-world examples—especially from companies like Facebook. It underscores how these bonuses are a significant portion of total compensation and are both performance- and timing-sensitive.

- **Performance bonuses are calculated using a base percentage** tied to level and salary, and then adjusted by two multipliers: individual performance and company performance.
- **Company performance multipliers vary**, often based on metrics like revenue or stock performance. For example, Facebook’s company multiplier was 90% in late 2017, despite its historically strong track record.
- **Individual performance multipliers** reflect how well someone met expectations (e.g., "meets all" equates to 100%), and strongly influence the final bonus amount.
- **Bonuses are only paid if still employed at payout time**, meaning even working a full half-year won't earn a payout if the person leaves before the bonus distribution date.
- **Payout examples help contextualize the numbers**: a senior engineer at Facebook with $62K eligible earnings, a 15% target bonus, and multipliers of 1.0 (personal) and 0.9 (company) would receive about $8,300—paid out roughly two months after the performance period ends.

How To Discover Your Work Passions And Hatreds

Which of the following should you do to discover your work passion?

What of these is a legitimate, strong sign that something is a work passion for you?

- *Regularly take time to reflect on how much you enjoy your work, especially when you're earlier-in-career*.
- Write down everything you do. Here are some examples of common things software engineers do:
  - Writing code
  - Reviewing code
  - Meetings
  - Working with JIRA
  - Talking with cross-functional stakeholders
  - Fixing bugs
- Split all the items into 3 buckets:
  - Things you genuinely enjoy: Tasks/behaviors you are excited to do and can lose track of time doing them.
  - Neutral: Things you can do a good amount of, but in the end, you do it for work.
  - Chores: You *only* do it for work, and you actively try to minimize doing these as much as possible.
- From the top bucket (enjoyment bucket), try to craft your work life around that.

Related resources about soul searching and find your own path:
- ["I feel like senior engineers tend to focus on a specific area. How can I pick a specialization that's still relevant in 5-10 years?"](https://www.jointaro.com/question/xFEhcvfbJ2P0pYzZ4r6f/i-feel-like-senior-engineers-tend-to-focus-on-a-specific-area-how-can-i-pick-a-specialization-thats-still-relevant-in-5-10-years/)
- [[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/)

How to Crack System Design Interviews - Part 10: Preparation Resources

This video outlines resources and strategies to prepare for system design interviews. We can improve our performance by:

- **Building a strong vocabulary:** Familiarizing ourselves with key technologies and concepts (e.g., Amazon S3, Apache Kafka) helps us communicate ideas effectively and demonstrate practical understanding.

- **Developing theoretical knowledge:** We can gain a solid theoretical foundation through courses like Interview Ready, which covers high-level and low-level design concepts, design trade-offs, and other essential topics.

- **Gaining practical experience:** Mock interviews provide invaluable practice and build confidence for the real interview. Consider using free platforms or seeking discounts if available.

- **Utilizing online assessment tools:** If time is limited, leverage automated online judges to assess and reinforce understanding of system design components and their placement.

- **Prioritizing human interaction:** While online tools are helpful, prioritize mock interviews with experienced individuals for the most effective preparation and feedback.

A few tools mentioned: 

- Mock Interviews: [joinTaro.com/perks](https://www.jointaro.com/perks/)
- [Automated Design Judge](https://interviewready.io/question-list/system-design-judge/?_aff=JOINTARO)
- [General Resources for SD](https://interviewready.io/resources)

[Gaurav Sen](https://www.linkedin.com/in/gkcs/) has conducted 1000s of system design interviews while working at Uber and building his [YouTube channel](https://www.youtube.com/@gkcs) to 500K+ subscribers. His platform [InterviewReady](https://interviewready.io/?_aff=JOINTARO) combines video explainers, live Zoom classes, and an automated System Design Judge.

What's Often Overrated When Choosing Your Next Job

Here are the attributes we've generally seen software engineers prioritize too much when weighing career opportunities:
- **Product space** - This usually manifests as pursuing a tech trend (like VR or NFTs). Of course, if you're legitimately passionate about the space, go for it, but seriously ask yourself if you would be in this space if it wasn't regularly talked about.
- **Technical space** - Similar to product space, you can follow trends here. Choose a stack that you're legitimately passionate about, which also has the support network you need (very important for junior engineers). The risk with cutting-edge technology is that it often doesn't have a lot of mature teaching resources behind it (it's cutting edge for a reason).
- **Level/title** - Promotion is a decent and concrete career goal earlier on, but don't go to bad companies to maximize your title. At the end of the day, your level and title are just strings next to your name.
- **Compensation** - Money is genuinely important in almost all cases, but what a lot of people don't realize is that very high pay often comes with a catch (usually work-life balance). Try treating this as a lagging indicator - If you're genuinely growing fast as a software engineer, you will eventually
land an opportunity that is top-of-market (as you deserve).

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 should I think about levels when it comes to evaluating jobs and in my career overall?"](https://www.jointaro.com/question/siBFn9WmU204N6D0IRHZ/how-should-i-think-about-levels-when-it-comes-to-evaluating-jobs-and-in-my-career-overall/)
- ["I feel like senior engineers tend to focus on a specific area. How can I pick a specialization that's still relevant in 5-10 years?"](https://www.jointaro.com/question/xFEhcvfbJ2P0pYzZ4r6f/i-feel-like-senior-engineers-tend-to-focus-on-a-specific-area-how-can-i-pick-a-specialization-thats-still-relevant-in-5-10-years/)

This Is Why FAANG Engineers Make So Much Money - Tech Compensation Breakdown

Learn about the 4 components of compensation:

1. Base salary
2. Sign-on bonus
3. Performance bonus
4. Equity

The latter two are less understood, and they are key to understanding why compensation at tier 1 tech companies is so high.

And we also talk about how Mark Zuckerberg actually had a pretty big impact on increasing tech compensation as a whole!

[The Insider's Guide To Negotiating Your Tech Salary And Compensation](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/)

[Become A Go-To Person 7/18] How Expertise Translates To Influence

A course by [Jordan Cutler](https://www.linkedin.com/in/jordancutler1/), Senior Software Engineer at Pinterest and Author of the [High Growth Engineer Newsletter](https://read.highgrowthengineer.com/)

Grow From Mid-Level To Senior Engineer [Part 8] - Fill In The Gaps

Senior engineers solve fundamentally different problems compared to mid-level engineers. This lesson teaches you:

- The expectation for senior engineer mindset and behavior when problems arise in a project they're working on
- The types of problems that mid-level engineers tend to avoid
- The types of problems that senior engineers uniquely solve compared to more junior engineers

Level Up Your Code Quality As A Software Engineer [Part 21] - Non-Descriptive Names

Naming: It's important for your children but quite important for your code as well. When it comes to your variables, methods, and classes, you should put in the effort to name them properly. This lesson will teach you:

- Why descriptive, high-effort names can add up to add a huge amount of quality to a codebase
- How to identify a poor name in code and the common patterns leading to it
- How much time you should spend on each type of name and how to prioritize accordingly, particularly in code review feedback
- The mentality to convert bad names to good names in code with an in-depth example walking through a classic utility method

Maximize Your Productivity As A Software Engineer [Part 16] - Mentor And Delegate

Many software engineers are naturally lone wolves due to their introverted nature. While this can work out as a junior or mid-level engineer, it quickly becomes unsustainable as you reach senior/staff levels and beyond due to the immense workload. This lesson teaches you:

- Why being a lone wolf is terrible for your productivity
- The importance of uplifting others around you when it comes to getting stuff done
- One of the core virtues the best engineers have, which is particularly needed for mentorship

Here's Alex's Meta mentorship case study: [\[Case Study\] Mentoring Junior SWEs \[E3\] to Senior \[E5\] In Just 2.5 Years At Meta](https://www.jointaro.com/lesson/EX9563YnxcJb62cCmetg/case-study-mentoring-junior-swes-e3-to-senior-e5-in-just-25-years-at-meta/?playlistId=oLssVMdTJ9NtX5SX1fek)

Why It Doesn’t Make Sense To Have a 5 Year Career Plan

Most productivity advice is about getting as much done as possible in the short term: *how do you optimize this week or this particular project*? How does productivity and time management fit into longer term career plans? How much time should be spent around planning your career years from now?

The answer is, **not very much**. Too much will change in 5 years to build your life around that: your experiences and attitudes may change, and the world will certainly change. 

Instead of working backward from the perfect job or career in the long term, it’s better to start with your desired lifestyle. 
- Where do you want to live? 
How much money do you need to make? 
- How busy will you be? 

It’s worth reflecting on what your desired lifestyle is, and check-in periodically to evalute if your goals have changed.

However, this is very different from setting goals. **A good goal is SMART: specific, measurable, achievable, relevant, and time-bound**. If you have a goal which is more than a year away, it’s worth breaking it down into something which can be relevant and time-bound.

When you have established a goal of the proper time duration, you should spend 5-10% of the time in planning how you’ll execute on the project. For example, if you’re planning a project which will likely take 100 hours of work, spend 5-10 hours (a few days of work) in doing the planning behind it. 

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

How To Accomplish Something Every Single Day

How do you make every one of your days productive?

True or false: People overestimate what they can do in 1 day while underestimating what they can accomplish in 1 year.

Which of these attributes should your singular daily goal have?

True or false: You should try to keep your goals purely inside your head instead of writing them down. This saves you time and prevents you from overloading yourself with too many notes.

Junior Engineers, Avoid This Fake Growth Trap

What's the main change in expectations when growing into senior engineering levels?

True or false: Hustling (i.e. working extremely hard) is a common, healthy way to get promoted.

Why is it bad if you are able to get promoted to senior levels through sheer ultra-hard work and very high raw productivity?

- A lot of earlier-in-career engineers believe that being a better software engineer is all about coding: If you can write more good code faster, then you are growing.
- This is generally mostly true in the beginning, but then it quickly becomes a toxic way of perceiving growth.
- You will hit walls. There are only so many hours in a day, and you can only type so many lines of code per hour.
- As a senior engineer, you need to focus on multiplicative and deeper behaviors.
- If you are able to have the impact of a senior engineer but are working extremely long hours, you are essentially "faking" the appearance of a senior engineer. This working model is not sustainable, and once you burn out, it's a terrible situation for everyone.

[Become A Go-To Person 5/18] Become The Technical Expert

Clear Communication For SWEs [Part 2] - What Is Clear Communication?

In this video, I delve into the essence of clear communication in software engineering, emphasizing its critical role in project success. I discuss the definition of clear communication, common barriers, and strategies to overcome them. Effective communication ensures team alignment, enhances productivity, and reduces errors. Viewers are encouraged to adapt their communication style for diverse audiences and regularly summarize key points for clarity.

Connect with me on LinkedIn: <https://www.linkedin.com/in/ryan-wiens/>

Master The Behavioral Interview [Part 9] - The Interviewer Isn’t You

One of the biggest mistakes software engineers make during behavioral interviews is not having empathy. This lesson teaches you:

- A crucial way to understand the goal of a behavioral interview
- How a lack of empathy leads to immediate tactical failure in behavioral interviews
- How you can use empathy to take in a non-confusing way

System Design Series: Taro Playlists [Part 9] - Thinking Into The Future

You can find the full [system design doc here](https://docs.google.com/document/d/15WaM8Ojan82g0m2mtz6kC2Hiyj0Q6VbjfqRmVNDI3qw/edit?usp=sharing) - Feel free to use it as a template for when you are doing a system design at your job!

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

- Products are rarely shipped in isolation: You will almost always iterate on them in the future, extending them and adding new features.
- You should always take some time to think into the future for your project. The amount of time you take will vary a lot based on situation, but it generally plays out like this across company types:
  - **Smaller companies and startups**: Spend less time as goal is to ship, and it's unclear if the company will survive to even iterate.
  - **Big Tech/FAANG**: Spend a lot of time as these companies need to think long-term to maintain their massive market presence.
- When coming up with future iterations during your system design, order them by likelihood of doing and level of priority.
  - Spend more time thinking through the scenarios at the upper end of the list and incorporate them into your system design if they are very likely to be done in the next couple months.
  - Your goal is avoid a scenario where you need to extend your system shortly after it's launched, but it's so brittle and fragile that you would need to rewrite huge swaths of it to accommodate the new use-cases.
- However, this is a failure mode on the opposite extreme and that is being unreasonably forward thinking and over-engineering your system as a result. Making a protocol more generic and scalable almost always takes more time.
- When building systems or services, seriously think about the assumptions you are making.
  - Will the input this API takes in always be in this format and have certain fields?
  - Will this hard-coded if-statement start blocking valid control flows in the future?

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.