Ex-Google engineer here. The way Google does things is indeed very rare, your experience at Microsoft is more typical.

Note that the path Google chose isn't easy! As the codebase got larger and larger they had to basically design and build their own build system, a distributed unit testing engine, custom code refactoring and hyperlinking tools, do major IDE modifications to Eclipse to make projects even loadable, eventually even build their own version control system because no other VCS scaled to the sizes and speeds they needed. They invested a TON of time and gold into allowing a single codebase to scale like that; it's practical if you're sitting on a hosepipe of money and you can hire brilliant engineers then assign them to build tools, but it's probably not practical for most companies despite that the resulting environment was quite pleasant.

That said, although the codebase was remarkably consistent, there were still variations. The most notorious was the split between the C++ and Java codebase. Some frameworks were written in c++ and bound into Java using things like SWIG. Others were bound using cross-process RPCs. A lot of smaller libraries were simply written and maintained twice. The culture was different too. Some Java codebases were way over the top of excessive abstraction and use of dependency injection, making them an absolute nightmare to understand or debug for newcomers. Others were simpler and more understandable (typically the older ones). The C++ side felt much more light weight, but on the other hand, it was largely stuck in the 90s, with memory management being entirely manual even in cases where conservative GC could probably have helped avoid mistakes. When I left C++11 was in the process of being whitelisted one feature at a time.

The biggest problem with the culture I had at the time I left (and was one reason I decided to pack my bags after 7.5 years there), was that basic tasks were becoming more and more bureaucratic. Often this was due to poorly designed processes put in place in a panic after some PR disaster around privacy or data handling, like Street View or Buzz. Sometimes it was just because some engineer needed to redesign a widely used system in order to prove they were being "impactful" and get promoted even though it wasn't really broken. There was a running joke there that there were two versions of every tool, the deprecated one and the one that didn't work yet. It started out as a lighthearted take on the companies rapid progress and by the end unfortunately just reflected a sad reality.

As an illustrative example, around the time I started to step back, one member of my team had spent on the order of 6-8 weeks attempting to simply download a file via HTTP in production, from our own servers (was a self test). This task involved filling out forms, arguing with the owners of the HTTP download service (the old one didn't require this process but was deprecated), discovering that the new version was hopelessly buggy and was breaking random products for end users without anyone on those teams noticing, etc. This is a task that could be accomplished in two minutes with a random Linux VPS and "wget" but turned into an epic struggle against a Kafkaesque corporate disaster zone. The problem was not that one team was poorly performing though: the problem was the company had lost the ability to pre-emptively catch this or even recognise that there was a problem. Most team members were happy to just collect a paycheque each day; if they got paid for filling out forms justifying why they needed the "fast reliable" HTTP download service instead of the "slow unreliable" service, why worry? Best not to rock the boat.