Google is the world's most used company by the number of users between products like Google search, YouTube, Chrome, Android, and many more. But what's the company like from an engineering point of view? We've spent months researching this topic to bring you the most detailed deep dive to date on Google's engineering culture.

We go into Google's unique tech stack and why every tool is custom at the company. How Google works, roles, compensation, performance reviews, on-call and internal mobility. How Google changed over the decades and advice on how to thrive at the Google of today as a software engineer and many more topics. If you ever wanted to work at Google as an engineer or manager or want to understand how one of the world's most innovative tech companies operates, this episode is for you.

Hi, I'm Gerge, your podcast host and author of The Pragmatic Engineer.

Hi, I'm Alen and you may or may not know me as the researcher of the pragmatic engineer. You might have seen my byline in some of our deep dives and survey articles. And today we're going to try out this new format to bring you a deep dive by talking you through everything Google.

So, I was an intern at Google for a couple months back in 2015. I was based in the London office. I worked as a UX intern actually. That was before I worked as an engineer after that. So I have a little bit of like inside vibes but not that much.

Let's start with everyone knows Google for sure. You cannot not know it but what are some interesting stats we found about them?

The numbers if we're going to go there, it is easy to forget how big Google is sometimes. So the latest numbers there's 182,000 employees across all of Alphabet. But obviously the majority of that is in Google. We have numbers from 2020 that there were about 50,000 engineers and that's up. So in 2015, which was the first time they came out with a lot of the numbers about the engineering work, there were 25,000 engineers.

I think size-wise this makes them similar to Microsoft in total employee count for engineers. A bit unclear. Maybe Google has more maybe Microsoft. Probably similar to Amazon, but Amazon has weird numbers cuz they kind of mesh the workers, but they're a lot bigger than Meta, for example. They're like I think two, three times bigger. So they're easily one of the biggest kind of top tech companies in the world, if not the biggest. The question is with Microsoft, but I think when it come to prestige, compensation, they're easily number one in this regards.

Scale of work that people work on. And speaking of scale, Microsoft might have similar number of employees, but when it comes to Google, I think numbers are a bit unclear, but around 3 to 4 billion people per month use their services between search, Gmail, YouTube. I mean all of these are marketing services right. I think search is more than 1 billion people per day which is kind of one like every I think nine person in the world uses search. YouTube has 2.5 billion monthly which is more than TV viewers and then Gmail has 1.8 billion active users and I'm pretty sure looking at my newsletter about 60-70% of emails are Gmail.

Yeah, for sure. I've seen the same stats and if you broaden out the Google Workspace apps like including Drive and Docs and Calendar and stuff, they have over three billion users and over 50% market share. They're so far ahead of Microsoft and Office essentially. With YouTube as well. I can't help, I'm a big YouTube user and have been for a long time and I'm always so fascinated by their general stats. Like there's 5 billion videos on YouTube. Not all of them are necessarily up and available. The latest numbers, 360 hours of content is uploaded every single minute.

Yeah, that's a lot of parallel processing.

There's 2.6 million videos uploaded every day. Almost a billion a year and a billion hours of video is consumed every day.

Yeah, those are just large numbers. And I think this is the thing with Google, right? Technically it's not even called Google. Technically, it's Alphabet, which the biggest part is Google that still owns things that like Chrome, the leading web browser, Android, which is still the leading smartphone platform globally by a lot by about 70%. In the US, iOS is now getting bigger. So, that can be a bit misleading. But then there's things like self-driving. If it's self-driving it's the only the commercial leading one is Waymo which is not part of Google but part of Alphabet.

In terms of the footprint, yeah Google's big. Just globally as well they have 72 offices in over 50 countries or 50 countries so they have offices all around the globe US Europe Asia Sydney Brazil.

Yeah but what we care mostly about is engineering so they're engineering offices there's about more than 25 ones, but the kind of the big ones that we should definitely mention, headquarters, Mountain View in Silicon Valley.

The Google Plex.

The Google Plex. Yeah. Really cool office. Like really cool kind of perks. Android figures. It was so cool. I was there last year. Addy Osmani took me around on the Chrome team. New York office also big one. Seattle and they have a lot of offices in smaller ones in the US. LA, Pittsburgh, Boulder, a lot of like specialized ones.

Cambridge and Massachusetts is pretty big as well. Yeah, the Seattle office is definitely one of the bigger one. And you might hear it referred to as Kirkland as well because Kirkland is the suburb of Seattle where it is and it's, yeah, lots of cloud is based there.

Yeah. And then Europe and the UK have large offices. The biggest one known in Europe is Zurich. It's actually probably Google's European HQ in terms of engineering if you will. And a fun fact is that Zurich pays almost as much in compensation as in the US which is really really interesting. A lot higher than their other European offices. London is another huge office. Dublin a big one. Dublin I think might be bigger than Zurich in terms of people but not necessarily engineering.

Ah, like they have a lot of sales. Yeah. Yeah. Makes sense. Makes sense.

Yeah, there's actually one here. I'm based in Stockholm. So, they have an office here as well that's grown a fair bit. It's like a few hundred people. Fairly big on the engineering side. work a lot on video meets and calls and stuff.

And a lot of US tech companies would stop here but Google obviously being Google they have engineering offices a lot of other places. Bangalore and Hyderabad are two massive offices in India.

They've grown so much as well. They're and growing. Like those are like a lot of the open positions are based in India.

Yeah we had an issue with that when I used to work at Uber as an engineering manager. We were hiring in Bangalore and what we found is we had trouble hiring senior engineers because whenever we'd extend an offer and that person was interviewing at Google, Google would offer 10% more than whatever we did. Always 10% more. So after a while back, this was back several years ago, but the team kind of backed down and they started to hire like less experienced engineer. This was a big kind of hiring fight.

But there is this thing about Google, by the way. If you have a competing offer, Google and they want you and then you're like senior and above, Google almost always will offer more. They don't care too much about their internal bands. Again, over time, this might have changed and for more junior positions, this could have changed. But I had a director of friend who was in the situation between having a competing offer at Meta and Google and it was really high already and then Google just really wanted this person and they just offered more. Google like when you become in demand this is a really interesting situation but it's kind of an open secret on the job market.

And then they have offices Tokyo, Japan, Sydney, Australia and probably every kind of major city and you'll have like so Google has so many offices right and engineering can pop up anywhere.

Yeah, exactly. They have a pretty big one in Brazil as well in São Paulo. They have a lot of search engineers. But it's also it's funny because one of the stats for Google is like they've always had such good revenue. So like back in 2024 there was $350 billion in revenue. 75% of that comes from ads. And I think Google like they've done good for themselves because they figured out such a good revenue model from day one for themselves. So they've always been able to offer all of these high salaries and pay for so much stuff.

I'm going to challenge you a little bit because I so like we know like Google is insanely profitable, right? Like there is no doubt about it. However, when we look a little bit closer at the unit economics and we're going to quickly move to engineering, but let's talk about the kind of where the money comes from. Google's like profit margin of like you know on $100, how many dollars is profit is around like 30 or 35%. So like $30 or $35 are pure profit and they're not the most profitable company. Companies like Visa or Mastercard and Adyen they do about 60% profit rate but those companies don't pay as much as Google does for their engineers.

So there's this interesting thing where there have been companies earlier who have found out similarly really lucrative really good business models again like with Mastercard you know you make a transaction they take a percentage they built out the global network boom profit but they don't compensate engineers or they don't kind of treat engineers the way Google does which we're going to talk a lot about. So, I think Google did something interesting where like by the end of this episode, we're going to have a better idea of what actually happened. But there's two things, right? Either they created this new thing where they became so profitable because they treated engineers so well. Or despite being so profitable, they're treating engineers really well and maybe they're becoming even more profitable and now a lot bigger than Mastercard or Visa or other companies.

Now one interesting thing that I wanted to bring up is when you joined Google there was this note from a founder who got acquired by Google called Treyas Banzal. A 10-person startup got acquired several years ago and on a blog post this is what he wrote. He wrote "working at Google is like having a second passport. Go to any major city in the world and your badge unlocks a beautiful office with great food, great desk and a high-speed link to every person in Google's 200,000 person network. And it's like visiting America as a foreigner. Everything you see inside feels oddly familiar because of its massive export influence yet is just slightly different." I thought this is fascinating. So like when you join Google you have suddenly access to all the offices. You can go into any of the offices. I mean travel budgets permitting. I understand they now have some of those but yeah you have access to this and to all of the people. I think this is something that a lot of people don't realize from the outside of just how it is one company but it's also more.

Yeah, that actually resonates quite a lot with my brief experience there as well. Again, we'll get into this but yeah, I think Google is so special especially if you compare it to the other big tech companies because like in many ways there's no one Google. It's not one company working on one thing. From very early on they worked on so many different things. So like you can reminisce my memories of Google is like it feels more like you can talk to other Googlers and it feels like they would be at like working at a completely different company but you're in this like alternate reality bubble where when you're in the bubble you know so many things that you can only talk about with other Googlers which yeah are like so it's more like they're in the same alternate universe bubble as you rather than at the same company as you. And yeah, the badge is really the passport to that really. It's a really fascinating place to be.

So Google has the most unique tech stack in the world and we're going to go into a lot more detail, but they have custom-built everything. So unlike almost every other startup or company that has some level of standard tech stack that the rest of the industry uses, Google just uses their own stuff and it works really well for them, which has an interesting outcome.

They also influence if not even kind of indirectly created how hiring is done today with these LeetCode style interviews. They started with the algorithmical interviews and they kind of I guess the perception of how Google having a hiring bar made it go mainstream across the tech industry and then they also invented roles like the SRE role which is now kind of pretty widespread across other companies as well.

Yeah, exactly. Even though it might be called something slightly different with like you know DevOps, reliability engineering etc etc. One thing that is very unique about Google is how many internal tools that they've built. Borg, blaze, piper, critique, code search. We'll talk about a lot of them today.

Yeah, we're going to get to them. In many ways, Google was one of the first modern software companies and how we think about them today. Not just all the perks that they provide, but building best-in-class internal tools. They also pioneered something that we take for granted today. Great data tools for product and engineering teams. Google was one of the first companies to take analytics, dashboards, AB testing, feature controls, all of them together seriously. They built advanced tools and made it available to their thousands of engineers and data scientists. This was the approach that enabled a fast-moving bottoms up approach to product development.

And this practice of having your engineering teams have access to these tools really did become the baseline for standout tech companies. For the last 15 years, pretty much every major tech company has had entire teams of people rebuilding this kind of feature flagging AB testing stack of tools internally.

But now something interesting is happening with the latest generation of tech giants. Rather than building these tools, companies like OpenAI, Anthropic, Figma, Notion, and a bunch of others, they're just using Statsig. Statsig has rebuilt this entire suite of data tools that was available at maybe 10 or 15 giants in a such a powerful way until now. They built experimentation with proper statistical analysis, feature flags for save deployments, session replace analytics, and more. All backed by a single set of product data.

So one thing that is like so unique about Google is they have completely custom internal infrastructure even today and there's a reason for this because when they started back then they needed to build this knowing how the existing tools didn't work for their scale. So maybe let's talk through some of the unique tool set that someone would see if they start to work inside Google or if they're working there, they see them.

Yeah, exactly. And I think actually it's like why this tech stack looks the way it does is very like it's because it was search. It's like well this needs to be global from day one. So we need to have this infrastructure from day one to get the speed and reliability that we want. And so that's why they just jumped straight ahead with like we'll just build custom stuff from the ground up. So yeah, like they scaled into six digits of machines in the early 2000s.

So like hundreds of thousands of machines.

Yeah. In their data centers. Yeah. There was a pragmatic engineer post from an SRE a couple months ago I want to say where he talks about he started at Google doing SRE in 2004 I think it was and already when he started there were hundreds of thousands of machines and this was during a time when large data centers had hundreds or maybe thousands of machines.

Yeah. This is Dave O'Connor and he was telling me that I think in Ireland they visited a data center cuz they wanted to see how they worked and they wanted to see if they could use them and in the end they figured out they couldn't but they asked like okay how do you manage your your machines and they were like oh we just do manual updates and they're like how many machines do you have and I think they had like maybe a thousand or so and they just did manually and then they were telling them like well that wouldn't really work for us cuz we're planning to have at least 10,000 machines but maybe 30 soon. And they were like what are you guys talking about? Because of this, the most advanced solutions in the case of data centers they didn't have the ambitions that Google had and that's why like even in the early days they knew like okay we cannot do what everyone else is doing we need to figure out build new automation build new tools.

And that's actually how they invented the site reliability engineer role they actually needed software engineers who now became experts at like operating infrastructure which was unheard of. Because until then you had the IT guys who knew how to configure, you know, Windows machines or Linux machines and knew how to patch them, how to plug in, how to, you know, make sure like do all these things, but they were not software engineers cuz why would you hire a software engineer to do that? So like Google did a bunch of these things and that's where obviously one of their biggest internal tools which we mentioned Borg comes from, which is an orchestration system and Kubernetes was inspired by this. In fact, Google created Kubernetes based on lessons learned from Borg and they released it in open source and internally they still use Borg.

Yeah, exactly. So, Borg is basically it's a cluster operating system.

And then you know do you know what Google's kind of internal version of Datadog is called? Borgmon. Oh, yeah. There's also one called Monarch. I'm not sure which one is which, but yeah. So, they have this monitoring which is like integrated into Borg. And this is one of the reasons by the way Google people are like oh why doesn't Google just move to Kubernetes and well I mean then they would need to replace some of these things. Oh and then they have this thing called Third Eye which is their which is pretty much what Sentry is from the outside world and that's also nicely integrated into all of these systems. It's kind of like got all the hooks got all the APIs.

Yeah. Like all of the tech stack is custom. Like there's nothing that's not custom in the Google tech stack. So, Borg, they call it a cluster operating system and it's yeah like one of the first things they built is like realizing okay we need huge data centers we need so many more machines than anyone's ever had. What do we need in order to operate this in a way that is automated and not manual because that's not going to scale. The Google data centers are and always were built kind of like from the ground up by Google and designed in ways that would fit their scale. Like because it was like planet scale search from the get-go, they never had to think about, you know, like, oh, what's the data center for like the smallest need because their need was so huge from the get-go.

Well, and there was this interesting thing, right, where until Google, the way to operate servers was to buy these really expensive Sun racks, the kind of like, you know, like mainframes pretty much, super powerful machines. And Google also had this innovation where they started to just use plain old PCs initially literally just took simple PCs that they put together on like the main frame, the CPU, the hard drive, and they just put it together and put it in data center. And people were like, "What? That's so silly." But they're like, "Look, we're getting a lot better value for a buck instead of a $2,000 machine. We can have 20 $100 machines and we can have throughput of three times." And then they started to take this a bit more seriously and started to manufacture their own servers, which cannot be bought by anyone, but that's how their internal data centers are built. Google Cloud these days is built like that as well, but Google's own infrastructure is probably bigger than Google Cloud, interesting enough. But as you just said, they built a larger scale compute than anyone needed at the time.

Yeah. Exactly. And like with their ambitions and knowing how big they wanted to be and the kind of support they wanted to provide, it's like well this is what we need to do. I think maybe also because of the SRE approach to building out all of this stuff and because that was so anchored in software, they did a thing quite early on where they decided to rather than going for like let's build the perfect machines that will never fail, they realized like at our scale, they're going to fail anyway. So yeah, let's just go with the cheap stuff that's easy to replace and just build amazing tooling on top of it that makes it nice and easy for us to operate on.

So like yeah, today it's obviously like cloud computing is it's the status quo. It's what everyone's doing. But at the time again like they did this in 2003 2004 this was unheard of and probably anyone who heard of it was like what are you doing? Why are you why would you do that?

Well, Jeff Bezos might have heard of it because he was an investor and you know, like AWS later launched their public cloud, but it was unheard of. I think this goes back to like Google was seen very kind of weird a little bit or like almost mythical for how they hired cuz like the way most tech companies would hire at the time is they would ask you programming questions of like I don't know they hired a Java programmer they would ask you all right how does you know the memory allocation work in Java or stuff like that or like if you know they would ask about design patterns or stuff like that and Google like would ask brain teasers they would famously ask like okay how many golf balls can you fit in a van or something like that and apparently the reason they did this initially and they stopped doing it after like several years but they wanted people who can think outside the box because they knew that they didn't want to do what everyone else was doing they didn't want to copy what Yahoo was doing or what MySpace or any they wanted to get the people who rejected you know the conventional thinking and they were still smart and brain teasers were seen as a way to do this. They stopped this several years later because once this kind of went mainstream, you know, people started to optimize for it and it turned out that they also rejected people who were smart but they were just not good at brain teasers.

Most companies hire for the programming language that they were using made up maybe that was like cold fusion back in the day or like again Java or Python or whatever. And Google to this day doesn't care about what language you're using. They just want you to use and write code with in a coding exercise oftentimes you can use any language or sometimes you use code if it's an algorithmical interview. This was one of the reasons they love algorithmical interviews. No specific language required.

Yeah. And I guess that makes sense as well because the Google tech stack is so unique. It doesn't like it won't matter anyway. like they need you to have open horizons simply flexible and solve problems because you're going to solve them differently at Google anyway.

Going back and speaking of just how custom it is, the fact that like when they built out these data centers, they also like they couldn't use or didn't want to use opted away from using normal like networking stacks and switchboards and stuff. They built that from scale as well. Yeah. Why?

Uh so they have something called B4 which is like the backbone networking infrastructure that has ridiculous bandwidth and that's the thing that their like they built out so that their data centers and the ridiculous scale of of the machines could talk to each other and uh that Borg was able to coordinate uh you know job allocations. They also chose not to do DNS the standard way because uh they developed something called Borg naming service. So the BNS um and that's because obviously like at that point and very often you will you know have a specific IP address and specific ports.

Yeah.

Um but Borg from the get-go was very like well anything can run anywhere. So they wanted a level high of abstraction higher than that. What Borg does is that they allocate resources for like jobs and memory and CPUs like across machines. So the actual IP address to the machines like it has to happen fluidly because they don't allocate specific machines. It's broader than that. It's more like cluster level and a cluster is like racks of machines.

Mhm. So they they needed that that abstraction. They need a next level outside of like you know what's a rack, what's a cluster, that kind of stuff.

Exactly. Because it's like well we have so many machines that it doesn't matter and the machines again like because they were especially in the beginning kind of like cheap and easy. It's like we don't like a machine will fail. We don't care. We'll like another machine will come in and take over. And similarly they built out the Google file system back in 2003 or well they talked about it in 2003 um which was also necessary because of that. So like a huge decentralized uh file system like in 2003 they had hundreds of terabytes of storage across thousands of discs and machines accessible by hundreds of clients.

It had this like basically a storage stack where you had discs like actual physical hard drives and then an abstraction called D above that for a disk but like the disc could be either a disk or something else. Uh and then you had the like the Google file system on top of that which was later preceded by Colossus which is what they use now. And then on top of that they built out all of these like database like services. So things like big table, like spanner, like there's not just like the one database because it depends obviously on the uses of the database like what are you optimizing for? And so internally they have lots of different variables and like kind of database systems as well where they will have some of their data centers are like more specifically for you know better for certain type of data storage and certain types of database you know big table is more nosql it's sparse it's distributed it's persistent spanner you have a more SQL like interface case it's more important for like real consistency across the world.

Yeah. So I guess the trade-offs are like is it like write intensive, is it read intensive, what kind of data are you storing, like how structured does it need to be, how are you wanting to access it, right? So these are all the differences between the reasons they they have and then like as you said the distribution like do you just want it on one machine and if it dies totally fine or you want guaranteed that it's distributed then do you want consistency that immediately as soon as you write is there but then there's a latency or then you want to minimize that or you don't care if it's eventually consistent and then you can write. So like there's a good question of like why does Google have so many databases and I guess this go back to like why are there so many databases? There's so many databases like we just did on the pragmatic engineer survey. There were so many like 50 plus or or even more that people use and they're all like built by like actually experienced teams. That that's kind of an interesting interesting side question. Why so many databases?

Yeah, like databases optimize for different things and so there's different use cases for them. But one of the things with Google from again fairly early on, Google branched out and like they didn't just focus on the one search product, you know, they built out Gmail which was basically email with built-in spam filters was like the pitch from early on as well as a gigabyte of storage which was also unheard of at the time. Uh and then they branched out into you know Google calendar, Google Docs. Um they did some really big and smart acquisitions like YouTube, uh Android, you know, they they had the in tech infrastructure that they had. Um and then they started getting all of these new use cases, uh basically companies operating on top of this stack. And so they were able like had the needs, had the expertise and had the data centers and the infrastructure to build out all of these different offerings for their own products.

And then outside of just infrastructure, like Google has so many other custom systems. I'll just name a few cuz I think like it's we could take forever in going into them, but instead of instead of GitHub, you know, for source control, they use Piper, something called Piper. That's their version control system. Instead of pull requests they have this thing called CL change list. Their code review tools called critique and it's integrated with so many other tools that they have a lot of AI function now built into it. It's a little bit like GitHub's pull request review.

Code search has been a very kind of famous tool that inspires source graph so you can search all of Google's repositories and again they do have a monorepo but they have incredible amounts of code and it's rapid. It's again it's from a search company you wouldn't expect anything less but apparently for a long time when I talk with source graph founders they were saying that code search was they had parts that were better than source graph's own offering. I think now source graph is catching up but I still remember when I first used source graph at Uber and it was just so fast and I was like wow this is so cool to use but apparently that's the norm at Google and most companies never had this until you know maybe they tried to build it for themselves but it wouldn't be worth it building for your own.

Yeah. And a lot of that actually comes from the fact that they have this monorepo. So the monorepo, they talked about it publicly first in like 2015. They started publishing numbers on it. Back in 2015, there were already a billion files in the monorepo. Two billion lines of source code. It was 86 terabytes of content with 40,000 commits every single day. It's interesting because one of the reasons why they were able to build the monorepo and operate it the way they did was also because they built it on the Google infrastructure that they already have. So the data centers and networking they built out their build tool blaze.

Blaze which they open source a thing called Bazel which is similar enough which is also really really fast and really good.

Yeah. And it's you know this distributed build system that yeah it's kind of core of how they build. It's very distributed very quickly. It enables the monorepo in the ridiculous scale it's at, but it's also deeply ingrained into how they do the development itself, which is very in the cloud actually. Like most Googlers will not have code locally on their machines and kind of haven't ever. It's kind of a system called clients in the cloud or Citsy which is the way they're programming which is yeah like not on device but you know connect to clients in the cloud. These days it seems like they mostly do that through a tool called Cider which is actually a fork of VS Code.

So, yeah. Again like because everything is custom everything is also so connected. So like Cider is deeply integrated into Critique that they use for code reviews which is deeply integrated to their CI tap test automation program. They have tools like Trycorder which runs tests static analysis all that stuff. They actually speaking of rapid they actually have their release automation tool is called rapid or one of them rather. Code search is integrated into all of that as well and obviously code search is you know like they had to build that out because the monorepo was so huge.

Speaking of like working together or how they work like you know when you think of Google's like what they use for project management you know their kind of version of Jira's linear they have buganizer. Again a custom tool and they have this tool called task flow which is a UI on top of buganizer for boards kanban and other kind of management tooling and then they have guts which is Google universal ticketing system it's was more for for tech related tech support when you open like a ticket you know you can think of it like zendesk or like juro tickets or or just any ticketing system but it's so interesting how they even built that for themselves as well.

But it's also it makes sense because I guess when you have the infrastructure so unique it's like well you need to implement this so where does that goes come in and actually I think buganizer in particular is also probably the integration with cider and critique and but like because everything is so custom everything is like made for each other as well. So using buganizer, you know, you can report but also like fix do small fixes like immediately in the same environment that you're already in because it's using the same infrastructure.

Yeah. Now, one interesting thing about Google that I hear is this kind of tech island. I think longtime Google engineer or executive Urs Hölzle might have said this. Google is a tech island like there's the rest of the world which is using you know pretty standardized things like most startups will be using like AWS tooling or for containers it'll be kubernetes or for front-end frameworks with like react or and for database it'll be postgress or something that is out there but for Google everything is separate.

And there was this recognition even inside Google that this could be a problem that they're so unique that they cannot take advantage of other open-source projects for example developing but also it's a very expensive to on board it's just for new joiners you know they have to throw away every knowledge and at some point it might also be maybe just not as tempting to go work at Google if you know that whatever you use there it's not going to be useful for your next job but I don't think this has changed I think Google is like nah you know like they probably talked a little bit about it but and maybe it cannot even change that much because it didn't start because Google it didn't feel doesn't feel to me that it started because Google said like no we need to do something different.

Yeah. I think it's more like we've been talking about like they kind of had to do something different from the get-go. And I think when you end up in a situation where basically you've invented your entire own kind of internet or like way of communicating across computers like from the ground up and you build out stuff on top of that like yeah I don't know even know if it's possible for them to move over and that's actually so when they started GCP the Google cloud platform you know a lot of that is what they refer to as externalizing. So they're externalizing. They're not open sourcing because it's still like they're on their own tech stack, but they are externalizing. So making offers that, you know, can be used by other companies. So Kubernetes is the externalized version of Borg and it's not the same, but it's, you know, heavily inspired by it. Like slightly different architecture, slightly different feature set because it doesn't have to cater to to just Google. And the same for you know big table spanner yeah basically everything in the in the Google cloud platform.

And actually also to mention gRPC which is a way of communicating across services that is something that is also externalized. Internally it's called stubby and that is the way that they communicate across services and it's yeah it's the internalized gRPC they use protobuff as like the messages for how to communicate across services and then gRPC is the way they do that.

Yeah. All all this internal tooling I think like for a feedback I often hear from people going to Google is how they're just really surprised at how it is. And of course people who've been there for long enough they gotten used to it when they go outside they're often really kind of taken aback by how little other companies have it. For example, if you spend most of your career at Google and move to any other company, like often Googlers will look for the equivalent of like whatever Google tool had at this company which might or might not exist.

But there was this person NeetCode as his name is Namadiv Singh who well he creates one of the most popular coding solutions. He worked at Google for I think about a year and he said he did a video about the one of the worst things about Google and he said how it's too many internal tools and what he said is I'm quoting him. "Google has this problem that they have an internal tool for literally everything. So and sometimes all those internal tools don't have massive teams supporting them. Sometimes it's just one guy working on an internal tool trying to get promoted that maybe they get promoted and then they stop maintaining that tool and now you're used to forced to use it and then nobody knows how to fix a bug. You have to go and read the code and you have to fix it yourselves and that's not fun. No one enjoys that." And then he said "I would rather not have this internal tool in the first place because at least I can just solve the problem from scratch but now that is there I need to use this internal tool." So I think it can get out of hand and sounds like a Google sometimes gets out of hand.

And he was specifically saying his problem is not with the big tools like Borg that are really well-maintained really well written but there's it's just everywhere. So it's and because of this as I understand you know Google has so many migrations going on all the time especially you know promotions come into play which we're going to talk about shortly.

So let's talk about how Google works. Now the first thing I kind of think about like when I you know people think like oh what do you know about Google even as engineers it's it's about the perks right like they're they're just so known for for the perks especially if you visit a friend at Google I mean it's the thing that stands out right I think the the micro kitchens.

Yeah I mean the Google offices in general are I mean I've been to other big tech offices as well and like I mean the the kind of playfulness and quirkiness is definitely not unique to Google, but it's also unique to Google. If you have the chance to go visit a Google office, especially one of the bigger ones, do it. It's a fun time.

Yeah, they people can bring in visitors. You get like free lunch or breakfast or whatever dinner probably as well. And I mean, the decor is unique like you know like I've been to many offices, right? Like obviously what worked at Uber but went to Meta, Spotify, etc. like and they all have like cool decor at places, but Google is everywhere. Like the thing that reminds me the most of of Google is the old Facebook office back in Menlo Park back when it was like still very very like heavily invested. There was like such cool cool things. That was the only thing that came close and I'm pretty sure they kind of modeled it partially after Google to wanting to hire, you know, like similar people. But yeah, like really unique decor every office like I think in Amsterdam there's a van in the middle of the office which is a meeting room which apparently people don't use because it's too hot but it looks really cool and and that's just one of the many decors.

Yeah. And and those are very they're quirky. They're location based. They're kind of theme based. So yeah, the micro kitchens, a micro kitchen is basically like a space in the office where you can get free snacks and coffee and tea and and just like often just like a nice little like chill break room where you can socialize and hang out with people. Yeah, there's just so much personality to them. In the Zurich office, they have one with a one of those like secret bookcase doors. So, like you'll be in this micro kitchen that looks like a library basically with these huge bookcases and one of them opens up to like a secret room in the back.

When I was in the London office back in 2015, they had you know the London phone boxes. They had tons of those across the offices whereas like you know you can go in and like do a quick call or like a oneperson meeting room. They had London buses, you know, just a London bus just in the office that you could go in and hang out in. They're really fun, very colorful. I mean, Google has always been colorful given that they chose like the bold colors in the logo from early on.

And then like I think the perk the list of perks is really long. I mean it keeps changing per location but there'll be like you know from the usual kind of in the US the 401k matching which is kind of a given but still generous from like all sorts of allowances that you can spend on like a lot of like typically you can expense a bunch of things the travel that you can travel usually don't need a budget. I mean it's changing over time and again this is what I mean by by location. And then there used to be like more historic perks that I don't think exists, but there used to be like on-site massages where you can get like like you know like like masseuse would come in and like you could just get it in the office which was very famous in the like 2000s or so to like the napping pots to some of these things. But these keep changing.

But I think one thing that hasn't changed is which is kind of like the biggest perk of all is the compensation package which is just like wow. Like you know there's this trimodal model of of like the local companies that compete locally and companies that like try to pay the top of the local market and companies that pay the top of the regional market that's a top tier. Google is a very top tier company which means that they can pay anywhere from two to four times the compensation so the total compensation that other similar companies would pay let's say for a senior software engineer.

And like what this means in terms of numbers is in Silicon Valley of California, a senior software engineer could make around $450,000 to $500,000 per year in total compensation, which means, and this is where it gets interesting, there's a base salary, there's a stock that vests per year that you can sell because it's liquid stock, and then there's a cash bonus. And then this will be something for a senior software engineer in the US like $220,000 in California base salary maybe $200,000 per year in stock and maybe $35,000 in target bonus and these last two they can change based on your performance you could get more you could get less. But for London this whole total compensation package which is not all salary so salary is only one part of it it will be for senior software engineer will be something like 200 to 250,000 pounds. In Munich, it will be somewhere to €190 to €220,000 and in Zurich it will be 300 to €330,000 which is like a big jump again differences in taxes and areas and again for every other location in India and in Sydney etc they will just typically pay more than anyone can offer.

In many ways, Google feels like this amazing like you get everything. You get to work on the largest scale things with smart people, these amazing perks, and you've been paid a bunch because a company that does pay you pretty well, not this well, but they pay you pretty well is Amazon. They give you a very respectable total compensation with pretty good stock and cash and all that, but then you get nothing. Like there's no perks. There's no nothing. They're like, you know, you want to go out for a team dinner, pay for yourself. Whereas at Google, like this is not even a question. Like, you know, like there will be team events and of course you're not going to pay for it.

And speaking of good care, so like one thing that really kind of struck me as really really unique is on call. Almost every company is like let's be real like engineers are paid really well at Google and similarly well at Amazon, Meta, Microsoft at all the other companies you are expected to when you're on a team you share the on call on your team. Now, in the case of Google, on call is not nearly as enforced or as stressful as at every other company. At every other company, you join like a six person team. You'll probably have a rotation of of every six weeks. It might be a bad rotation. It might be a good rotation. If it's a bad rotation, well, I mean, you know, your nights will be disrupted. Sorry. Until your team gets this stuff together.

So, Google has a few things. First of all, they have an SRE organization which works really hard to make on call less painful for teams. They build tooling that helps with this. They monitor the load of the teams and they have this thing called toil SLOs, toil service level objectives where they want to make sure that that teams whose SLOs are breached, they stop production work and fix the underlying issues. So they basically provide time for teams to become healthy again and you know not get woken up all the time at night by systems that break which happens a lot actually at some of these other places that again have high expectations similar to Google.

And then another interesting thing that Google has this thing called on call tiers. So at most companies even at big tech every team just makes sure their systems are up. Google assigns tiers to their services. Tier one means that a page that comes it needs to be acknowledged in 5 minutes, tier 2 in 30 minutes and tier three is best effort. So you can imagine tier three is internal services, tier one is important services, but then they pay for the on call accordingly. So they say if your team owns a tier one service and you're on call, you get 66% of your normal salary. They do a bunch of composite they pay really well for being on call and then they limit time spent on call at the same time. You cannot go for on call for more than two weeks per quarter which is going to less than other companies. So it just like it it like mind-blown like Google all does all these things. They pay engineers like best in the industry or close to best in the industry. They give all these perks and then they relieve them from on call. So it's almost like it's it's amazing to be and then not just relieve but they actively help and mandate teams to make their systems better. So this is like paradise for an engineer.

If you work at Google, you'll likely be an SWE, the software engineer. That's the big role that Google has. Um but Google also has tons of like there are a lot of other types of roles and niche roles as well. Like SRE is obviously one of the bigger niche ones that they have. Uh but there's also quite a lot of other smaller ladders that and and roles that they have depending on you know like some roles are more prevalent in some parts of the organization and with some products or product areas.

So you'll have stuff like DevRel, they have UX engineers which are kind of like more front-end engineers working more with design implementation and that there's like a scale there that goes from more like front-end engineer to prototyper which is a separate career ladder. They have research scientists, they have within the SRE there's also like more specific type of roles and working with the infrastructure. They have tons of other roles, but the big one and the most on paper apparently all of these different ladders are supposed to have, you know, like same compensation, same prestige, same everything. But it seems like in reality the SWE role is good, kind of a bit like higher class essentially. Uh, and part of that is because when you're in SWE, like because it's kind of the default go-to role, that's the one where you have the most internal mobility, you can work on like any team, you like it's much easier to like move somewhere else because that's the default that engineering managers will look for and hire for.

And speaking of managers, they have engineering managers that are, you know, EM, they take care of teams. That's their primary focus is making sure that the team is healthy. Uh they also have two roles that is the tech lead role and then the tech lead management role.

Tech lead manager.

Which is unique to Google where uh so it's basically you can think of them as like a spectrum where you have EM on one side where it's you know the person like you know they have direct reports they take care of the team they do all the EM things and then on the other side they you have an IC individual contributor who's a tech lead. So tech leads are in charge of you know overall architecture tech aspects of projects of products they'll make sure that you know like tech decisions get made they have the top say they get appointed by EM but then there's this slide in scale in between where you can have tech leads who also have direct reports and here we talk about tech lead managers.

Yeah but so my understanding of this role because We introduced it at Uber and it was influenced by Google. I think we had a Google SVP come over and then it was introduced. My understanding of the idea of this role originally was well first let's talk about levels. The levels start from L3 which is entry level software engineer. L4 is mid-level software engineer and Google has different names for it, but that's kind of what it is. L5 is senior software engineer, L6 is staff. L7 senior staff and L8 principal. Uh L9 distinguished and L10 partner or fellow, yes, Google calls it fellow.

And around like at the senior software engineer at the staff engineer level at L6 another path starts which is the manager path. L7 will be senior engineering manager which is the same as the senior staff. L8 is director which is now principal engineer so the same level the same compensation and it goes to L9 senior director, L10 VP and then there's an L11 on the manager track for senior VP which does not exist on on the IC track.

Around like L6, people need to decide are they going to be on the IC ladder, try to make their way to L7, L8, and so on, or switch to manager ladder. But at some point, you kind of like get stuck, but maybe not necessarily an uncomfortable way. So like when people get to like L7 or L8, you're not really going to go higher. And at Google there are people with really long tenures like 10 years 20 years even more and they're very comfortable there. And so you have these individual contributors who are really good at their work. They're the tech lead de facto and they could manage their team that small team like and typically these are small projects but they don't really want to be on the manager ladder cuz they want to stay IC's and they don't really want to be promoted. So this tech lead manager role is kind of created for those people.

And this is really important context because some other companies took over this role. And what they found is people who went into this thought that they would be promoted to the next level. But it's really hard to be promoted when you're kind of expected to both be an as an engineer you're not doing as much work as before a little bit less and as a manager you're managing a team. So people can get frustrated but for Google it worked as I understand. So the tech lead managers are typically they're not like looking to go to that next level. It's just more recognizing that hey, they're doing both of these pieces of work. When you're judging their performance, don't compare an L8 tech lead manager to an L8 IC who will be pushing out a lot more code.

But I think this leads into nicely into the performance reviews and promotions at Google. The performance process it used to be called Perf and it used to be kind of you know one of those things that is like people famously complain about. But they actually did a big rehaul in I think 2022 where they moved to a new system called Grad, which stands for Google review and development.

If you ever worked at a big tech company, it's a pretty similar performance review process. People will need to fill in, as I understand, their self-reviews. You get peer reviews. Managers look at it. They give you feedback. And there's a timeline for this. So Google runs once a year. It starts in November and the bonus numbers will be managers look through it in December. There's bonus meetings behind the scenes. In January, they get finalized and then they get paid out in March.

Yeah. And I think one of the differences like I think the Perf process was like way more heavy on you as an individual doing all the heavy lifting where you had to spend yourself a lot of time putting together reports and like paper trails essentially about all the things that you do. And with grad supposedly it's been pushed more to the managers I believe which if you have a good manager is probably an amazing thing because you know you'll have a lot less work. But if you end up with a Yeah. like it it'll depend on your manager it seems like.

Yeah. And so Google used to be known and I think they still kind of are. They're trying to be pretty fair in how they do performance reviews and promotions and we'll see that with promotions. I mean, the manager still has a big say, but they're trying to focus on outcomes, outputs, etc. Like they're doing more there's a lot of training for managers going on anti-bias training all of these things and the process is really well documented and it is more heavyweight than most big tech companies and people take it seriously. But there is this interesting thing called the Perf score resetting when you change teams.

Oh, yeah. As I understand, this is kind of a open secret that if you change teams during a perf season, so basically like right after the perf season has on your first perf season on your team, you will always get meets expectations no matter if you're how much you're overdoing it. I mean, if you're doing terrible work, you might get below, but you're typically not going to do terrible work, but you will not get exceeds no matter how hard you work. So this is leading to like some pretty strategic considerations on when to change teams because getting an exceeds rating means you're going to get higher bonus but you know that when you're changing teams it's going to be meets you're going to get your target bonus no matter what.

Outside of performance reviews the other one is promotions. That's and promotions are different at Google because there is this thing called a promotion committee. So, my understanding is that Google has been really big about trying to not be biased in promotions, the way promotions work at most companies is when you're up for promotion, the group of your manager and your manager's peers all get together and they're like, "All right, is you know, Johnny ready for a promotion?" And they all kind of talk about why, you know, and your manager says why they think they are. And then their peers say like, "Yeah, we agree or we don't or what about Jane?" And so on. And so this group who's kind of, you know, like kind of know your work, they all like decide collectively in the end or they get feedback why you're ready, why you're not ready. And the good thing about this is that they all know the context of your work roughly. The bad thing is it can be pretty biased.

And what Google has done for a long time is they said all right let's just make this whole process unbiased let's have a promotion committee where no one knows you like it's not your managers but it's like this group of like senior or staff plus engineers and other engineering managers at a different part of the org and they just get a written packet a little bit like their hiring committee that we're going to talk about they decide your promotion based on that and what this means they don't know anything about you they don't know who you are. I mean they will understand the context But they haven't to work with you. They have no bias for or against you. And so the decision should be a lot more like objective, right? So they will decide on your impact on they will look at the framework that's there and the impact.

There is a very interesting kind of downside of this promotion committee. There's a famous article called why I quit Google to work for myself by Michael Lynch who was an L4 software engineer at Google for four years and he was stuck on that level for four straight years trying to get promoted for years one after the other and he wrote this blog post and he failed every single time. First promotion he submitted his he was doing a bunch of maintenance work and then the promotion committee said that he had not proved that he could handle technical complexity and they didn't see the impact again Google's big on impact.

So he now looked for a project to get to promotion and he got that project but then the project got cancelled and then the next year I think he moved teams or he had to move teams because his team got cancelled and so he had this like series of bad lucks where and then in year four he wrote in this article I'm quoting him "my quality bar for code drop from 'will we be able to maintain this thing for the next 5 years' to 'can this last until I'm promoted'. I didn't file or fix any bugs unless they risk my project launched. I wriggled out of all responsibilities for maintenance. I stopped volunteer for campus recruiting events. I went from conducting one or two interviews per week to zero because he just really wanted to get that freaking promotion." And in the end, he quit Google.

But this whole story showed how it's super easy to fall into Google into the promotion trap, which is I need this project to get me promoted and that's it. And he actually explained and in the end I think he said like what am I doing here? Like why am I doing this? And this is where we should talk a little bit about promotion-driven development that is very real inside Google because all the incentives are there for it. And you know there's this joke that goes around of why Google has so many chat products. They keep changing the names and also the product. Google's payments promotion it was Google wallet then G pay then Google pay then it's now Google wallet again. You see sometimes a lot of things where Google has a product like with their chat product which is still not they don't have a Slack competitor. You can get promoted for having a successful launch for showing traction.

A lot of projects at Google, you know, like people start a new project, they get traction, they get promoted, and there's this thing where if you move teams, your performance scores are reset. You will definitely meet a meets. So if you hit a bit of an obstacle, the launch goes up, but now it kind of flatlines. I mean, you can stay on that team and get a meet's review, or you could move to a new team and get a meets review anyway. So often teams will move to a new team and either start a new project or join in. There's just not much incentive to stick around on a project that's not doing great for even a year to kind of hang it out and get it back to growth. There's just more incentive to start a new one because you're not going to get promoted for maintenance. That's the gist of it. And you know this goes back to Google has this thing called killed by Google a website that collects these like 300ish Google products that have been launched but they have been killed.

One interesting thing that comes up with Google... it's not really software engineering but it kind of impacts us. OKRs, objective key results. Now if you're a software engineer you probably like and you worked at a midsize or larger company this probably came up like what are your OKRs? What are your teams OKRs? The objectives the key results and the goals and apparently Google made this super popular this framework right?

Yeah exactly. So technically they didn't invent it. They were actually introduced in the 70s at Intel which is so long ago but there's this guy John Doerr who was at Intel before he joined Google kind of early and in 99 he introduced this idea of OKRs and they fit really well with Google at the time and it became a big part of and ingrained in the culture of how they operated. So yeah like objectives and key results. Objectives is like you know a kind of more high-level goal of like this is what we want to build and then the key results are specific measurable things that you can measure in order to know that you're moving towards the goal.

I'm always a little bit suspicious about OKRs and Google because the book Measure What Matters was published in 2018 and from there on it's really blown up and I think everyone's like using OKRs cuz there's this narrative that OKRs make Google successful. But I'm kind of thinking like is this a little bit saying that I don't know like using Jira made whatever company successful, SpaceX successful. I'm not sure they've used Jira, but like whatever ticketing system they use, did that make them successful? Cuz I have a sense Google would have been successful whatever they use because you know like it started with page rank. They did something that everyone wanted. And I wonder if if OKRs is something that I mean it's probably it works, but it could have been anything else.

Speaking of OKRs as a tool for communication, communication in general at Google is and at least has been very open and very transparent. So historically, like this has changed a little bit now. We'll get into this, but like culture is shifting across the industry, including Google in late years, but historically it's been incredibly open and transparent. Since pretty early days Google used to have or still has them these weekly companywide town hall all hands meeting check-in type thing. It's called TGIF. So, thank Google it's Friday. And then with the company being global so it's actually it's on Fridays in one time zone but not in the other. So it's more like TGIT now so thank Google it's Thursday.

Yeah. But basically, it used to be more like Sergey and Larry on stage talking about stuff, doing open Q&As. You'd have different teams come in and like present what they're working on or what they've built. And I think it's one of those kind of cultural cornerstones it seems where like I remember when I was interning you know it was on Fridays and like there's the all hands itself that's TGIT or TGIF but then you know there would be an event at the office where you know there would be free food and drinks and sometimes some like event. You'd just like have this weekly chance to like go hang out with your colleagues before going home from work that like you'd learn all these things from across a company.

One of the things again like we're doing this research from the outside looking in, right? Like we're able to get to the stuff we can get to and we've talked to people. And one of the things that has come up is definitely like the culture is shifting. Like there's the winds of change in Google following you know partially just like the vibes of the industry as a whole but partially very much internally also during the pandemic you know they had some big leaks so like they stopped some internal transparency in the all hands and the full access to like everything going on. I know that's been restricted.

Yeah. So, so let's talk a bit more about this because I feel this is like the Google of today. Basically, we've kind of arrived from like where Google started, how they built like all these cool things to what is Google like today from all that we've gathered and I guess maybe we should just like reflect a little bit on how the whole as you said the whole industry has gone through a massive change. First there was a pandemic... and then it turned out to be a blessing for tech because everyone started to hire like crazy. And in 2022, just as lockdowns ended and the world recovered, tech started to crash down. There was like mass layoffs across companies.

This went up all the way to 2023. Big tech had big layoffs and Google had the first ever layoffs in almost the first in company history. In 2008, they did like a 3% layoff because of the financial crisis. But since then, they haven't really had any layoffs. And Google used to be known as the place with like great job security, work life balance, almost impossible to get fired if you do a minimum good enough job. And then they did like 6% layoffs just cutting people with like including people with 10, 15, 20 years of experience just sending an email to them at night. And I think this really changed the mood at Google.

And then in 2024 they there were some more layoffs coming in not as many as before but it's now seems like that kind of period of Google was perfect in so many ways. perks, money, work life balance, clubs, investing in everything. Like it was just impossible to hire away from Google pretty much. Now there's a bit of a sense of there is some level of being cutthroat. Not as much as their competitors like Meta or Amazon where it's a lot more tougher, but still it's like, you know, it's a company. At some point, you might get fired and you'll get a good severance, but they'll tell you that it's game over.

So, so let's talk about who do you think would be a good fit at Google? Like who are people who could get a lot of out of it in today's Google? Like not the ideal Google, but the one that we know today who could get a bunch of value out of working there. And when could be a good time assuming you manage to get in because I think we should be clear getting in is is super hard.

There are some of the things that we've been sort of talking about the whole episode. Like if you're really super into the specific tech stacks and trying new tools and playing around with new frameworks the second they get out, you know, Google is not for you. Basically, you're not going to be able to use or reuse any of your like tried-and-true favorite things because you're going to be working at with completely different things at Google.

So, you're basically saying like if you're interested in the frameworks in the industry that startups use that that you build up the knowledge that I don't know like the latest React framework or latest ML framework that is out there that makes you in demand for other places. Right.

Exactly. So if you like keeping up with the industry like keeping up with the tech industry's cutting edge as opposed to internal Google cutting edge that no one knows except for Google but then you might not be able to talk about it because of the NDA. Another part like if you're someone who like who is not into reorgs or like things changing all the time like the googly thing of being into ambiguity like if you like things being somewhat like stable and yeah then Google is probably not for you either.

And then on the flip side of that, I think if you if you do like trying new things and innovating and trying things out, like I think Google is good for that as well. You know, like you mentioned, they did, you know, 20% time was way more of an established thing in the past. They didn't completely get rid of it. They have some like incubator type teams at Google still. They have one thing called area 120 you know they build completely new very like startup-based completely new apps that very quickly like often just transition straight into the killed by Google graveyard. But you know they'll probably like they will reuse some of this technology as well. So like there is a like killed by Google is definitely true but it's not like all of it's wasted. So like if you're into innovation and trying new things Google can be for you but it's not it's probably also not going to look the way that you imagine it to look like and if you get in love with your idea and you know the whole I kill your darlings thing. If you're not good at killing your darlings then probably just do startups instead of Google.

Yeah. Well, one thing I'll add is Google is very very good for one thing which is the pedigree. So if you have if you worked at Google for let's say you know sometime even a year it's one of the most recognized brands even to date. Part of it is the bar of getting in is just very high. So my suggestion would be is if there's a reach out from a company like Google, it can be a challenge to just go through the interview process even if you have no intention because their interview process is very very similar to the interview process of the companies that are hardest to get into.

And then there's this other interesting thing. If you look at where the hottest startups of today hire from, you know, may this be open AI, Anthropic as I mentioned, Stripe, so many of them will be from Google. Google has a lot of people who are underutilized, but they're very smart and very capable. And then there's a network. If you're someone who is curious or talks with other people inside Google, you can build up a really good network. Having it behind your back, it can strengthen your resume and your opportunities for like a decade or even more to come.

Yep. And Google has this interesting thing called team matching which is for software engineering positions typically they don't interview for a specific team but they interview in general. And once they decide like all right you're good you meet our bar. Then a team needs to claim you. So you need to kind of go through a team matching process which can be really frustrating by the way. The recruiter might tell you like congratulations we want to hire you and you're like great where can I like how much is the compensation how are I signing like we just need to go through team matching and sometimes this team matching can take months and sometimes it comes back with I'm sorry no teams were available or wanted your profile in this case so that's the other thing it is it's kind of harder to get into than most places.

I hope that we were able to share some details cuz this environment really is not for a lot of people. And you do need to put up with a lot of things that come with large companies. And in this case, a one that is very transparent, which means there's a lot of information overload as well.

Oh, yeah. I think if you're not good at like multitasking or if it stresses you out to like have to go to meeting middle of the day while coding, you'll probably hate this place probably.

Interestingly, Google is one of the very few tech companies who are very innovative. They come up with so many new products even today like an AI that they're leading. They're a frontier lab. But they're also a company where a lot of people retire from. So, this is the company where it's not unusual to see people with 20 plus years of having worked there. And when you look closer, it'll be different teams. They will switch teams every now and then. But it is one of the places together with maybe Microsoft to some extent Amazon where like I do see people probably in larger amounts or larger percentages just stay there and clearly decide either that they're very happy there or that they're the happiest they can be compared to other options and they do it all the way to retirement and because Google pays as well as it does. Retirement doesn't necessarily come at the around 65 or whatever the legally mandated is. A lot of people will say I'm retired earlier because I have saved off enough together with with Google's perks and pension program and whatever that I will now have a very comfortable life.

And one thing that I would just close with is everything that we might have said or covered about how things generically work. It might be absolutely false for for one for that specific team that you might be working in or that your friend is working in. So don't forget like I think personal relationships really do matter. And what I have seen reasons people go to Google for example or leave Google might be their manager. So you know people come and go between companies like Google, Meta, big tech, startups and scaleups and there are some things that can be generalized but yeah don't forget if you meet interesting and valuable people just you know keep in touch with them because they might end up in interesting places that might or might not be like these.

Yeah, it's been a lot of fun, a lot of information, but uh yeah, hopefully we'll do this again with uh other topics in the future.

Yeah, let us know your feedback and hopefully we'll see you in the next one. This was our Google podcast episode. If you'd like to get even more details about Google's engine culture, check out our deep dive article in the pragmatic engineer newsletter linked in the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and see you in the next.