I had one I was dabbling with temporarily until I got busy, but maybe you can build it out.

**Problem**: short video content users (on instagram/tiktok/youtube) receive tons of restaurant recommendations from creators. They either have to disrupt their browsing experience (and manually add the place to some Google Maps list); or save within app and forget about it when you actually need it (Sunday night dinner plans?).

**Solution**: When seeing a reel/short/tiktok that recommends a restaurant by a creator, you can share the reel/link to an app X. The X app will automatically parse the video, extract restaurant name, retrieve metadata (like price, timings, ratings etc.) from google maps API, and present to users of this app in a few different formats: map view, list view, with filters like ratings, distance etc.

**Challenge:** the short form videos do not clearly tag restaurants in a well-structured format. Sometimes it's voiced over, sometimes it's in caption, sometimes as a text embedded in the video. Can you use LLMs? 😉 Extract all "text" from the video, feed into an LLM, and that should be able to give you restaurant name.

**Technologies needed**: react JS, Android/iOS app development, queues for video processing, databases for storing/serving content, LLMs (fine tuning, prompting etc.), Maps API integration, OCR, video processing.

I'd be happy to consult if you need inputs -- this is certainly a 3+ month project to build out MVP (if you work full-time on it).

Staff SWE @ YouTube, Engineering Mentor, SWE Guru

Lalit Kundu

There's wide variety of archetypes at L7 and L8 levels. You cannot prescribe a fixed/minimum size of the org as a factor. However, outsized impact is a minimum at those levels. 

For example, one recent L6-&gt;L7 promotion in my organization: technical lead for 60+ engineers from my organization, working with x-fn/x-team for an year, to launch a $XB+ ARR product for YouTube. This is a typical project TL type of role.

There's other archetypes where you solve a deeply technical problem, with a very small group of engineers even. I had a mentor who saved Google millions of SWE hours by redesigning core search infrastructure.

You are spot on about the confusion overlap of responsibilities between a TL and a manager. Here are some high level patterns of how IC and managers operate.\
\
**Typical IC patterns**\
\- deeply technical, but also broad scope \
\- “strategic advisors” to managers\
\- leading technical advancements in broad areas\
\- leading technical projects over long horizons\
\
**Managers**\
\- more business oriented, creating areas of growth and sustainability\
\- dealing with the efficiency of the organizations (via organization structure, processes, performance reviews, resourcing decisions)\
\- resolve conflicts, focus on equitable growth for everyone\
\- defer to ICs for technical decisions, but influence.

I get into further details of overlap of responsibilities between TLs and managers in this video in my course for grow into a TL role: <https://www.jointaro.com/course/tech-lead-blueprint-role-skills-and-strategies/why-do-tls-exist/>

I have done my fair bit of "influencing" with over 100k combined followers, 7m+ impressions on LinkedIn, TikTok, Quora etc. I'll keep it short in a pros/cons list.

**Pros**

- **Social impact:** absolute #1 for me, being thanked by individuals I impacted or uplifted.
- **Writing/speaking/articulation/confidence/creativity**: qualities all good leaders need. Based on the medium, you will have a chance to build all of these qualities.
- **Connections**: chance to meet other influential and fun personalities (like Rahul).
- **Side-hustle**: Personally, I have had a strong principle to not make any money from my mentorship initiatives; and I donate 100% if I do make nominal amounts. Some people do make a few hundred bucks per week/month though.

**Cons**

- **Takes time:** certainly takes good amounts, will have to cut from either life, or work, or time you could've spent learning.
- **Vanity metrics**: you may get attached to the "wrong" metrics (follower counts, etc.) and soon it'll be a toxic relationship with social media.

What a thought-provoking question!

I am blessed to have the opportunity start my career with launching Google Pay in India, as one of the core engineers on payments backend; and since then bolstering YouTube's ecosystem with a 16x growth in non-advertising revenue. I started my journey as competitive programmer who was used to writing deterministic coding solutions under time pressure. Within 6 years, I lead 45+ engineers to solve real-world problems and build products for billions of users!

Looking back, I took a generalist SWE approach in consumer facing domains: I have superficial knowledge of various technologies, somewhat decent product and program management skills, and a good collaborative personality.

I believe that to be a successful generalist, you need to have experience with as many product and technical domains as possible -- somewhat like how consultants have problem-solving experience in various industries. I personally haven't had that, having spent a long time at YouTube. Even at the expense of pace of growth, perhaps I should've ventured to different domains -- ads, search etc., and worked closely with a few other technologies -- like frontend, AI etc.

I still have a long career to go, and I look forward to expanding my generalist expertise :)

Great question!

Looking back on my journey as a SWE, I was a quick learner and had decent technical chops by the time was an L4+ at Google. Around that time, I learnt the concepts of extreme ownership and program management skills that lead me to becoming L5.

Now, my path from L5 to L6 was a combination of doing what I was doing but at a larger scope (so bigger team, harder technical problem etc.), but an additional critical skill which is often ignored by TLs: **team cohesivity and growth**.

- **You deliver faster**: your team, like a well-oiled machinery is productive, is free of interpersonal conflicts and individuals co-operative and helpful to each other. All critical parts of recipe that delivers faster.
- **You scale yourself faster**: if you can grow your junior eng into senior, you free up time for yourself to tackle even bigger things.
- **You quickly become a valuable TL to managers**/senior leaderships -- you want to get their reports achieve their goals (promotion, work-life balance, fulfillment)! 

I get into more details of this skillset (with some more anecdotes) in the *Team Unity + Growth* section of my course for TLs: <https://www.jointaro.com/course/tech-lead-blueprint-role-skills-and-strategies/empathetic-leadership/>

Fwiw, the whole course is useful for learning behaviors and leadership skills that L6+ engineers need.

Looking at the breakdown of tasks, it's impressive you could do so much and get involved in various things in the first month at a company. A lot of ramping up for tech leads means getting acquainted with processes, designs, individuals, working groups and culture of the company. It makes sense to me that you had no time for coding!

But I would provide two alternative perspectives

1. **Two-pronged rampup:** for ramping up in an area, no matter how senior/junior you are, I suggest tackling it from both ends (high-level designs, etc., but also low-level technologies, code stack). I have some more advice on this in this newsletter: <https://www.linkedin.com/pulse/how-onboard-new-technical-space-quickly-lalit-kundu/>
2. **Long term balance for TLs**: Depending on the domain, the org's needs, how large the influence area of a TL is, and archetype of TLs you may be writing tons of code or writing none at all. It's a big spectrum. On one end, you could be TL for a large team of 40+ engineers, leading multiple staff engineers on projects. You'll probably write a few strategy docs, review other's designs and review CL, with few coding contributions (depending on how much time you've left after meetings). On the other hand, you may be solving a deep technical problem with a small group of 3-4 engineers, not requiring large amounts of x-fn collab, in which case you'd be writing and reviewing tons of code. So, you have to see: are you a TL that solves coordination problems, or a TL that specializes in deep technical problem-solving. Most people lie somewhere in between.

Good luck, and hopefully you've been enjoying the course :)

This reminds me, one time, I was driving a project across my organization at Youtube, dealing with changes in a few sub-teams' systems. TLs of these sub-teams were leading the work in their area, and I was the "end-to-end" expert, ensuring all pieces fit together. But I was only an L4 at that time.

Anyhow, at the last moment we discover a new requirement and I volunteer to make some quick code changes in another sub-team's (say A) codebase because engineers on that team were busy with other things. I sent my code for review to team A's TL and a fresh grad (say G) on team A, both of whom were staffed to the same project. Now, G, while extremely smart and intelligent, had some bitter feelings around how I, just an L4, could be "leading" such a big project and he didn't necessarily respect my authority or expertise.

Now, this code change was pretty small, adding one or two new methods of 5-6 lines each. In the first round of review, he left a bunch of nitpicks around variable naming and such, which I happily addressed. Next round of review, one of his comments linked to a doc which rewrote the whole code by breaking it down into super-granular methods (of two lines each). I was flabbergasted! I felt like blasting him in the comments and asking him to write the whole damn code himself instead (which he's already done), but I held back. I copy pasted whatever he suggested to my change and went on with my project.

A few weeks down the line, his manager (overall project lead) asked me for feedback, specifically about him. I wasn't surprised, because apparently there had been mentions of similar interpersonal issues impacting others in the team. I gave honest feedback, in typical sandwich style. I appreciate his good qualities, sprinkled in some specific and evidence based incidents of things he can do better, and wrapping up with how much potential he has.

Long story aside, I learnt how to control some of my strong negative emotions in the moment. I can promise you that, never ever, has an outburst of expression of negative emotions in the moment has helped me. It always has become something I need to address down the line.

For your specific scenario, I would like to share this pattern I've seen: seniors provide more feedback (including nitpicks) to new junior engineers. In some time, they start trusting them more, and provide more autonomy. So, do evaluate if you have earned that autonomy yet.

With peers and juniors, it's a bit tricky. They don't have authority, but it's still good to have a good relationship. My formula is simple: if nitpick is easy to address and not completely absurd, I do it, no questions asked. This avoids unnecessary/futile conflict. But, if nitpick would take more effort to address, or doesn't entirely make sense, I explain my reasoning and gently turn it down. If they still don't back down, I meet in person to discuss to understand how important it is to them on a scale of 1-10. Then I evaluate how hard/absurd it is to me on a scale of 1-10. Based on these two numbers, typically we have an answer.

Staff Software Engineer [L6] at Google

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!

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!