Also, almost certainly, you don't want to hire engineers after they end up working at one of the tech giants, and the more experienced they are the worse. Having had the unfortunate experience of working along side some of the 'veterans' of one of these tech giants, it was a little disconcerting how easily they would form cliques based on perceived 'proven vs unproven' folks - if you hadn't worked at one of the tech giants, naturally you were unproven.
There were also tangible side effects. You couldn't generally expect them to work on what they perceived to be work which is low profile but actually important for some unquantifiable metric such as morale of the customer support team. You couldn't generally expect them to play by the same rules when it came to check in policies, documentation standards etc.
But best of all, the actual code they wrote would uniformly fall on either end of the astronaut architecture spectrum - either completely ignoring maintainability and turning the entire team into Schlemiel the painter, or being so convoluted that they themselves couldn't make quick progress a few years down the line on the code that they wrote.
The cliques are not the fault of the engineers from Big Co - it is the fault of your management who perceives them as "proven" and you as "unproven".
This is a self-perpetuating thing too, when most of the promotions go to people from the "proven" cliques, and those who got promoted, promote more of their "proven" brethren.
If you noticed this problem at your company "from below", your upper management completely failed to notice it, and it's their fault for not noticing the strain and for letting people behave lazily and arrogantly in the first place.
Good managers would reeducate or remove the veterans on a case by case basis, ensuring everybody follows the rules and collaborates productively.
There were also tangible side effects. You couldn't generally expect them to work on what they perceived to be work which is low profile but actually important for some unquantifiable metric such as morale of the customer support team. You couldn't generally expect them to play by the same rules when it came to check in policies, documentation standards etc.
But best of all, the actual code they wrote would uniformly fall on either end of the astronaut architecture spectrum - either completely ignoring maintainability and turning the entire team into Schlemiel the painter, or being so convoluted that they themselves couldn't make quick progress a few years down the line on the code that they wrote.