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

Level Up Your Code Quality As A Software Engineer [Part 27] - Continue The Learning Journey

Watching one course is not going to automatically make you master of code quality (or anything really). To really learn these concepts and burn them into your mind, you need to continue the learning journey. Here's how to do that:

- Start discussions in the Taro forum: <https://www.jointaro.com/questions/create/>
- Join Taro events, especially Group Office Hours: <https://www.jointaro.com/events/>

If you have mastered code quality, then here's a great skill for you to move on to: [\[Masterclass\] How To Become A Debugging Master And Fix Issues Faster](https://www.jointaro.com/lesson/ioR6WzamAIUTpySLAr7o/masterclass-how-to-become-a-debugging-master-and-fix-issues-faster/)

Level Up Your Code Quality As A Software Engineer [Part 16] - One Diff, One Thesis

One of the biggest and easiest ways to level up your code doesn't even lie in the code itself and is about how you split it up when submitting it for code review instead. This lesson will teach you:

- The most common way low-performing software engineers mess up their code when submitting it for review
- Why championing the concept of "One Diff, One Thesis" massively boosts your productivity alongside your code quality
- How to tell whether your pull request follows the principal of "One Diff, One Thesis" or should be broken up into smaller pull requests instead
- How to split up your technical task or project into chunks, so you can map out its pieces to a series of pull requests following "One Diff, One Thesis". We do this with an in-depth example further digging into the login flow

How To Decide To Leave A Company: Generalist to Specialist shift

Philip spent many years at Microsoft, followed by many years at Facebook (Meta). What led him to finally decide to leave each company? 

More to explore: 
- Our masterclass on [How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/how-to-build-deep-relationships-quickly-in-tech-12172022/)
- Connect with [Philip Su](https://www.linkedin.com/in/suphilip/)
- [Why Slack Sucks for Team Communication](https://www.jointaro.com/lesson/yurIkW9cyU9lkG3FjYnU/what-gets-communicated-gets-done-why-slack-sucks/)

Manager 1 on 1s Are A Litmus Test For Seniority

True or false: In tech, operating at senior levels means that you are driving more, if not most, of the conversation in your manager 1 on 1s.

Why do senior employees tend to drive more of the conversation in manager 1 on 1 meetings?

Your 1:1 meetings with your manager can demonstrate whether you are becoming a senior engineer.

Master The Behavioral Interview [Part 2] - You're (Probably) Sleeping On Behavioral

Grinding LeetCode endlessly makes no sense and will not get you a great software engineer job, especially in a bad market. So why does it makes no sense? Because data structures and algorithms (DSA) rounds are far from the most important. This lesson teaches you: 

- The reason why companies weigh behavioral interviews so heavily (usually more than candidates realize)
- Why behavioral interviews are actually the most important interview type
- How engineers waste the precious time they have in behavioral interviews

Ace Your Tech Interview As A Software Engineer [Part 4] - The #1 Trait For Interview Success

Software engineers overwhelmingly blame the wrong thing when it comes to why they aren't landing job offers, particularly their own lack of skill. This lesson teaches you:

- What the actual #1 trait among successful job searchers is
- How to build up your personal grit
- Why most software engineers have the wrong perspective post-interview and are unable to fully learn from their failures
- The success metric you should be weighing yourself against as you progress through the job search, viewing everything as more of a spectrum instead of a binary state

To go deeper into developing your grit and boosting your productivity, watch this video: [2 Ways To 100x Your Productivity That Nobody Does](https://www.jointaro.com/lesson/RXEca9zfyZG0pl015att/2-ways-to-100x-your-productivity-that-nobody-does/?playlistId=JNCZ1vbRF3NwsOQCqblt)

How To Tell If A Layoff Is Coming At Your Company

Layoffs are scary and are often a complete surprise. This video covers some of the warnings signs you can use to predict if a layoff is coming and start preparing for interviews accordingly.

Here are the core points:
- *For public companies, the most obvious sign is a struggling stock price*
- In general, stagnant growth is bad
- Mass hiring freezes are a common precursor to big layoffs
- Trimmed perks and a more somber, frugal mood among leadership are other signs
- You can also listen through the "grapevine" but be careful
  - Blind in particular is quite flaky. Blind correctly predicted the Fall 2019 and Spring 2020 layoffs, but *it also incorrectly predicted 18 other layoffs*
  - In general, treat online rumors with a massive grain of salt, and it's probably best to just stay away from them. There's no need to add a bunch of unnecessary stress to your life

Related resources:
- [[Masterclass] How To Survive Tech Industry Layoffs](https://www.jointaro.com/lesson/axnVXYox5QeOneqcoyuH/masterclass-how-to-survive-tech-industry-layoffs/) - The full video where this clip was taken from
- ["What are the signs of an impending layoff in an organisation that can help an employee prepare themselves better?"](https://www.jointaro.com/question/tNOO9FtALQIRrUXSqzV1/what-are-the-signs-of-an-impending-layoff-in-an-organisation-that-can-help-an-employee-prepare-themselves-better/)
- ["How to handle stress at work especially after a company layoff?"](https://www.jointaro.com/question/mOjMnHL2Zhke2rSrtVdD/how-to-handle-stress-at-work-especially-after-a-company-layoff/)

Why Chasing Promotion Could Hurt You

Daniel has never gunned for a promotion when choosing teams or projects. In fact, he's actively turned down promotions he was offered at Microsoft and Meta (Philip Su famously down-leveled himself at Meta so he was no longer a Director). 

Here's why chasing a promotion could end up causing more stress and end up hurting your career in the long run. 

- Connect with Daniel Tomko on [LinkedIn](https://www.linkedin.com/in/danieltomko/)
- Videos from [Philip Su](https://www.jointaro.com/tagname/Philip%20Su/)

Related video: 
- [Taro Premium Session: Mentoring Meta Engineers From E3 -> E5](https://www.jointaro.com/lesson/EX9563YnxcJb62cCmetg/session-5-mentoring-junior-swes-e3-to-senior-e5-in-just-25-years-at-meta/)
- [Rockstar Software Engineer Story: SW2 -> Principal In Just 4 Years](https://www.jointaro.com/lesson/Lvf1TDKt1R4ZJSCr9BVv/rockstar-software-engineer-story-sw2-greater-principal-in-just-4-years/)
- ["Is there something as growing too quickly?"](https://www.jointaro.com/question/o9oyCcIjWT4Xa6w1Eau5/is-there-something-as-growing-too-quickly/)

[Case Study] Effective Communication: Leading A Multi-Org Re-architecture At Meta

Here are [the presentation slides](https://docs.google.com/presentation/d/184dP9pi41lO5TlME4cn4fRblCPtKFdet7d5WmrpnbGc/edit?usp=sharing) and the [polished chat log](https://firebasestorage.googleapis.com/v0/b/tech-career-growth.appspot.com/o/tps_chats%2Ftaro_premium_session_4_chat_notes.txt?alt=media&token=ca1a199d-fe36-42bc-8d2e-fc91371e691f) from the session.

As an IC, you don't have authority over engineers in the way a manager might. So your impact is defined by your ability to have **influence without authority**. Influence comes from consensus + collaboration, which comes down to communication. Said another way: Communication is the foundation for trust. 

Rahul talked about 3 parts to effective communication in this presentation: 
- **Start with the audience**
  - Understand how much context your audience has, and connect the dots for them.
  - Your communication should be as short as possible.
  - Bad news should never be a surprise.
- **Choose the right medium**
  - Do some reflection on what your objective is: build relationships or efficiently communicating some info? Be clear the difference between verbal and written communication.
  - Evaluate the current processes for communication in your org: standups, team meetings, email updates, cross-org communication. 
- **Be consistent**
  - You should have a regular drumbeat of posts for your projects. If you feel like nothing happened, you should explain why nothing happened.
  - For long-running processes like brainstorms or architecture reviews, you should consistently message the timeline and milestones.

Related resources:
- ["How can I come up with big initiatives, especially those at a Staff level?"](https://link.jointaro.com/sm57uikgXJ3RRpTv8)
- [Writing is thinking](https://medium.learningbyshipping.com/writing-is-thinking-an-annotated-twitter-thread-2a75fe07fade) - by Steven Sinofsky (Former President @ Microsoft)
- [Be plainspoken](https://boz.com/articles/be-plainspoken) - by Andrew Bosworth (VP of Eng @ Meta)

Why IN PERSON Meetings Are Important for Building Culture


  How can you build relationships and team culture in a hybrid or remote team? 

Unfortunately, the physical connection you get from being in an office is much harder to emulate online. If you are in a remote environment, having some sort of in-person meetup can create a substantially healthier and bonded team.

Philip also talks about how to best evaluate a company culture: talking to senior individual contributors (ICs). Managers may provide less value since they have something to sell.

More to explore: 
- Our masterclass on [How To Build Deep Relationships Quickly In Tech](https://link.jointaro.com/MvHfGDSzxwboGqBB8)
- [Why Slack Sucks for Team Communication](https://link.jointaro.com/JmHCagUPAFPSCtt99)
- Connect with [Philip Su](https://www.linkedin.com/in/suphilip/) 

What The Optimal Discussion On Code Review Looks Like

In this video, we explore the **spectrum of code review discussions**, highlighting what kinds of conversations are appropriate—and which are not—for an effective and healthy code review process. We emphasize that great code reviews live in the middle: technical, constructive, and context-rich.

### Key Takeaways:

- **We avoid extremes on the code review spectrum**: Debates about architecture or product behavior should happen *before* the code is written. On the other end, trivial nitpicks like formatting should be automated with linters—not left to human reviewers.
- **We aim for meaningful middle-ground discussions**: The best code reviews focus on topics like naming clarity, input assumptions, and logic validation—things that improve understanding and code quality without being overly granular.
- **We talk about testing and future-proofing**: We use code review to validate testing strategies and anticipate how upcoming features or changes might interact with the current code—enabling forward-thinking design.
- **We reduce unnecessary friction with agreed standards**: By aligning on style conventions and automating formatting checks, we free up our code reviews to focus on higher-order thinking and shared learning.
- **We use code review to transfer experience and context**: A reviewer’s knowledge of future plans or broader system behavior adds lasting value. These discussions aren’t just about code—they’re how we build team wisdom.

Structuring Your Manager 1 on 1

If you are working in a strong, high-growth tech company, what is a good frequency to meet with your manager?

True or false: Managers are extremely busy, so it is best to have ad-hoc 1 on 1 meetings with them based on whenever they are able to find a sliver of free time.

Your relationship with your manager should be more proactive than reactive.

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

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

How To NOT Learn A Codebase

The biggest mistake engineers make when going into a new codebase is to excessively read through the code and documentation. This is a horrible way to learn. 

The problem is exacerbated because the supporting documentation of the code is usually out-of-date: the docs can't keep up in a fast-moving tech company.

Instead, just dig in and start coding!

- Break things
- Add all the print statements ever
- Get the debugger working
- Run the code and see what happens

The key takeaway is that you should **get your hands on the keyboard** (even if it's uncomfortable).

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.")

Level Up Your Code Quality As A Software Engineer [Part 17] - Share The Context

Software engineers often have this flaw where they assume that everyone somehow automatically knows what they're doing and the nuances of the spare they're operating within. This often extends to their published pull requests. This lesson will teach you:

- The ingredients behind a high-quality context section on a pull request
- A simple tactic to greatly expedite your pull requests, build respect amongst your team, and get better feedback (hint: It's not just your teammates who can review your code)
- Exactly what a stellar context section looks like with an incredibly detailed, broken down example. This is a trademark sign of high-performing mid-level and senior software engineers

[Case Study] How I Get 500,000+ LinkedIn Post Views Per Week

[Alex Chiou](https://www.linkedin.com/in/alexander-chiou/) is one of the cofounders behind Taro, and he owes a lot of his success building up Taro to his LinkedIn profile. As of September 2023, he:

- Has 66,000+ followers
- Gets 500k - 1M post views per week
- Spends just 10-15 minutes writing each post

Alex covers a lot of ground in this presentation, so here are just the Top 5 core points:

- **LinkedIn is extremely underrated** - When it comes to return on investment for your time, LinkedIn is easily one of the most effective content creation platforms if not *the* most effective. Unlike TikTok, Instagram, and YouTube which are media-based and require lots more effort, you can regularly go viral on LinkedIn with relatively short snippets of text.
- **Consistency is key** - LinkedIn is pretty generous at allowing you to post many times a week without your posts cannibalizing each other. Try to post at least 3-4 times a week with the upper bound being 2 times a day. If you post too frequently, you are leaving views on the table. Also, you are naturally going to have some posts that do terribly and some that do well: By taking more shots on goal, you are evening out your returns. *Variance can be conquered with volume.*
- **Keep it short, don't be too smart** - This is *by far* the most common mistake Alex has seen aspiring LinkedIn creators make. Engineers tend to be very smart people who love to cover all the nuance, which leads to overly long posts that are neither concise nor dense. This type of content does horribly on social media. Alex's style is to have 5-9 sections (each separated by a line break) with each section being just 1-3 lines for a 30-75 second read. Keep it snappy.
- **Write first sentences, not posts** - The entire purpose of the 1st sentence is to convince the reader to read the 2nd. LinkedIn by default hides the vast majority of your post's text behind the "See more..." button. Purely focus on writing a compelling first sentence, and the rest of the post should flow from there.
- **Never forget: It's just social media** - LinkedIn, like every social media platform with 100M+ users, is full of dumb stuff. *Don't let that get to you*. Don't be afraid to disengage from the platform and not read notifications and comments. And never ever couple your emotional state to how well your social media posts are doing.

Related resources:

- ["Why should I bother building a brand or becoming famous on LinkedIn?"](https://www.jointaro.com/question/s1NVrO0VlvIufReDKCSl/why-should-i-bother-building-a-brand-or-becoming-famous-on-linkedin/)
- ["How to be brave and post publicly on LinkedIn?"](https://www.jointaro.com/question/xUJSnOXQOmJyisZCB0Qa/how-to-be-brave-and-post-publicly-on-linkedin/)
- [\[Case Study\] Building An Engineering Brand - Why And How (LinkedIn, YouTube, Twitter, Substack)](https://www.jointaro.com/lesson/t06NajpS2kSCk98IEmQm/case-study-building-an-engineering-brand-why-and-how-linkedin-youtube-twitter-substack/)
- [How Rigid Should You Be With Your Coding / Content Schedule?](https://www.jointaro.com/lesson/GaOB5qFLoTbGilp7UokF/how-rigid-should-you-be-with-your-coding-content-schedule/)
- [Presentation slides](https://docs.google.com/presentation/d/1-_it2buJQ764fQAf5MgXtIKRrYJPI_ayUv5WdU5cslw/edit?usp=sharing)

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)

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.