To pick a tech stack and stick with it: How is this possible when we switch companies?

In that series, Alex mentioned picking a tech stack and sticking to it.

When I listened to the same talk, I got the sense that when Alex was more talking about sticking with an area of software with similar concerns than specific languages or frameworks, though of course there is some noticeable differences between different languages/frameworks.

For example, there are hundreds of web frameworks and each may be written in JS or TS, but they all fundamentally solve the same set of issues: how to transact data and render UI using such data effectively and efficiently on the DOM. There's likely years of practice necessary to be a good web developer, but perhaps only several months of practice necessary to get good at new UI framework. Even with Android (Alex's example), some companies use Kotlin while others (like Google) mostly still use Java.

C# and Java share many features together and if you were already an expert in building backend using C#, I don't believe it will take you a long time to transition your knowledge and experience to one using Java. As such, I wouldn't be too worried about this, as long as you don't switch too frequently (it still takes ~2 years to really leverage some of the nuanced powers of certain languages and frameworks).

Should I look for jobs that use the tech stack that I am strong with?

I would advise sticking with the same area of software if you can and treat the specific language as a bonus, assuming you like (or at least, don't hate) the problem space within this area of software. Once you master one area, it's much easier to branch out to other areas of the stack since you have something to base your exploration on.

Kuan pretty much nailed it! Things like programming languages and libraries are very nitty-gritty. Being too attached to those leads to the failure mode this question covers: Your expertise is far too narrow, so it's hard to switch teams and companies. This makes your career very brittle - You either need to stay on the same team forever or switch into some very thin set of teams that happens to use the exact same tech stack you're used to.

When I say stick to a tech stack, I'm more referring to the overall area of development like Android, web, back-end API development, etc. By going up to this level to organize your learning, you will pick up fundamental concepts instead of being tied to raw tactical code understanding (i.e. "In order to do X, I have to write Y specific lines of code").

Should I look for jobs that use the tech stack that I am strong with?

With my definition above and your level, I recommend yes. It's generally better to pivot once you get a senior level (e.g. transitioning from Android development to ML infra), as you'll have stronger learning fundamentals.

Or learn and master the tech stack that companies use?

Of course, you always want to adapt to your current environment. However, I also recommend going a bit out of your way to go to a different setup within your tech stack. Let's take Kuan's example with Android. In this hypothetical, you're used to doing Android development in Java and you're going to a Big Tech company. You have the choice between the following 2 Android teams that are equal in all ways besides the tech stack:

• Team #1: Still uses Java, just like your current team
• Team #2: Uses Kotlin

Even ignoring the fact that Kotlin is the more recent paradigm for Android, I recommend #2. By learning to do Android with a different language, you're setting yourself up to better learn Android concepts overall, divorcing yourself from the language-specifics of Java.

Here's a really good thread about finding a balance between specialization and going broad - I highly recommend going through this as well.

I have a story to share on top of the great answers from Kuan and Alex. I also don't think there's a single tech/framework you need to focus on. In fact, being really deep in one technology can be a huge asset when you do switch teams.

At Meta, there was a very senior (E7) engineer who worked on the continuous integration system, then transitioned to working on Android app development. Pretty different area, but he was still amazingly productive since they knew what questions to ask and they came in with deep first-principles thinking. (There was certainly some overlap with the CI system and mobile builds, which helped.)