Honestly I think the better example would be from a tiny company that can't afford to do things wrong.
If you read what the majority of them recommend, its similar to the banker's path in the early 2000s. Graduate from Ivy League, spent 3 years at FANG, then 2 years at Ivy League MBA, then back to FANG or join a startup for a few years so you can get a title bump when you do go back to FANG. The type of people that join Google nowadays aren't the type of people that were early employees. They have a very standard charted course to their careers.
Google has reach maturity stage of the company. They have leeway to screw up like what Microsoft did with Windows and Office in the early 2000s. Will they have the ability to push out something completely new and amazing like Gmail or Google Maps (although Maps was a clone of Mapquest, they executed better), where the end users aren't developers themselves? I highly doubt it with an organization as big. There will be a lot of politics involved to get anything done. They have lost the talent to innovate.
What's stopping you?
I haven't found a problem where I have any insight on how to solve
What Google seems to do really well is building robust systems at a scale that pushes the limits of what humanity is capable of. If you collect anecdotes from engineers who've worked on scaling systems at the small number of companies at this scale, there seems to be general agreement that Google is "the best". My understanding from these anecdotes is that Google core services are "on fire" less than everywhere else and require less maintenance.
But that's a pretty narrow definition of software engineering. AWS, by all accounts, is much better at productizing something useful to the world. I've heard that the reason Microsoft lags Google in stability could plausibly be accounted for by the fact that they care so much more about maintaining backwards compatibility (which Google very clearly does not care about).
All that said, I don't think its "best at software engineering" is a terribly useful category, better to say they are plausibly "best at a very specific and very difficult kind of software engineering".
Whether core services are "on fire" depends on which team you're on. Some core services are pretty much "on fire" all the time, with high pager loads for the SRE teams supporting them. Some core services are rock solid, and the SRE teams conduct exercises where they turn the service off just to remind people that the uptime SLO is not 100%.
Same goes for code quality. Some teams have code that you'd just love to print out and put the code listings on your desk. Some teams have code that doesn't make sense and nobody understands.
Some teams are highly functional, some teams are exceptionally dysfunctional.
Can you give some examples of things Google did which pushed the limits of what humanity was capable of?
Or, how about a video distribution network that serves more than 600,000 hours of video every minute, and manages to do that such that, every time service deteriorates on my 4G connection in a poor country, it's the last website (even considering text only websites) to stop working?
As for YouTube, it was bought, not created by Google, wasn't it?
As for youtube, serving video is not the impressive part. It's the scale at which they do it. And my understanding is that the scale has increased exponentially since the 2006 acquisition.
Depends what you mean by "better at software engineering".
Conversely, simply having more market share doesn't mean AWS services are well engineered and the engineers are smarter (they might be, but you cannot make this claim).
There're different ways to measure "smart". My view is that in the cloud computing business there are people smarter than them (at least in terms of market share) so it's perfectly fine that Google Cloud engineers learn from their competitors in terms of engineering, marketing, etc.
What could have been... [1] Yes, I'm still bitter about it after all those years.
My impression is that this is a result of a policy that google3 never touches a developer machine, which of course means you can't disconnect and work from a log cabin in the woods. Really sounds like bending yourself around an antipattern to be honest.
This is becoming an increasingly remote (hah) scenario where doing development over web-based IDEs and SSH becomes a problem. For the incredibly few people who do this sort of thing regularly, you could get satellite internet reimbursed. There is even a story of a SRE who used to work from the top of mountains on occasion because he hiked so much.
I wouldn't call them "evolving" anything software as of late. Their hard science departments seem good though, but these aren't software engineering
There are a lot of projects that look easy at a POC stage and are very different at million of users, millions of tps, millions of TB or full featured
Spanner seems a prototypical Google dev product though; it's only invented to serve Google. I don't think any of their solutions is the de facto choice in any tech stack.
It was invented to serve Google (really: the people who had outgrown bigtable's limited featureset) but is widely applicable.
80% of software engineering is not about pushing but maintaining. I'm not the one who praises Google (far from that), but using "pushing anything relevant" as a metric is not correct imho.
I understand there are many reasons for this (though some of those originate with Google itself), but that's rather the point. The whole reason Google became a thing is because most search engines 20 years ago were full of results that were "hyper-monetized, full of spam, and frequently just not especially great." Then Google came and offered a product that effectively solved this, and quickly became a giant because of it.
Maintaining, let alone evolving, means continuing to work at least as well in the face of changing conditions.