[Timeless Career Advice] Compounding Engineers vs Detractors

Become An Engineer Influencer [Part 2] - Michael's Backstory

Michael saw the transformative power of influence after he left his job at Netflix. This video reveals the new opportunities enabled by cultivating an audience. Michael talks about which platforms he grew on, among Medium, LinkedIn, Twitter, a newsletter, and more.

Connect with Michael:

- LinkedIn: <https://www.linkedin.com/in/michael-lin-tech/>
- Twitter: [https://x.com/\_michaellin](https://x.com/%5C_michaellin)
- Newsletter: <https://www.michaellinwrites.com/>

Write A Stellar Resume As A Software Engineer [Part 19] - When You Don't Have Enough

A 1-page resume is the golden standard, and engineers usually mess up by going above that 1 page. However, what happens if you're incredibly junior and you're the opposite, having less than 1 page? This lesson teaches you:

- How to stretch your Education section on your resume
- What to do with your resume's project section when you're just a student
- Other simple tricks to make your resume longer and fill up that 1 page

Paper Reading: MyRocks: LSM-Tree Database Storage Engine Serving Facebook's Social Graph

Session led by [Dharin Shah](https://www.linkedin.com/in/dharinshah/)

**Event description**

Facebook uses MySQL to manage tens of petabytes of data in its main database named the User Database (UDB). UDB serves social activities such as likes, comments, and shares. In the past, Facebook used InnoDB, a B+Tree based storage engine as the backend. The challenge was to find an index structure using less space and write amplification.

LSM-tree has the potential to greatly improve these two bottlenecks. RocksDB, an LSM tree-based key/value store was already widely used in variety of applications but had a very low-level key-value interface. To overcome these limitations, MyRocks, a new MySQL storage engine, was built on top of RocksDB by adding relational capabilities. With MyRocks, using the RocksDB API, significant efficiency gains were achieved while still benefiting from all the MySQL features and tools. The transition was mostly transparent to client applications.

The paper was published at the **International Conference on Very Large Databases (VLDB)**: [**https://research.facebook.com/publications/myrocks-lsm-tree-database-storage-engine-serving-facebooks-social-graph/**](https://research.facebook.com/publications/myrocks-lsm-tree-database-storage-engine-serving-facebooks-social-graph/).

Paper authors:

- [**Yoshinori Matsunobu**](https://www.linkedin.com/in/yoshinorimatsunobu/)
- [**Siying Dong**](https://www.linkedin.com/in/siyingdong/)
- Herman Lee

Negotiation Course: Reneging An Offer

Backing out after accepting an offer (*"reneging on the offer"*) is unfortunate but happens more frequently than you think. Imagine that you accepted a job offer, but two weeks later, you finally get an offer from another company that is better in every way. What do you do?

First, prevention is the best cure: try to get all the offers around the same time.

If the timing mismatch is unavoidable, you should do what’s best for you: don’t worry too much about the company.

In the US, employment is at-will, so there’s nothing legally preventing you from joining. Of course, you may have to give back any kind of signing bonus.

There may be reputational damage: talk about why the opportunity is incredibly unique and you hope to work with them again. Reneging on a large company is not as big a deal compared to a startup.

Negotiation Course: Negotiating Your Current Salary

Negotiating your current comp is harder. You can no longer sell on potential, you have to show the outcome of what you have achieved. There are generally also fewer levers to adjust, usually just salary and equity refresh grants.

A few tips: 

- Time when you ask to coincide when your company normally does pay evaluations and merit increases
- Share market data or another offer

If you ask for money and reference another job, be careful about the impact it may have on your manager relationship, who may give you less scope or responsibility.

Negotiation Course: Prefer Async Communication

Recruiters have much more information and practice with negotiation relative to job candidates. The pressure of a phone call and our desire to please others means that phone calls become dangerous places where engineers shoot themselves in the foot. Too many tech employees keep speaking on the phone call and end up revealing too much.

- Recruiters have orders of magnitude more knowledge about the job, the range of possible offers from the company, and even the range of possible offers are peer companies. 
- On the other hand, most job candidates have a handful of data points around their compensation could be, based on their past jobs and what their friends have told them.

This information asymmetry clearly favors the recruiter, who can read your emotions and take advantage of the knowledge gap to lowball you.

For that reason, you should prefer to eliminate phone calls or keep them short, and then be deliberate about your emails where you can craft the exact message you want to send. Async communication is also better for clarity and you can research on your own.

Negotiation Course: The Importance Of Equity In Negotiation

Most companies have larger allowable bands in the equity component of their compensation. For this reason, you should treat it with additional importance as a way to best meet your compensation target. 

There are 2 reasons why companies are more willing to increase equity (RSUs or stock options) compared to other parts of the offer: 

1. Equity doesn’t hurt the profit and loss (P&L) statement of the company. This is especially important for startups.
2. Equity has inherent incentive alignment between the company and the employee. The employee will be more motivated to grow the company because the equity is worth more when the company succeeds.

In addition, equity is generally less understood by employees. Rahul's friend at Uber shared stories of people who rejected an equity grant and simply asked for an additional salary (when they could have gotten significantly more in equity). The risk tolerance for receiving stock compensation is less understood outside the US, e.g. in European countries.

For many people in tech, their base salary is enough to cover their day-to-day living expenses. In a major metro area, an engineer's base salary in a Big Tech co can range from $100K - $300K. This can cover things like rent, food, travel, and even some savings.

If you are in this scenario, Rahul's advice is to be **very aggressive** about increasing the equity component of the comp package. You should tell the recruiter that you want to "*take part in the success that you'll help to create at the company*" and therefore want to be at the highest possible range for equity. 

We'll share more about sample phrases you can use later in the course.

Negotiation Course: When Should You Negotiate? And When Should You Not?

Negotiation makes the most sense for "high-leverage jobs" like software engineering or most other jobs in tech. An example of a low-leverage job would be to stock shelves in a grocery store or drive a taxi in NYC. The difference between the best and average worker in those fields is not that large. But in engineering, the difference in output for the best vs the average can easily be 10x or 100x.

Within the high-leverage category, there are jobs that have many comparable data points (e.g., junior or mid-level engineer) and those that are bespoke because they're rare/senior at the company, e.g., executive level or senior engineering leads.

Negotiation makes less sense for jobs that are purely stepping stones, or those that are time-bound. The classic example here is for internships. A good litmus test is if you know anyone who has ever negotiated that offer, e.g. no one at Stanford ever negotiated the summer research pay.

Finally, negotiation does not make sense if you already accepted the offer at a lower number.

Nail Your Promotion As A Software Engineer [Part 30] - Be Patient

It can be frustrating waiting so long to get promoted as a software engineer. You've been working so hard for so long, and you still don't have that fancier title. This lesson teaches you:

- Why getting promoted is so hard
- The right mentality to always have as you're going through the promotion process
- A clear framework you can use to determine if you are truly getting better as an engineer

Nail Your Promotion As A Software Engineer [Part 9] - You Need More Senior Teammates

As a software engineer, it can be confusing on what's actually needed to get to the next level. Having more senior teammates helps tremendously with that. This lesson teaches you:

- Why more senior teammates are important
- What the ideal senior teammate looks like
- Healthy vs. unhealthy teams for promotion when it comes to seniority

After you find a more senior engineer to mentor you, follow the advice here: ["How do you get the most out of mentorship?"](https://www.jointaro.com/question/IbuZydz0QzsVVqESVaxQ/how-do-you-get-the-most-out-of-mentorship/)

Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases

Session led by [Dharin Shah](https://www.linkedin.com/in/dharinshah/)

In this session, we delve into the intricacies of Amazon Aurora, a high throughput, cloud-native relational database designed to meet the demanding scalability and performance requirements of modern applications without compromising on the simplicity of access via SQL. The paper presents a thorough examination of the design considerations that underpin Aurora's architecture, understanding how it achieves unparalleled levels of efficiency and reliability within the cloud. We will explore key concepts such as Aurora's distributed and decentralized approach, fault tolerance mechanisms, and the optimization of data storage and retrieval processes.

Taro Book Club: Designing Data Intensive Applications - Chapter 4 (Encoding And Evolution)

Session Led by: [Lax Meiyappan](https://www.linkedin.com/in/lakshmanan-meiyappan/)

Topic: Chapter 4 - Encoding And Evolution

In this #taro-bookclub discussion, we'll be talking about Chapter 4 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 4.
- There will also be time for any questions and answers you might have.

Please send your questions ahead of time to [**Lax Meiyappan**](https://www.linkedin.com/in/lakshmanan-meiyappan/) in the [**Taro Premium**](https://www.jointaro.com/membership/) Slack, so that they can be included in the discussion.

Get ready for another engaging and informative 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 27] - Hiring Manager Round (Separate)

Congratulations, you went through the onsite loop and did well! But what's this - The engineering director behind the job you're interviewing for wants to talk? This lesson teaches you:

- When separate hiring manager rounds happen (and why that's a good thing)
- How to pass hiring manager rounds and what to expect from them

Paper Reading - Attention is All You Need

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

"Attention is All You Need" is a seminal research paper published by researchers at Google in 2017, introducing the Transformer model. The paper revolutionized natural language processing and machine translation by proposing a new architecture that relies solely on self-attention mechanisms, eliminating the need for recurrent or convolutional layers.

This paper and the Transformer model it introduced are crucial in the context of Large Language Models (LLMs) for several reasons:

- Parallelization
- Long-Range Dependencies
- Efficient Attention
- Mechanism Pre-training and Transfer Learning

We will be discussing the internals of the Transformer architecture which will help guide our journey into the LLM space.

Paper link - <https://arxiv.org/abs/1706.03762?ref=blog.oxen.ai>\
Event link - <https://www.jointaro.com/event/paper-reading-attention-is-all-you-need/>

Paper Reading - Gemini: A Family of Highly Capable Multimodal Models

Paper Discussion led by: [Akshika Wijesundara PhD](https://www.linkedin.com/in/akshika/)

Abstract: Google researchers recently unveiled Gemini, a ground breaking family of multimodal AI models capable of understanding and reasoning across images, audio, video, and text. The largest Gemini model, Ultra, achieved human-expert performance on several benchmarks and advanced the state of the art across a range of multimodal tasks.

In this paper reading, we will discuss key details from Google's paper introducing Gemini models. Topics will include:

- The Gemini model architectures and how they achieve cross-modal understanding
- Performance benchmarks and state-of-the-art results across text, image, audio, and video tasks
- Applications and use cases enabled by Gemini's multimodal reasoning
- Approaches to responsible deployment of large language models like Gemini

This paper provides a comprehensive overview of the exciting new capabilities of Google's Gemini project. Whether you're an AI researcher, engineer, or simply curious about the state of the art in multimodal AI, join us for an in-depth look at this new model family.\
\
Paper link: [**https://arxiv.org/abs/2312.11805**](https://arxiv.org/abs/2312.11805)\
Event link:  **[https://www.jointaro.com/event/paper-reading-gemini-a-family-of-highly-capable-multimodal-models/](https://www.jointaro.com/event/paper-reading-gemini-a-family-of-highly-capable-multimodal-models/)**

Handling a PIP: The Ultimate Guide To Navigating A PIP

There are two options after a PIP: either the employee will remove all the doubts about the performance concern, or the employee will be terminated.

Your job as an employee is to judge your manager’s intentions. Your manager is the most important person in the PIP, and more generally, in your career. Many managers view the PIP as a formality before termination, and they’ve already given up on you. In that case, **you need to leave.** You don’t win any bonus points by "proving them wrong."

If the manager is responsive to your questions, provides constant feedback, and has a reasonable PIP plan, you may have a chance to succeed.

However, in the vast majority of cases, our recommendation is that you **must start looking for a** **new job.**

The biggest reason a PIP is not worth fighting is because **you want to work for people who believe in you**. This is critical for career success: you need someone who is unfailingly supportive of you, whether that's a friend, mentor, or manager. A PIP does not feel like support. In fact, it feels like the opposite. Your manager felt your performance was weak enough that they literally spent hours documenting how you fell behind, and then informed you in a legal manner.

The joke is that PIP should stand for “Paid Interview Period”, and that is honestly our recommendation for many tech workers who receive a PIP.

Here is the **PIP Evaluation Framework** in order to make the best decision once you’ve received the PIP. If 1+ of the following are true, you should **not** plan to have a long-term future at your current company.

- Your manager is uncommunicative or closed off
- The time horizon for the assigned work on the PIP is unrealistic (e.g. 1 week for a launch)
- The goalposts for the projects keep shifting
- The PIP work and your “normal duties” result in an unmanageable workload
- Your team is unsupportive

Are you a PIP risk? The Ultimate Guide To Navigating A PIP

The most obvious way to identify if you’re at risk for a PIP is if you’ve received poor ratings in prior performance review cycles. But this is a **lagging indicator**, so it may be too late to do anything at this point. Ideally, we’d like a **leading indicator** so you can take steps to avoid a PIP by discovering the warning signs early enough. 

The best leading indicators are: 

- Check-in with your peers and managers and get feedback
- Compare markers of progress: code output, design docs, and updates on tickets of projects. 

On the topics of ratings, you should understand the breakdown of what percent of employees get each rating. Companies may not reveal this info directly, so you can ask your manager or look up internal documentation.

If your manager and teammates start ignoring you or removing your scope, that’s an unhealthy sign.

Why Companies Do PIPs: The Ultimate Guide To Navigating A PIP

A PIP can seem cruel, but there’s a clear reason that companies use them year after year. Let’s start with the top priority for a manager: ensure the optimal performance of the team. For a manager, getting their reports promoted or singing their praises is important, but only insofar as it’s in service of the optimal performance of the team.

Another detail to realize is that the high performers on any team do an outsized amount of work. This is especially true in jobs that have tremendous leverage for the most skilled workers, such as software engineering (thus the famed “10x engineer”). When a company is large enough, a “bell curve” of performance will emerge. A PIP is focused on the employees who are deemed as low performers, typically the bottom 10% of the bell curve.

So, returning back to the original question: the reason why companies do PIPs is to **ensure optimal productivity and impact** for the overall employee base. If high performers sense that poor performance is not being addressed, they may leave the team. So a PIP is a way to push poor performers off the team.

The company also wants to push people out in a way that **minimizes the chance of a lawsuit**. Even though employment in the US is at-will, there’s still a chance of getting sued if the employee argues that they were fired for an illegal reason (e.g. due to a protected characteristic).

The company or manager may claim that the PIP is designed to help you, but that’s almost never the case. They’re more concerned about minimizing the negative impact on the broader team.

Finally, PIPs are often “weaponized” to fire people under the guise of performance when the company doesn’t want to call it a layoff. This is especially relevant now in the current economy as companies may enter an age of austerity.

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.