This article highlights one of the things that really bugs me about tech hiring. The availability of developers who know a language or tech isn't a limiting factor if you're willing to hire people and give them the time to learn. Yes, it's expensive, but if there really are productivity benefits from using a particular tool then you should end up better off in the long term anyway. The expectation that another compan…
Then, you have the tooling that are completely different. Where it would normally take me 5 min to jump into Xcode to profile an application, inspect for leaks or other performance issues, I spent a few hours going through Android documentation learning how to do the same thing.
Last, and this one is a bit nuanced and sort of hard to explain. As a senior engineer, you're typically expected to help mentor others and maintain the foundations of your product so that as new people join they have a template to work from. If you're switching to something so different, you could end up hurting the team (or company) by using the wrong patterns and promoting incompatible ideas. People need to trust you and if you break that trust at the beginning of your employment, it'll be really hard to earn it back.
No regrets though, and I'm grateful to my employer for giving me the space to make the shift. However, I do not believe in the idea you can hire someone at a generalist level and then expect them to be productive anytime soon.
There is a saying, "Jack of All Trades, Master of None," and although very cynical, it's just an honest statement when it comes to these things. Hire the right person for the role you need filled first, then if you want to make room for engineers who are looking for big career changes, make sure your product and team won't suffer for that and you have the right culture in place to encourage that kind of growth.