Alex and Lee have great thoughts, and I'll add some on top of those.

**All staff engineer promos lie on a spectrum**

- from, a deep tech contributor that solved a (or two) very hard problems
- to a proven lead of a big team, advancing the team over a long time horizon

**What is a hard problem and where to find them?**

I'll throw some examples, see if you can notice the patterns

- **one liner in the mind of an org lead**: "we have a reliability problem", "our subscription churn numbers look high". Just one line. No more. If you see that nobody can't articulate what the problem is further, forget solution, that's a potential problem. Anyway, talk to your leads, see what bothers them, volunteer to take on challenges. Albeit many of these would be risky problems to pursue without impact, but that's what a staff engineer does: entrepreneurial in approach, risk taker but also knows when it's time to move on.
- **big top-down project, are you suited?:** compliance, business critical and deadline projects are best for delivering impact and less risky. But they're often the most sought after too. So, how can you position yourself to be the lead? Be curious, participate cross-stack cross-team, build surface knowledge level of everything and deep knowledge of at least one portion of overall stack.
- **what does the business need?:** if your org doesn't have a "busy" charter with proven/low-hanging fruits, you need to become an entrepreneur yourself. Figure out how you can impact topline metric of your org (revenue/users/clients): brainstorm and collect ideas from product managers, EMs, UX, data science and your partner teams how you can create positive impact on your business. List down all the ideas; sort them by a function of effort, confidence and impact. Pick top 5 and voila, you have a strategic roadmap. Convince your leadership to fund it, execute on it and that's your staff promo.

These are some generic patterns, but each org and situation is different; and sometimes there's no bandwidth to do any of this (you're stuck doing someone else's staff projects). Patience and diplomacy with your manger is the answer there.

Good luck!

Staff Software Engineer [L6] at Google

Lalit Kundu

Being a mentor is hard. I've had some great mentors in my career. I myself coach and mentor software engineers in and outside my org. Two main tips that bad mentors don't employ

- Listen to learn: not to fix. You don't want to tell answers directly. Lead with curiosity and shape the thoughts of your mentee gently. Ask questions. Rephrase what they've said to understand further.
- Respect and observe emotions: fear, frustration, joy, excitement -- all of these play an important role in how people operate. Notice and help notice your mentee these. Acknowledge them.

Doing work misaligned with your goals, values or principles can be jarring and is the top reason for burnout. What's great in your case is that you've recognized it pretty well, many engineers go without understanding this main root cause of burnouts. I myself have been in situations like these.

There's many options in front of you that you can pursue (that are not mutually exclusive)

- **let's manage frustration in current project**: debug a little further what's causing the frustration. Perhaps this "chaos is a ladder"? Or an opportunity to gain some new skillsets (like stakeholder management, "politics") that'll propel your career in the long term? Perhaps it's an opportunity to learn how to overcome interpersonal challenges? Perhaps you can sell these challenges to your manager and create a positive perception on your work? and so on. Bottomline: is there a silver lining in all this?
- **work with manager to fast track transition:** articulate your frustration and pain to your manager. Explain why there's no synergy with your goals/skill sets. Any good manager will be able to recognize the stakes, and make it their problem. You don't have to be alone through this.
- **switch teams/orgs/companies:** this can be a last resort, but any fast switches in orgs/companies that are visible on the resume might be a red flag to a hiring manager in the future. It's certainly explainable though, and might even be a great story that shows some of your qualities. There's also risk in the current job market, and it comes with a lot of stress too. This one depends on your appetite. 

Good luck!  

For what you described, which is a large scale code change, I think doing it incrementally is how I'd go about it. You incrementally "merge" your small change back into the "main" branch. That way,

- you don't have to whole hog test and release everything
- you risk only a "small"/contained outage
- you start getting the benefits of the migration from day 1

This approach can be applied to large architectural migrations as well in fast paced teams. Say you have an old stack O1, and you want to move to your new stack O2. Building O2 will take 2 years for the current features that are supported in O1. Meanwhile, team also needs to launch X new features per month to the users. There are a few typical ways of how you can reach your eventual desired state

- Pick sub-systems S of O1 that can extracted out of O1, and implement on O2. You might have to add compatibility layers between O1 and O2. Choose S based on 
  - the benefits of moving to O2 are realized as soon as possible
  - minimize the amount of throwaway work on O1
  - balance engineer staffing so that business doesn't slow down too much

In my opinion, concurrency, memory management, serialization, reflection are few of the complex topics that most developers don't understand the internal workings of.

Effective Java by Joshua Bloch (an ex-googler) is a great book for advanced topics. See if you find some codelabs to do online for the topics.

One last bit, I would like to understand your motivation behind getting deeper (to avoid X-Y problem <https://en.wikipedia.org/wiki/XY_problem>). I have built products using java myself, and rarely I had to do super-deep; and when I had to, I just looked up primers quickly. But if you're passionate about programming languages in general, I understand.

I don't have much details of what features are there in AWS, but just some ideas that you can combine

- Setup quotas: configure a soft and hard limit on how many nodes can be there in a cluster. Perhaps quotas per team?
- Two party control: any change to nodes in a cluster should be approved by one additional person.

If you cleared interviews once, I'm sure you can do it again with a few months of practice. I sense fear that you need to keep up the same level of practice or you'll lose it altogether. But that not entirely true imo. Yes you will struggle in the beginning, you would've forgotten a few complex topics, you'll make bugs in coding etc. But eventually muscle memory kicks in, and second time around it's much easier.

You can invest time in a few other areas meanwhile -- getting promoted in your current company, learning new skills, exploring new software engineering domains that might be interesting to you, do side projects etc.

I feel you, my fellow software engineer.

You have to accept this: the field of software engineering is vast, and growing at a pace faster than ever. The number of technologies, frameworks, AI findings, frontend technologies, vector databases, and what not. It's impossible to go deep into everything. If I look at myself -- I know a handful of Google's proprietary technologies deeply and for the rest I have a surface level understanding.    

So what do you do? There's two paths here. One, you go deep into an area: like AI, frontend, databases etc. You can have a fulfilling career without needing to know everything else in much detail. The other option is a generalist route: successful generalists, imo, have gone deep into various areas in their careers over time, but their overall breadth of knowledge and foundation runs wide.

From what I can tell, you're more aligned towards a generalist role. You have to recognize that it takes patience and time. Generalist keeps switching areas/domains every few years to gain wide experience. They deliver impact no matter what area they're in. I'm a generalist myself. I've learnt few technologies, but also skillset of how to leads experts and combine with my generalist software engineering experience to land large impact, irrespective of the domain.

More tactically, I'd recommend this: do well what you're doing in your current role. Deliver impact, get promoted. At the same time, do some foundational courses to cover what you missed out from your college degree:  distributed systems, databases, AI, operating systems. Remember that the foundation is all you'll remember from these courses over your career -- not the specific syntax, algorithms, programming languages, frameworks, etc. When the time arises to switch domain, you can use your foundation to go deeper.

Good luck!

Adding on to Alex's great points, you need to debug productivity first in your team. Where are engineers spending most time, what takes forever, what are the most annoying tasks. You can just ask engineers and you'd be surprised at the number of ideas you'll get.

But, in my experience, there's a few obvious culprits

1. Too many meetings: engineers don't know which ones are useful to them, organizers don't know why a meeting exists etc.
2. Too much firefighting: that's a reliability issue in your systems. Much harder to solve, but a long term problem to solve.
3. Too many interrupts: other teams, or team members are asking ad-hoc questions that interrupts flow. Might want to sheath your engineers from these incoming requests via office hours.
4. Unnecessary bureaucracy: too many processes to launch a simple thing, or get access to logs, etc. Stuck in getting approvals, writing docs, creating presentations etc.

Happy debugging! Let us know how it goes

A very simple one that I follow is to create a list with following columns

- Behavior: what code/product functionality does this row test. Focus on testing behaviors, rather than underlying implementation details.
- Setup: what are the preconditions before we can execute the behavior. Create a new account, join a certain experiment, etc.
- Steps: These are the core steps to execute the behavior. Click button X, type in Z, etc.
- Expectations: At the end of the steps, what do we expect to happen. User visible behaviors, such as screens do something, receiving an email etc. As well as system behaviors (if relevant): database gets updated, certain data guarantees etc.
- Type of test: You might be executing these manually or in an automated manner.
- Result: Pass/Fail
- Artifacts: Screenshots, evidence, etc.

Typically QA team executes these, but sometimes developers do too. It serves as a great mechanism of ensuring your code changes are working well.

This is such a relevant question! I myself have experienced this on days when I had to work from home due to being sick. During large group discussions, there's so many parallel ongoing threads in a room, and every person in the room then has to pause to hear me speak on video call. Back and forths take forever, as you need to build quorum on who speaks first.  Remote work technology is far away from solving these problems, so we have to operate within the constraints.

There's some obvious ways people will tell you like raise your hand, leave written comments to give opinions, be confident about interrupting the flow since what you say is valuable, and so on.

But these are also some more practical ways of operating within these constraints

1. Build personal relationships and a strong network in 1:1s. Have those discussions in advance with your tech lead and other engineers. That way your opinions are recognized, even if not in one large forum.
2. Make the conversation efficient: if you're driving the discussion, document design options in a document, share in advance and ask for offline reviews. If someone else is doing the same, you can provide your opinions in comments.
3. Organize smaller meetings, if possible. Everyone gets to participate and conversation is more efficient.

Hopefully this helps, and good luck!