Switching between technology stacks does not make sense for developers.
It also does not make sense for companies to ask developers to do so.
But there is still a strong demand for it.
This has become a common trend in the software development market lately: Big or growing companies like Google, Amazon and Indeed interview candidates regardless of their current technology stack knowledge. Their recruitment process is focused on common development skills, such as algorithms and other problem solving abilities. During the interview process, you can use the stack of your choice, probably one that you love and use on daily basis. This makes the impression that these companies are very open minded - as long as you pass the interview well, you are in!
When you get in, they give you a technology stack which they use, regardless of what you always used before. And you will need to adapt and grow into that new stack, unless you are ready to change the job again.
If you already use stacks like Java or Python, then you are the lucky one, because that's what they use mainly. But if you are focused on .NET stack (like me), then this is a real switch for you.
But does it make sense to switch?
I will just describe my own experience. I'm a developer and I have gone through such thoughts many times already.
I have been focusing on .NET technology stack since 2003 (my whole career). And this is not just using it, this is learning it, many times, from many different angles. After I have mastered it, I can simply say that I could do anything using this technology stack. That includes skills that I need to do the job, or to follow my hobbies, such as contributing to open source communities.
It took my entire career to get where I am now. Obviously, part of that time went in other skills as well, which are not called .NET stack specifically, such as design patterns, architecture, OOP/OOD fundamentals, and so on. But I've been reconciling all other skills with .NET knowledge, because I use .NET (and C# as a language) to implement all these concepts I have grasped even in other areas of study (e.g. implementing design patterns with C# language constructs). This contributes to growing in .NET in some new ways, too.
If I switch to another technology stack (for instance Java), then I will need to spend approximately 5 years (based on my rough estimate) to reach the level where I'm at now, skill wise. During those 5 years, I will be focused on learning this new skill set, while I won't be actively practicing .NET skills anymore, so I will be forgetting those. Yes, developers don't have endless powers and they can't do all things together. I will have to be good at something and not so good at other things - especially those which I don't use.
Maybe it's not a very bad idea then - 5 years and I am again where I was. But wait, while I was getting back to where I was, I didn't go any further than where I was. If I don't switch, I think I can grow further. And I really do - I read something every day, I challenge myself every day. It's adding up to my skills and knowledge, rather than replacing it. Switching between stacks means to replace, rather than to add to it.
So, as a developer, if you grow on daily basis like I do, I think it does not make sense to switch.
Companies somehow think differently. Let's touch that part too.
I often interview engineering candidates for various roles, around the technology stack that I use (either .NET or JavaScript focused). Sometimes I find candidates that don't have much experience with .NET, but they want to become .NET engineers. At the same time, they have many years of experience in other stacks.
If I'm looking for a senior engineer, will I pick them? You can think I'm not very open minded, but my answer is No.
Reason is very simple - how can I expect an engineer to be productive from day one (typical expectation for "senior") if he or she has not used this technology seriously yet? We could invest in training and growth, indeed. But that does not fit with the definition of "senior".
So, question is, am I looking for the engineer who needs to perform from day one, or can we afford waiting while the candidate ramps up?
Also, why are we discussing this if we can find an experienced .NET engineer instead? If the choice is between an experienced and non-experienced engineer, which one should we pick? No brainer.
Obviously, if we were looking for junior or entry level engineers, that completely changes the matter, but that's not the case here.
Having said that, I think those companies who don't care about your experience with their technology stack, they don't really care how productive you can be. Do you want to be part of such company? I don't. Probably that's why I have not managed to build good relations with Amazon, Google, and Indeed recruiters. Yes, these are good names, and that makes my case very bad-looking to some. But why don't they care about who I am and what I'm passionate about? Why should I switch and not them?
Back to the point - while these companies set candidates for immediate stress and failure at their new jobs, they also don't take max out of the situation. They are the ones who need to keep these people at their desks. I would not want such employees (at least not at senior levels), but they do.
That's a very strange recruitment policy, to say the least. Clearly does not make sense.
If you are still curious why they do this - probably because they can't find enough professionals focused on their stacks, so they are ready to invest in converting a person from one stack to another. Nice business model. I'm more surprised that people are ready to be part of this experiment.
I was thinking the other day - who is right, me or them? These giant companies are tricking me into switching stacks, while I insist to keep doing what I am good at doing. This is an endless fight of thoughts, back and forth...
But does it make sense to think about switch from a problem statement standpoint? Let's define the problem.
We build software systems. There are certain expectations for these software systems. Those expectations are user stories, use cases, acceptance criteria, etc. These artifacts don't ever mention technology stacks, and there's a reason for that. Because it does not matter.
Yes, it does not matter, and that's the main reason that every developer should stick to what they love to do. Because whatever we need to do, our technology stack can do that.
Using .NET stack, I can build all kinds of software - command line tools, desktop apps, web, background services, interaction with databases (either relational or non-relational). I can't think of anything that I cannot do without switching the technology stack. If you can do anything with what you already know, why would you want to do it using something else, which does the exact same thing? Why not instead become better at what you already know?
That's the main reason why I don't want to switch. That's why it does not make much sense for any other engineer, too.
Yet, there are some situations which could make the switch more acceptable or tempting. Let's look at them, reluctantly...
If you feel that by switching you are not losing your time: i.e. If you feel that you are not growing anymore, then switching may even be interesting to try. But if you are still growing, keep doing so. That means it's still early.
If you want to put the shining Google or Amazon label in your resume: They don't use much of .NET stack (not yet). Some engineers will do anything for the shining resume. If you are among them, no judgment, just switch.
Money. Yes, many of us are motivated by compensation and there is nothing to be ashamed of. It pays our bills, and we do everything to be worth it. Senior engineers who agree to switch are highly paid, because there is a strong interest from certain companies in finding such professionals. If you are offered to switch, and you value the opportunity to make more by switching, then go ahead and do what's best for you.
If you are just starting. Oh yes, I am a .NET engineer, but I have said it many times: If I were starting right now, I would go with Java. That's because I clearly see a strong and growing demand for Java stack. If I don't switch it does not mean that I can't see. I wish there was just a single stack and everything would be so much simpler (not a bad idea for another day). I hope this gives me back the status of an "open minded" person, in case I lost it earlier.
I already said that I am a loyal .NET engineer and software architect. Besides building systems using this amazing stack, I also provide a training course for the engineers with the same focus. If I can help you in any way, don't ever hesitate to reach out.
The author of the above content is Tengiz Tutisani.
If you agree with the provided thoughts and want to learn more, here are a couple of suggestions: