How The Top 1% Of Engineers Are Judged

As a former VP of Engineering at Amazon, Ethan has the unique ability to share how the senior-most engineers were evaluated within Big Tech. These are the top few percent of engineers in the company (Staff Engineers, Principal Engineers, Distinguished Engineers, etc), and the expectations are incredibly high.

**Key insights:**

- **At very senior levels, technical excellence is table stakes.** The top-performing engineers use their technical expertise to help the business. 
- **The dynamic with company leadership is important**: these engineers must be proactive in helping the business, and not simply the "guru on the hill" who provides answers when asked.
- **There are different modalities to get to a very senior level**, e.g. CTO model, technical expert, product engineer, and others. It's ok if you don't want daily meetings with company leadership, but you must be working on a valuable enough problem that can merit an engineer of that seniority.
- **Finding a good manager is critical for both ICs and managers**. Two ways to evaluate this are (1) find a leader who has grown many people and (2) find a leader who is advancing rapidly in their career.

[**Ethan Evans**](https://www.linkedin.com/in/ethanevansvp/) is a retired Amazon VP who now teaches managers how to break into executive levels. He was at Amazon for 15 years, and he became a VP in 2013 until he left in 2020. Ethan shares valuable insights for anyone interested in management or career development.

**Helpful links:**

- [**\[Masterclass\] How To Work Better With Your Engineering Manager**](https://www.jointaro.com/lesson/2PbJb2fuqF3iMHy57eEg/masterclass-how-to-work-better-with-your-engineering-manager/)
- Rahul's Senior to Staff course: <https://maven.com/taro/senior-to-staff>
- More from Ethan: <https://www.jointaro.com/topic/ethan-evans/>
- [Rahul's $800K TC journey](https://www.youtube.com/watch?v=inydj1VZ0y0)

Tech Lead Blueprint 11/17 - Empathetic Leadership

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

DSA Crash Course [Part 40] - Depth First Values Walkthrough

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

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

DSA Crash Course [Part 34] - Zipper Lists Approach

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

> Write a function, *zipper_lists*, that takes in the head of two linked lists as arguments. The function should zipper the two lists together into single linked list by alternating nodes. If one of the linked lists is longer than the other, the resulting list should terminate with the remaining nodes. The function should return the head of the zippered linked list.
>
> Do this **in-place**, by mutating the original Nodes.
>
> You may assume that both input lists are non-empty.

```
a = Node("a")
b = Node("b")
c = Node("c")
a.next = b
b.next = c
# a -> b -> c

x = Node("x")
y = Node("y")
z = Node("z")
x.next = y
y.next = z
# x -> y -> z

zipper_lists(a, x)
# a -> x -> b -> y -> c -> z
```

```
a = Node("a")
b = Node("b")
c = Node("c")
d = Node("d")
e = Node("e")
f = Node("f")
a.next = b
b.next = c
c.next = d
d.next = e
e.next = f
# a -> b -> c -> d -> e -> f

x = Node("x")
y = Node("y")
z = Node("z")
x.next = y
y.next = z
# x -> y -> z

zipper_lists(a, x)
# a -> x -> b -> y -> c -> z -> d -> e -> f
```

```
s = Node("s")
t = Node("t")
s.next = t
# s -> t

one = Node(1)
two = Node(2)
three = Node(3)
four = Node(4)
one.next = two
two.next = three
three.next = four
# 1 -> 2 -> 3 -> 4

zipper_lists(s, one)
# s -> 1 -> t -> 2 -> 3 -> 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/>

Maximize Your Productivity As A Software Engineer [Part 10] - Organize Your Calendar

Now we know that focus blocks are one of the most powerful weapons in a software engineer's arsenal. So how can we get them? This lesson teaches you:

- How to organize your meetings in the most efficient way
- What you should look out for when it comes to clearing space on your calendar

Master The Behavioral Interview [Part 13] - Good Vs. Bad Questions To Ask

You're a software engineer and you have slogged through the behavioral round, answering many grueling questions. And now the interviewer opens up the floor to you: "Do you have any questions for me?". What do you do here? This lesson teaches you:

- What a good behavioral interview question to ask looks like through many examples, which you can ask word-for-word in your next behavioral interview
- What a bad behavioral interview question looks like (avoid these)
- The attributes of a high-quality question vs. a low quality question in a behavioral interview

Grow From Mid-Level To Senior Engineer [Part 24] - Go Deeper: Follow Through

Start a career discussion in Taro: <https://www.jointaro.com/questions/create/>

Join Taro events: <https://www.jointaro.com/events/>

Come to Alex's Group Office Hours: <https://www.jointaro.com/p/alex-chiou/>

Related courses:

- [Nail Your Promotion As A Software Engineer](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/)
- [Managing Up: Build Effective Relationships With Your Boss](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/)
- [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)
- [Effective Communication For Engineers](https://www.jointaro.com/course/effective-communication-for-engineers/)
- [Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

Grow From Mid-Level To Senior Engineer [Part 10] - Code Review

Writing code is great, but so is reviewing code. In fact, being great at reviewing code is more impactful than being great at writing code 90%+ of the time! This lesson teaches you:

- How the writing code vs. reviewing code dynamic changes as you get to senior
- Why senior engineers tend to review more code than they write
- How senior engineers expand their code review scope while mid-level engineer code review scope tends to be more constrained with a real-life example
- The difference between a senior engineer code review comment vs. a mid-level engineer code review comment

Get better at code review with our masterclass: [\[Masterclass\] How To Do Amazing Code Review](https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/)

Becoming A Staff Engineer In Big Tech (Panel Discussion)

The journey to Staff Engineer is unique for everybody. Let’s talk about all the ways we got there! Senior Engineer is a terminal level at most tech companies.

Staff Engineer is the next level up. This is referred to as Staff at Meta/Google, or Principal Engineer at Amazon/Microsoft. ([Rahul's promotion story](https://www.jointaro.com/lesson/qvp2quodqAEWSkN7sayt/case-study-building-a-meta-internal-tool-to-empower-an-entire-org-staff-promotion-story/).)

Partial list of questions discussed:

- How do you know which problems are worth solving?
- How do you communicate to your manager that you want Staff promo? And what do you look for in a manager?
- What type of teams do you think best support growth into the Staff level?

Panelists:

- [**Zach Wilson** - Airbnb](https://www.linkedin.com/in/eczachly/)
- [**Rahul Pandey - Meta**](https://www.linkedin.com/in/rpandey1234/)
- [**Carly Taylor - Activision**](https://www.linkedin.com/in/carly-taylor-data/)
- [**Lee McKeeman - Google**](https://www.linkedin.com/in/lmckeeman/)
- [**Ryan Peterman - Meta**](https://www.linkedin.com/in/ryanlpeterman/)

See discussions about Staff Engineers on Taro: <https://www.jointaro.com/topic/staff-engineer/>

Watch the full [Senior to Staff course on Taro](https://www.jointaro.com/lesson/NE3J4vWP7BoWlNgbRtCw/becoming-a-staff-engineer-in-big-tech-panel-discussion/).

Maximizing a Severance Package 8/9 - Can You Sue?

- Connect with [Ethan on LinkedIn](https://www.linkedin.com/in/ethanevansvp/)
- Taro members get a discount to join [**Ethan's Level Up community**](https://levelupwithethanevans.substack.com/taro25)

Grow From Mid-Level To Senior Engineer [Part 12] - System Design

System design is a topic engineers are becoming more and more familiar with, largely due to their emerging prevalence in interviews. It's also critical for the mid-level to senior promotion. This lesson teaches you:

- Why system design is the most important technical skill that mid-level engineers need to develop to grow to senior
- The ingredients of a high-quality system design document
- How to get feedback on your system design document
- Tactics to run an effective technical review meeting

Here's the system design course: [\[Course\] Frontend System Design Masterclass - Building Playlists](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

Master The Behavioral Interview [Part 22] - Do Mock Interviews

Software engineers love working and studying solo, but this is extremely difficult with behavioral interviews. This lesson teaches you:

- Why behavioral interviews are inherently collaborative and effectively require mock interviews to master
- How to get the most value from your mock behavioral interview sessions

Onboarding Tips Within Larger Companies

In a large company, you should expect a more formal onboarding process. However, don’t let this be an excuse to move slowly. Your goal is (still) to set up your environment and land code within a week.

Big companies will have many teams which may have slightly competing priorities. That means you need to invest in relationships and understand how the work connects between teams. Disperse and collect knowledge from around the company.

Spend some time understanding the unique terminology and culture of the company. Companies like Amazon, Meta, Google, Microsoft are large enough that they have their own set of acronyms, languages, and cultures!

Maximize Your Productivity As A Software Engineer [Part 14] - Do The Hardest Thing First

When you get a tough project, it's tempting to tackle the easiest parts first because you already know how to do them, putting off the most difficult portions for later (you'll totally figure it out right?). This lesson teaches you:

- The difference between bad and good engineers when it comes to taking on a project
- Why tackling the hardest parts of a project first is effective risk management and a defining behavior of the best tech leadWhen you
- The massive team-wide benefit solving the hardest problem grants you

System Design Series: Taro Playlists [Part 6] - Overall Approach And Tradeoffs

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're designing systems at your job!

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

- When it comes to determining your overall approach, it's important to understand the priorities and values of your team/company. You can't have it all when building software; when you invest more in a certain attribute, it will generally take away from others. Here are some example attributes:
  - Execution speed
  - Feature robustness
  - Code readability
  - System scalability
  - Design and aesthetic
- Taro and very early-stage startups in general will make warped decisions as the prioritization leans extremely heavily towards execution speed. The goal is to 80/20 as much as possible when it comes to all the other attributes surrounding quality.
- Since this case study is a pretty basic CRUD play building on top of an existing model, there isn't too much complexity around the approach. However, you generally want to propose 2+ concrete approaches and the tradeoffs behind them, especially at a Big Tech company where you often have many, many options.
- Here are the technical design principles covered in the video:
  - **Single source of truth**: This is a very easy way to systems to break and have inconsistent experiences. Let's say your content object has 2 fields, a boolean of "hasLikes" and then an array of users who have liked this particular piece of content. You can either check the emptiness of the array to see if the object has likes or consult the boolean. It's extra work maintaining these 2 different representations of this information, and if they fall out of sync and 2 services/surfaces each read from a different one, things will get weird.
  - **Smart server, dumb client**: You cannot scale the user's device unless you ship them a new computer or phone. However, you can theoretically infinitely scale your server-side. This is why clients (i.e. usually front-ends) should be as dumb as possible with the back-end abstracting away as much complex logic as possible. This is especially true when your product is a mobile app as there will always be users lagging on older versions of the app - You don't want to have to make a mobile update every time you have a basic product logic change. Make your back-end protocol generic, flexible, and powerful.
  - **Be additive with data model**: This is primarily relevant with mobile apps as you will have users on older builds. If you change or remove a field, older builds will break. You can't count on your users to all update to the latest version of your app immediately.

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

If your job search dilemma isn't covered by this course, start a community discussion here: <https://www.jointaro.com/questions/create/>

Taro regularly hosts events to get your resume reviewed, pair up for mock interviews, and deep-dive into system design problems. You can find those events here: <https://www.jointaro.com/events/>

**UPDATE:** We have shut down Taro Networking as a feature. Sorry for the inconvenience 🙏

Maximize Your Productivity As A Software Engineer [Part 17] - The Demon In Your Pocket

Smart phones unlock infinite opportunity, but they also unlock infinite distraction - We've all lost countless hours towards mindlessly scrolling through the many addictive apps on our mobile devices. This lesson teaches you:

- A basic tactic to prevent you from getting distracted by your smart phone
- A more involved and technical tactic to discourage smart phone user, which Alex is a big fan of
- An extremely aggressive tactic to get your smartphone away from you, used by a Staff Engineer at LinkedIn who's also a parent!

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

Grow From Mid-Level To Senior Engineer [Part 13] - Just 1 Sentence Is Enough

As a software engineer, you will often get tasks and projects that aren't fully defined. How you react and are able to perform in these scenarios is a huge factor when it comes to determining your seniority. This lesson teaches you:

- A simple framework to understand the expectations of a senior engineer when it comes to handling ambiguity
- The different components that go into converting a single sentence to a full-blown project

Claiming Full Credit For Your Projects On Performance Review

- What is the project: Which features did it compose of? How does it work?
- Context behind the project:
  - Why was this project hard/interesting: Complexity of projects is especially important for more senior engineers.
  - What was the business impact: Did it lead to more revenue directly? Did it improve user experience? Was a core KPI increased?
- Role you played in the project: What value did you specifically add to the project, especially that of the deeper kind? For Big Tech companies, this is very important as projects can easily have 15+ people working on them.

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.