Career Advice About Netflix

I'm relatively new to Netflix, and I'm a senior engineer. What's crazy is that I have so many teammates that are also L5, but I feel like they're way better than me. They have far more experience, and they're amazing at all these hard skills like running meetings, designing complex systems, and being able to go super technically deep. I feel like I'm far behind them in these areas, so I'm looking for advice on how I can improve my mentality here and catch up as a strong senior engineer.

In anticipation of my , we can collect questions here. I can also answer questions afterward.

Work history

I've worked in leadership positions at companies like Netflix (2013 - 2017), Google (2017 - 2021), and now Disney. I'm currently a Director of Software Engineering at Disney as part of Disney Streaming (Disney+, Hulu, ESPN+ Star+).

Happy to talk about mobile development, engineering management, and career growth.

Other

I have a deep background in music and audio, having received a Masters in Music & Audio Technology in 2003, and then working with Dolby for more than 5 years.

After I left Google, I took a career break to learn, explore, and recharge. I traveled to Ghana, learned about accounting, became a startup advisor, and read a lot.

I'm on LinkedIn here: .

How can I prevent myself from putting myself in a job where I have to recode an entire code base after a long amount of time on a product?

More specifically, how do I identify good teams that have working styles where you aren't having to refactor an entire codebase and have a frustrating work environment? In the past, I've heard that at companies like Netflix that people can just code in whatever language they want, then when folks sometimes regroup/resync with a larger product team, one team in a particular language will win, leading to large parts of other specific devs on the team to hate it because they have to refactor their code.

How does one come up with certain criteria (and follow through with it) as they interview for jobs and specific companies about working styles on preferences of code base, tools, frameworks?

What other core principles and criteria folks consider as they're interviewing other people (not just the company interviewing for a role) that they should consider as a part of the dev culture, structure when it comes to these types of things so I don't make the same type of mistake?

And yes, I know people refactor code bases (ex. legacy projects, cleaning out whatever tech debt folks have), which people tend to hate because it's a lot of work--and that it's still bound to happen and unavoidable, but how can we eliminate cultures we dislike that are refactoring code bases as a result of a dysfunctional tech team? I want to avoid having terrible experiences at a future company I work (similar to an hackathon experience I had recently working on a small MVP can be frustrating when folks are not aligned / on the same page for things that might take to long to complete or have to refactor completely if they are not communicating well or upfront from the beginning).