Get Maximum Value Per Answer

You should "Learn how to fish" instead of "receiving fish" — your goal in onboarding is to become a self-sufficient, productive engineer as quickly as possible. 

The way you do that is to ask follow-up questions when you get help and understand how you would have arrived at the solution on your own.

Bias toward asking for help earlier when you're new to a company, since you don't know what you don't know. It's better to be more annoying for the first month on the job rather than somewhat annoying for 6 months.

Ask Questions Well

What makes a high-quality question?

- You get the help you need
- You build trust with the person/group that you're asking the question to

Question asking is a deep skill that requires you to add sufficient context (but not too much) so people can easily help you.

- Prefer to ask in public forums
- Realize that your question may help others beyond you
- Your questions are a valuable signal to the team 

When you are asking a question, please don't just say hello and wait for them to respond: <https://nohello.net/en/>

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.**

The Common Misconception With Help

When you're new, there's an overwhelming amount of information to absorb. You should plan to ask many, many questions, which means it's important to have the right framing of that interaction.

Obligatory Confucious quote:

> The man who asks a question is a fool for a minute, the man who does not ask is a fool for life

Myth #1:

- **Myth**: Asking for help is a sign of weakness ❌
- **Reality**: You’re expected to ask questions to gain knowledge and foster interaction ✅

Myth #2: 

- **Myth**: Everyone knows so much more than me, I’ll waste their time ❌
- **Reality**: Each person’s knowledge is incomplete ✅

Instead of thinking that building expertise in something is difficult or impossible, realize that **you can become more knowledgeable than anyone** as long as you narrow the scope appropriately. (e.g. "In one afternoon, I can go understand more about the flags to configure **git log** compared to anyone on my team of 10 people.")

Have The "Meta Conversation"

A "meta conversation" is a **conversation about conversation**. It's a conversation you should have with coworkers to discuss **how** you should communicate.

- How often do you want to meet?
- How often do you want feedback?
- What is your preference for written vs verbal updates, and the format?

You will be working with your manager and team for 100s of hours over the course of a year, so it's worth spending some time at the beginning of the relationship to understand how you can best work together.

Create An Onboarding Doc

The **onboarding doc** is a reference guide as you join the company. This document is literally designed for you, outlining your role + team, people to meet, and how you can get started. Generally, your manager will provide an onboarding doc for you, but you should feel free to augment or create your own if the doc is lacking. This is a great place to collaborate and deepen your relationship with your manager -- point out further areas of discussion.

Components of a good onboarding doc:

1. Team charter (translated down from the company mission)

2. Partner teams + people

3. Expectations + milestones 

   1. These should be clearly defined so it'll be clear if you achieved the expectation or not

4. Project ideas with t-shirt sizing

5. Engineering rubric or career matrix for your role, if one exists

Reference question: [What should be part of an onboarding doc?](https://www.jointaro.com/question/FL7XdfLsG9Da6YyfbjZ3/what-should-be-part-of-an-onboarding-doc/)

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.

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.

Why Most Companies Suck At Onboarding

You should not expect a good onboarding process at your company. Helping new employees ramp up is a good example of something that is *important but not urgent*. Tenured employees likely don't remember what it's like to be new.

While many companies will have insufficient or non-existent onboarding, the other end of the spectrum is also unfortunate: larger bureaucratic companies will have excessive onboarding, with months of training before you can do anything productive.

Even if the company has good intentions, building a solid onboarding plan is a hard problem: the tech industry's rate of change is very high, with people, tools, and technologies changing every year. Naturally, documentation and processes around onboarding become outdated.

Despite the difficulties, poor onboarding can be seen as an opportunity for new employees to have an immediate impact.

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.

How This Onboarding Course Works

Onboarding into a new job is (hopefully) the start of a rewarding and impactful career change. "*Welcome to the rest of your life*" is apt when you're the new employee: you are setting the stage for the rest of your job. Make it count!

This course will guide you through the onboarding process as a software engineer. Rahul will share his experiences and knowledge to help you establish relationships, navigate change, and prevent common failure modes. By the end, you'll have a clear understanding of how to build respect, measure progress, and succeed in your new role

Why Rahul is qualified to teach this course: 

- Across full-time and internships, Rahul has worked at 7 different companies with wildly different onboarding processes
- Rahul has directly coached and mentored hundreds of engineers as they started in new roles
- Rahul has seen what works (and what doesn't) when engineers apply the advice on the job

When engineers fail to productively ramp up in a company, it's often because they are one extreme of the spectrum of panicked to complacent: 

- **Panicked engineers** lack focus, try to do/read everything, and are very stressed out. 
- **Complacent engineers** are too reactive, lack curiosity, and are not stressed enough.

If you're looking for a job, start with this course: [Ace Your Tech Interview And Get A Job As A Software Engineer.](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

Paper Reading: Self-supervised Vision Transformers (Foundational Model)

Session led by [Mandar Deshpande](https://www.linkedin.com/in/mandardeshpande1995/)

Dino is a self-supervised learning approach for computer vision tasks. It leverages vision transformers without using any labeled data. Dino v2 introduces several improvements over its predecessor, enhancing performance and scalability. It achieves state-of-the-art results on various benchmarks. Notably, Dino v2 demonstrates strong performance on downstream tasks such as image classification and object detection.

We will be walking through

- Basics of computer vision
- Self supervised learning
- ViT (vision transformers)
- DINO
- DINO v2 model

Paper link - [**https://arxiv.org/abs/2304.07193**](https://arxiv.org/abs/2304.07193)

[Event link](https://www.jointaro.com/event/paper-reading-dino-v2-ie-foundational-model-for-computer-vision/)

[Distributed Systems Deep Dive] Wide-column NoSQL DB / Cassandra

If you're interested in how to design a wide-column NoSQL database, this session is for you. We'll start with the basics: what Cassandra is and why it's a popular choice for handling massive amounts of data. Expect a clear explanation of its architecture and how it spreads data across multiple servers. We'll cover how Cassandra keeps your data in sync and the trade-offs you might face.

- **Cassandra Basics:** Learn what Cassandra is made for and when it's better than other database options.

- **Architecture Overview:** Understand Cassandra's setup and how it's built for horizontal scaling.

- **Data Duplication:** Find out how Cassandra copies data to protect against outages.

- **Consistency Levels:** See how you can control consistency in Cassandra to fit your use case.

- **Writes and Reads:** Get into the details of how Cassandra handles your data when you're adding or retrieving it.

- **Node Communication:** Discover how Cassandra's nodes talk to each other to stay up to date.

- **Space Management:** Take a look at how Cassandra keeps disk space in check by getting rid of unnecessary data.

- **Dealing with Deletions:** Understand how Cassandra handles the cleanup of deleted records.

Thanks to [Alex Poon](https://www.linkedin.com/in/thealexpoon/) for leading this session!

For more system design resources:

- [\[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/)
- [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

[Distributed Systems Deep Dive] Design a KV such as Dynamo DB

This is a session on DynamoDB if you're looking to understand how to design a distributed key-value stores. We'll start with what DynamoDB is and why people are using it. Expect a run-through of its architecture and a straightforward explanation of how data gets sliced for efficiency. We'll also cover what happens when things go south and how DynamoDB keeps data consistent and up-to-date as well as the pros and cons.

If you write code and care about making it scale, this will be worth your time.\
\
**Dynamo Basics:** Understand what DynamoDB is built for and when to use it over other databases.

1. **Architecture:** Get to grips with DynamoDB's architecture - how it's built to scale effortlessly and provide consistent performance.

2. **Data Handling:** Learn about partitioning strategies that spread data across nodes effectively and replication techniques that prevent data loss.

3. **Resolving Conflicts:** Master vector clocks for resolving data conflicts in a system designed for eventual consistency.

4. **Operational Workflow:** Gain insight into the lifecycle of 'put' and 'get' operations and how DynamoDB handles data under the hood.

5. **Merkle Trees:** Understand how DynamoDB uses Merkle trees to synchronize data across distributed systems efficiently.

6. **Gossip Protocol:** Learn the workings of the gossip protocol for node communication and how it contributes to DynamoDB's robustness.

Thanks to [Alex Poon](https://www.linkedin.com/in/thealexpoon/) for leading this session!

Taro Book Club: Designing Data Intensive Applications - Chapter 3

Topic: Chapter 3 - Storage and Retrieval

In this #taro-bookclub discussion, we talk about Chapter 3 of [**"Designing Data-Intensive Applications"**](https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321) by Martin Kleppmann.

Here's the agenda:

- Let’s get to know each other with some quick introductions.
- We’ll break down and discuss the key concepts from Chapter 3.
- There will also be time for any questions and answers you might have.

Thanks to [**Suraj Singh**](https://www.linkedin.com/in/suraj-singh-495b192b/) and [**Sangavi Pari**](https://www.linkedin.com/in/sangavi-pari/) for leading this session!

Taro Book Club: Designing Data Intensive Applications - Chapter 2 (Data Models and Query Languages)

Discussion led by: [Ankur Agrawal](https://www.linkedin.com/in/erankuragr/) & [Raj Shah](https://www.linkedin.com/in/therajshah/)

Topic: Chapter 2 - Data Models and Query Languages In this #taro-bookclub discussion, we'll go over Chapter 2 of the book "Designing Data-Intensive Applications" by Martin Kleppmann. This chapter is about Data Models and Query Languages and will provide good mental models to think about Relational vs Document Models, Graph Data Models and various types of Query Languages.

Here's the agenda: We’ll break down and discuss the key concepts from Chapter 2. There will also be time for any questions and answers you might have.

Get ready for our second session on this engaging and informative book! If you don't have a Taro Premium membership, you can get it at a discount with Ankur's special link here: <https://www.jointaro.com/r/eventu507/>

Event Link: <https://www.jointaro.com/event/taro-book-club-designing-data-intensive-applications-chapter-2-data-models-and-query-languages/>

Ace Your Tech Interview As A Software Engineer [Part 38] - Go Deeper, Follow Through

You made it! By completing this course, you have attained the necessary wisdom to avoid the many, many failure modes software engineers so often fall into when searching for a job. This video teaches you:

- Why completing this course is actually just the beginning of your job search success
- The Top 5 overall learnings from this course
- The exact difference between struggling job seekers and successful ones
- How you can follow through with the knowledge gained from this course and actually apply it to your job search

Ace Your Tech Interview As A Software Engineer [Part 37] - Getting The Offer

Congratulations, you got the offer! However, the journey isn't over yet. This video teaches you:

- The exact steps you should follow after getting an offer (it doesn't even have to be a formal offer letter)
- Why offers are often even more valuable than software engineers think, even the more lackluster ones
- How to communicate with other companies you're in the interview loop for after you have gotten any offer (even a verbal one)

To master the art of negotiation, follow the advice here: [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/)

Ace Your Tech Interview As A Software Engineer [Part 36] - Getting Interview Feedback

The best way to get better at software engineer interviews is to fail a bunch of software engineer interviews. But how exactly do we do that? This lesson teaches you: 

- Why you're probably not getting feedback from the company after you have failed their interview
- What you should do instead after an interview to maximize the learning that you get from the experience

Ace Your Tech Interview As A Software Engineer [Part 35] - Temper Your Expectations

You just went through an interview as a software engineer and are eagerly awaiting the result. Is it time to get your hopes up? This lesson teaches you:

- The dangers of having the wrong mentality after an interview
- Why having tempered expectations is crucial for long-term success on the software engineer job hunt
- Why software engineers often overestimate how they performed on an interview, especially with top tech companies like FAANG
- The exact calculation and framework you should follow to set expectations appropriately after you have gone through an interview, particularly an onsite (final round)

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.