I'd argue that for almost any companies except for the big 10 or so, that's the correct approach. Especially for enterprise software. And even in those big 10, for projects which are not directly tied to the things they do at scale (I doubt the Hangouts Android client needs to reinvent the wheel...), it's still the right approach.

I'm kind of sick and tired of companies writing their own frameworks and languages when they can't really maintain them, long term. Google, Facebook, Apple, Microsoft can, because they have a different culture and primarily because they have a different focus as well as enough profits to support it. Random Java big-shop can't. Their framework will be nice and shiny the first year and 15 years later you'll be wondering why you're working with the atrocious Struts-1 inspired undocumented internal framework.

> I doubt the Hangouts Android client needs to reinvent the wheel...

This actually touches on an interesting point. My notorious interview company is Google. I'm not familiar enough with the Hangouts Android client to tell you anything about it, but for the sake of argument let's unrealistically assume it's trivial. Imagine you have an organization where some engineers are good enough to work on the Hangouts Android client but not good enough to work on, say, the F1 distributed database.

Internal transfers become crapshoots. Is this person good enough to work on my new, highly complex project? Should I reinterview them to make sure they can hack it? Imagine what this does to the social and cultural stratification. "Oh, those Hangouts guys are nice but they're not that impressive, it's not like they're working on the machine learning or anything." It'd be a nightmare both practically for management and socially for the engineers.

Our philosophy is: all engineers should have the chops to quickly be able to ramp up on whatever project they like. This means rejecting a lot of people, but it also means that two engineers can look at one another across the hallway and immediately know they could swap teams and not miss more than a couple weeks of productivity. When framed this way, I think the interview process is a natural consequence.

Not sure what the culture is at other places, but I hope this is a useful data point.

The only way this actually works is because Google is sitting on a pile of cash, in my opinion.

But regarding your problem, you could solve that by having internal interviews.

And I really doubt that for any complex product people switching will only miss a few weeks of productivity.