B (3:44)

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

A (4:29)

Yeah, that's a lot of parallel processing.

B (4:31)

There's 2,6 million videos uploaded every day. Almost a billion a year. And a billion hours of video is consumed every day.

A (4:41)

Yeah, those are just large numbers and I think like, you know 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 U.S. iOS is now getting bigger, so that can be a bit misleading. But then there's things like self driving, you know 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. And in terms of the footprint, yeah.

B (5:22)

Google's big like 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.

A (5:36)

Yeah, but what we care mostly about is engineering. So their engineering offices there's about like there's more than 25 ones, but the kind of the, the big ones that we should definitely mention. Headquarters, Mountain View and Silicon Valley.

B (5:49)

The Googleplex.

A (5:50)

The Googleplex, yeah. Really cool office, like really cool kind of perks. Android figures. It was so cool I was there last year. Adi Osmani took me around on the Chrome team in 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.

B (6:13)

Cambridge in 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.

A (6:32)

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.

B (6:56)

Dublin I think might be bigger than Zurich in terms of people, but not necessarily engineering. They have a lot of sales.

A (7:04)

Yeah, makes sense. Oh you're right. I actually used to have friends non technical who were in Dublin. Yeah, you're right, you're probably big. But I was thinking engineering.

B (7:15)

Yeah, engineering. Zurich is the biggest hub for sure.

A (7:18)

Munich is a big one for engineering as well. In Germany they have a Berlin one. I understand that it's a bit smaller. And then Paris is a research office as I understand there's a bunch of smaller ones. The thing with Google is they do have some smaller bits. For example, even in Budapest, Hungary they had a very small engineering office. I think they still have, but it's tiny compared to all these other ones.

B (7:38)

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 meet and calls and stuff.

A (7:53)

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.

B (8:04)

They've grown so much as well. And growing. Those are like. A lot of the open positions are based in India.

A (8:14)

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 engineers. This was a big kind of hiring fight. But there's 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 bans. Again, over time this might have changed. And for more junior positions, this could have changed. But I had a director 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. So 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.

B (9:37)

Yeah, exactly. They. They have a pretty big one in Brazil as well, in Sao 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, 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.

A (10:17)

I'm going to challenge you a little bit because we know Google is insanely profitable. Right? There is no doubt about it. However, when we look a little bit closer at the unit economics and, you know, 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 a hundred dollars, how many dollars of profit is around like 30 or 35%. So like, you know, $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 or 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, 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, they don't kind of treat engineers the way Google does, which we're going to talk a lot about. So, 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, 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, or Visa or other companies. Now one interesting thing that I wanted to bring up is, is when you joined Google there was this note from a founder who got acquired by Google called Shreyas Banzal. A 10% 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 you badge your badge unlocks. Beautiful office with great food, great desk and a high speed link to every person in Google's 200,000 person network. And, and it's like visiting America as a foreigner. Everything you see inside feels oddly familiar because of its massive export influence, yet it's 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 the just how it's, it is one company but it's also more.

B (12:40)

Yeah, that actually resonates quite a lot with my experience, 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 like there's no one Google, like it's not one company working on one thing. From very early on they worked on so many different things so like can reminisce. My memories of Google is like, 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, 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, or 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.

A (13:46)

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, Google just uses their own stuff and it works really well for them, which has an interesting outcome.

B (14:06)

Yeah, we'll get into a lot more detail.

A (14:09)

They also influence, if not even kind of indirectly created how hiring is done today with these lead code 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.

B (14:31)

Yeah, exactly. Even though it might be called something slightly different with like you know, DevOps, reliability, engineering, et cetera, et cetera. 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.

A (14:50)

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 of approach to product development.

B (15:20)

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 a b testing stack of tools internally.

A (15:39)

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 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.

B (16:07)

And one really nice thing about statsig, it's. It's not just about saving engineering time, it's about getting world class infrastructure from day one without having to build it yourself. Rather than arguing about metrics, definition or troubleshooting broken tools, engineering teams can just on focus, focus on building a really great product.

A (16:24)

The other thing is scale. Since statstik already processes trillions of events per day, which is enormous data by the way. They also scale with you. Plus you can integrate statsic into your existing product data easily as well. If you're interested in giving your product team an access to an incredible data tools, go to statsig.com pragmatic they have a generous free tier a $50,000 starter program, affordable enterprise plans. Just tell them the pragmatic engineer sent you. 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 tools tool set that someone will see if they start to work inside Google or if they're working there. They see them.

B (17:18)

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.

A (17:53)

So like hundreds of thousands of machines.

B (17:55)

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.

A (18:23)

Yeah, yeah. This is Dave o' Connor and he was telling me that I think in Ireland they visited a data center because 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, but they asked like, okay, how do you manage 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 because we're applying to have at least 10,000 machines, but maybe 30 soon. And they were like, what are you guys talking about? Like, that's so because of this, like the kind of 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 reliably engineer role. They actually needed software engineers who now became experts at operating infrastructure, which was unheard of because until then you had the IT guys who knew how to configure 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 because why would you hire a software engineer to do, to do that? So like Google did a bunch of these things and, and that's where obviously one of the biggest internal tools which we mentioned, Borg, comes from, which is Orchestration System. And, 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.

B (19:59)

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

A (20:04)

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 a, so they have this monitoring which is like integrated into Borg. And this is one of the reasons, by the way, people are like, oh, why doesn't Google just move to Kubernetes? And, and well, I mean then they would need to replace some of these things. Oh, and then they have this thing called thirdeye, 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.

B (20:39)

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, oh, what's the data center for the smallest need. Because their need was so huge from the get go.

A (21:30)

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 mainframes, pretty much super powerful machines. And Google also had this innovation where they started to just use plain old PCs initially just took simple PCs that they put together on like the mainframe, 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 bug. 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 just to your point, they built a larger scale compute than anyone needed at the time.

B (22:37)

Yeah, exactly. And 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 SRV 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?

A (23:37)

Well, Jeff Bezos might have heard of it because he was an investor and, you know, like AWS later launched their public cloud. But. But yeah, it's. It was. Yeah. And I think it wasn't just, just unheard of it. But 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. Because, like the, 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? Stuff like that. Or like, you know, they would ask about design patterns or stuff like that. And Google, like, would ask brain teasers. They, they would famously, they would ask like, okay, how many golf balls can you fit in? I don't know, like 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. 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, like you're using. They just want you to use and write code with a coding exercise. Oftentimes you can use any language or sometimes you use silo code if it's an algorithmical interview. This was one of the reasons they love algorithm interviews. No language, no specific language required.

B (25:26)

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. They need you to have open horizons and be 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 when they built out these data centers, 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.

A (26:01)

Why?

B (26:02)

So they have something called B4, which is like the backbone networking infrastructure that has ridiculous bandwidth. And that's the thing that they built out so that their data centers and the ridiculous scale of the machines could talk to each other and that Borg was able to coordinate job allocations. They also chose not to do DNS the standard way because they developed something called Borg naming service. So the bns. And that's because obviously at that point, and very often you will have a specific IP address and specific ports. But Borg from the get go was very like, well, anything can run anywhere. So they wanted a level of abstraction higher than that. What Borg does is that they allocate resources for jobs and memory and CPUs across machines. So the actual IP address to the machines, 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.

A (27:19)

So they needed that abstraction, they needed next level outside of like what's a rack, what's a cluster? That kind of stuff.

B (27:25)

Exactly. Because it's like, well, we have so many machines that it doesn't matter. And the machines, again, because they were especially in the beginning, kind of like cheap and easy. A machine will fail, we don't care, 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, which was also necessary because of that. So like a huge decentralized file system. Like in 2003 they had hundreds of terabytes of storage across thousands of disks and machines accessible by hundreds of clients. It had this like basically a storage stack where you had disks like actual physical hard drives and then an abstraction called D above that for disk. But like the disk could be either a disk or something else. And then you had 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 database like services. So things like BigTable like Spanner, there's not just the one database because it depends obviously on the uses of the database, what are you optimizing for. And so internally they have lots of different variables and kind of database systems as well where they will have some of Their data centers are more specifically for, you know, better for certain type of data storage and certain types of database. You know, BigTable is more. No SQL is sparse, it's distributed, it's persistent. Spanner, you have a more SQL like interface. It's more important for like real consistency across the world.

A (29:21)

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 have. And then like as you said, the distribution, like you just want it on one machine and if it dies it's totally fine or you want guaranteed that it's distributed and 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 goes back to like why are there so many databases? There's so many databases like we just did on the Pragmatic Engineer survey. There was so many like 50 plus or even more that people use and they're all like built by like actually experienced teams. That's kind of an interesting side question. Why so many databases?

B (30:20)

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. And then they branched out into Google Calendar, Google Docs. They did some really big and smart acquisitions like YouTube, Android. They had the tech infrastructure that they had and then they started getting all of these new use cases 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. I don't know if this is still happening, but they did actually for a long time at least and possibly still. They also had backups for all of their data centers on physical tape.

A (31:44)

Wow. I mean tape is durable.

B (31:46)

So yeah, there are in the SR ebook which was published in I Want to say 2015 2016, which is available online. You can read it online. They have some amazing stories of some huge outages in 2011 and 2012 from Gmail and the Gmail one in particular. There was a bug and they lost like 0.2% of users logged in. And like there was nothing in their inbox because they lost all their data. And they wrote like an incident report saying like, this is what was going on. And they talked about how they were able to restore the data and they went into what they called gtape, which was their physical tape, and they spent a couple days manually going through the tapes to restore the data to the users.

A (32:37)

There's this article published by Google called 10 Things We Know to be True. It's a set of beliefs that they published when the company was just a few years old. And what surprised me is how many of these are still true today. Did you read this article?

B (32:50)

Yeah. And then the fast is better than slow, which was a defining part of the culture and one of the core tenants for their product, which was search at the time.

A (33:00)

Yeah. And if anything, that obsession with speed, it's become even more critical today given how competitive the market feels.

B (33:07)

Yeah, for sure. Actually, when we worked on the what's in your tech stack survey that we worked on a few months ago, one of the most mentioned words that engineers used when talking about tooling that they dislike was slow.

A (33:19)

Yeah, that was the number one. It's pretty clear that engineers or even teams that are faster than a competition and are quick to make decisions, they use tools that are also fast in how they manage their work. And all of this brings us nicely to our seasoned sponsor, linear. Linear actually dominated the project management responses this survey as a tool that Tech Keys love using. In fact, it was the most loved project management tool. It wasn't even close. From the responses, it was clear that the big part of this was due to how fast LINEAR is to use. Right after we posted a survey result, LINEAR reached out wanting to work together and it was a super easy yes. I've since been Talking with the linear team about how OpenAI and perplexity switched to Linear. And a big reason for these companies to move was how Linear enables velocity in their product workflows. I'll actually link the OpenAI story in the show notes below because it's such an interesting read.

B (34:06)

And yeah, I guess it goes back to a thing that Google understood very early on, that when you focus and prioritize speed in terms of how you operate, every piece of your stack needs.

A (34:17)

To support that totally I'm going to be spending more time with the lunar team over the coming months and I'm excited to share more about the product and the story behind the company. If you're curious to get a feel for the product yourself, head over to Linear App Pragmatic. And then outside of just infrastructure like Google has so many other custom systems, I'll just name a few because I think we could take forever in going into them. But instead of GitHub for source control, they use Piper, something called Piper. That's their version control system. Instead of pull requests, they have this thing called TL change list for their code review tools called Critique. And it's integrated with so many other tools that 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 sourcegraph. 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. Again, as from a search company, you wouldn't expect anything less. But apparently for a long time when I talked with sourcegraph founders, they were saying that code search, 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 sourcegraph at Uber and it was just so fast and I was like, wow, this is so, so cool to use. But apparently that's the norm at Google and most companies never had this until, you know, maybe, maybe they tried to build it for themselves, but it wouldn't be worth it. Building for your own.

B (35:53)

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, 2 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.

A (36:36)

Which they open sourced a thing called Bazel, which is similar enough, which is also really, really fast and really good.

B (36:41)

Yeah, and it's, you know, this distributed build system that, yeah, it's kind of core of how well it's 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 sitc 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 cidr which is actually a fork of VS code.

A (37:35)

Well now it is, right? It used to not be.

B (37:38)

Yeah, it used to be something else.

A (37:39)

It used to be a web based tool.

B (37:41)

Yeah, I used it a little bit when I was interning there and I think back then it felt kind of niche. But then I think that's changed a lot I guess partially since forking VS code. I bet it's looking much nicer than it did when I was there.

A (38:01)

I hear a lot more people are using it. So.

B (38:03)

Yeah, again because everything is custom. Everything is also so connected. So CIDR is deeply integrated into critique that they use for code reviews which is deeply integrated to their CI test automation program. They have tools like Tricorder 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.

A (38:43)

Speaking of like, 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 slash linear, they have Bugganizer again a custom tool and, and they have this tool called Taskflow which is a UI on top of Bugonizer for boards, Kanban and other kind of management tooling. And then they have Guts, which is Google Universal ticketing system. It's more for tech related tech support. When you open like a ticket you can think of it as like Zendesk or like Jira tickets or just any ticketing system. But it's so interesting how they even built that for themselves as well.

B (39:22)

But it's also, it makes sense because I guess when you have the infrastructure so unique it's like oh, we need to implement this, so where does that come in? And actually I think Bugenizer in particular is Also probably the integration with CIDR and critique but because everything is so custom, everything is made for each other as well. So using Bugenizer 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.

A (40:03)

Yeah. Now one interesting thing about Google that I hear is this kind of tech island. I think longtime Google engineer or executive Urs Herze 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 you know, like AWS tooling or for containers it'll be Kubernetes or for front end frameworks like React and like for database it'll be postgres 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 onboard. It's just for new joiners, 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, they probably talked a little bit about it and maybe it cannot even change that much because it didn't start because Google. It doesn't feel to me that it started because Google said like no, we need to do something different.

B (41:21)

Yeah, I think it's more like we've been talking about 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 way of communicating across computers from the ground up and you build out stuff on top of that. Yeah, I don't even know if it's possible for them to move over. And that's actually so when they started gcp, the Google cloud platform, 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's, it doesn't have to cater to, to just Google. And the same for, you know, bigtable Spanner. Yeah, basically everything in the, in the Google Cloud platform. And actually also to mention grpc. 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 the internalized drpc. They use protobuf as the messages for how to communicate across services. And then GRPC is the way they do that.

A (43:06)

Yeah, all this internal tooling, I think like for 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, for the equivalent of like whatever Google Tool had at this company which might or might not exist. But there was this person, neet code, his name is Namindeep 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 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. And sometimes all 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 it 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 promotions come into play, which we're going to talk about shortly. But let me show you this image. When it comes to Google, there's this like two things to choose. There's the main thing that's deprecated, don't even think about it. And the new thing that is under construction. And this is by Manu Cornet who worked there for I think 12 years. And he was saying that, by the way, this is true for a lot of tech companies, but especially Google. 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 micro kitchens.

B (45:45)

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.

A (46:01)

It's unique to Google.

B (46:02)

If, if you have the chance to go visit a Google office, especially one of the bigger ones, do it. It's, it's a fun time.

A (46:09)

Yeah, people can bring in visitors. You get like free lunch or breakfast or, 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 worked at Uber, but went to Meta, Spotify, et cetera. Like, and they all have like cool decor at places, but Google is everywhere. Like the thing that reminds me the most 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, like really unique decor at every office. Like, I think in Amsterdam there's a van in the middle of the, 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 many, one of the many decors.

B (47:03)

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 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 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 bookshelves, 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, the offices where it's like you, you know, you can go in and like do a quick call or like a one person 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 yeah, you can just, you can tell like those little caps with the propellers on the Noogler hats which I did have but it broke and I have lost it somewhere.

A (48:27)

And then like I think the per, the list of perk is really long. I mean it keeps changing per location but they'll be like you know, from the usual kind of in the US the four okay 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, that you can travel. Usually you 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, I don't think exist. But there used to be like on site massages where you can get like, like you know, 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 it 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 tri modal model of like the local companies that, that compete locally and companies that try to pay the top of the local market and companies that pay the top of the regional market. That's the 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 what this means in terms of numbers, is in Silicon Valley of California, a senior software engineer could make around 4,500,000 per year in total compensation. Which means, and this is where like 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 U.S. 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 a senior software engineer will be something like 200 to 250, 50,000 pounds. In Munich it will be somewhere 190 to 220,000 Euros. And in Zurich it will be 300 to 330,000 Euros, which is like a big jump. Again, differences in taxes and areas. And again for every other location in India and in Sydney, etcetera, they will just typically pay more than anyone can offer. So typically the best paying opportunities, they will shoot a little bit above. And in the case that someone pays more and Google really wants you, they will sometimes shoot more and offer you more if they really want. In many ways Google feels like this amazing, like you get everything, you get to work on the largest scale thing 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 there. 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.

B (51:52)

No, exactly. Like they, they take good care of their engineers and have done again like from day one, basically.

A (52:00)

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 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 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'll 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 1 means that a page that comes and needs to be acknowledged in five minutes, tier two 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. Like if you would have been on call for the whole month, which you're not going to be on call, you, you can either choose vacation or pay like 40 minutes of your time for every hour. So anyway they, 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 again a lot less than other companies. So it just like it, it's 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 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. Like so far, like you would almost think that Google is paying us to like advertise them, but they're not.

B (54:54)

No, they make it easy.

A (54:55)

But I guess where's the catch?

B (54:58)

I mean given what we've been talking about though in terms of like Google being this tech island, I guess like this is the positive side of it because you can't actually fix everything yourself because everything is custom. So you can't put the expectation that everyone can go and fix their kubernetes, pots or whatever. This is kind of the trade off. So it's like you get this because you work with the unique tech stack that is not transferable outside of Google.

A (55:25)

And because they invested this much in it.

B (55:28)

Exactly. If you work at Google you'll likely be an SWE software engineer. That's the big role that Google has. 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, but there's also quite a lot of other smaller ladders that and roles that they have depending on, you know, like some roles are more prevalent in some parts of the organization than with some product 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 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 Org there's also 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 same compensation, same prestige, same everything. But it seems like in reality the SWE role suite role is kind of a bit like higher class essentially. And part of that is because when you're in SW 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 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, ems, they take care of teams. That's their primary focus is making sure that the team is healthy. 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 so it's basically you can think of them as like a spectrum where you have ems on one side, where it's the person, they have direct reports, they take care of the team, they do all the EM things. And then on the other side you have an IC individual contributor who's a tech lead. So tech leads are in charge of 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 ems. But then there's this sliding scale in between where you can have tech leads who also have direct reports. And here we talk about tech lead managers, which is this unique to Google.

A (58:25)

Yeah, but so my understanding of this role, because we introduced it at Uber and 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 and then we'll get to why this role is kind of important. So the levels start from L3, which is L3 is the 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, an L8 principal, L9 distinguished and L10 partner. Fellow or fellow.

B (59:12)

Yes, Google fellow.

A (59:13)

Google calls it fellow. I think Microsoft calls it partner. And around like at the senior software engineer and the staff Engineer level at L6 another path starts which is the manager path, which is exactly. Which is where injury manager, there's sometimes an L5 injury manager that's more of an entry level, but I think they'll use it internally. And then L7 will be senior injury manager, which is the same as the kind of 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 the IC track. So at Google we have this level from like IC L3 to L10 and then manager from L6 to L11. And at every level it starts to become harder and harder to go up the path and 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 the manager ladder. But at some point you kind of get stuck, but maybe not necessarily in an uncomfortable way. So when people get to L7 or L8, you know, you're not really going to go higher. And at Google there, there are people with really long tenures, like, you know, 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, 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 because they want to stay ICs 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. So the Duber for example, 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. As an engineer, you're not doing as much work as before or 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 L8IC who will be pushing out a lot more code.

B (61:29)

Yeah, My understanding also is that this role is especially like you kind of mentioned as well in small teams, usually more of the research type things of like, hey, let's try to build something out and see if it works where the team also wants to move a bit more quickly and it might not be around forever. So it doesn't necessarily make sense to both have an EM and a tech lead because it's more kind of grassroots than that. And so then you'll also have these people who will sometimes manage the whole team, but it's like a couple people rather than a full established team that has way more cadence and way more kind of EM type work there.

A (62:19)

Yeah, and I think there's a limit of like four or five maximum reports, so. And usually it's stable teams, usually it's not once. And also if you're on a team of like four or five people, there's going to be not as many promotions and so on. And also fun fact about the level so entry level software engineers start at L3. Those are new grads. And by the way, the whole L thing, as I understand it's to do, there might be L1 and L2 within Google. It's just not for engineering because they're also salary levels as well. PhDs. If you have a PhD, you start at L4 minimum. So there's one. Some other companies do the same thing, by the way, who hire for PhD students. But that was an interesting thing for me to know. At Uber when I was hiring interns, we hired a PhD and then HR told me that that person needs to be at the next level. I was like, okay, sure, like fine. But I guess it's one of the reasons you see like, okay, having a PhD pays off. But again, we ask the same question from the PhDs as we did from, from the new grads. So they still needed to algorithm the coding interview. So there you go.

B (63:18)

Yeah, I do think the like L1 and L2 might be used in like very rare occasions for like kind of interns straight out of university or like they find someone who didn't actually go to university, but like very, very entry level. But like, obviously there's expectations also on like all the low L levels, which is, you know, across the company, our industry, that if you're in a very low L, like you're supposed to kind of progress to a higher level within like X years.

A (63:51)

Well, yeah, so this used to be the case, but it's kind of changed. So like Google has this, had this thing, although they still have it called terminal level. Terminal level used to be L5 senior. And I'm not sure if this was Google, but there used to be an expectation that as you said, in certain years you would get from L3 to L5. Later. Uber copied this and at Uber we had, we had five years of expectation to go from L3 to L5. And in the case of Google, and then if it didn't happen, there will be questions asked and some pressure and eventually they might actually just fire the person saying, hey, like, why did it not grow to what we expected? And once you reach a terminal level, there's no pressure. And what has happened at Google is they've changed the terminal level to L4 because over time it's now to get promoted to L5, you need to like ship, kind of a promote a project that shows that you're ready for senior. And the bigger the company is, sometimes there's not enough projects like that, especially in smaller offices. So it's now like you just need to get to L4. And I'm not sure there's a limit even, but Google has become a lot bigger than before and this happens with every company as they grow. But I think this leads into nicely into the performance reviews and promotions at Google.

B (65:07)

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 Googler, Googler Review and Development.

A (65:29)

If you ever worked at a big tech company, it's a pretty similar performance review process. People 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 like this is Google, it 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. And so basically like for the input that you put in November and December, you're gonna get a final output in February and you will get the bonuses in March. Either you'll be happy or you'll be unhappy.

B (66:10)

Yeah, and I think one of the differences, I think the PERF process was 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.

A (66:50)

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 as 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 after until a few years and I'm sure after a few like after like you know, five, 10 years before, just probably like all right, here we go again. Especially if you're not wanting to move up. And there are performance scores or feedback scores in terms of like, you know, if you're meeting or if you're exceeding if you're above. But there is this interesting thing called the perf score resetting when you change teams. So this is.

B (67:51)

Oh yeah.

A (67:52)

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 per season on your team, you will always get meets 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, 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 meats. You're going to get your target bonus no matter what.

B (68:34)

It was actually with perf that, that they used to use. So yeah, meets expectations, exceeds expectations and then like very much exceeds expectations basically. But actually with grad they've updated the kind of terminology so now they map to impact instead. So you have not enough impact, moderate impact, significant impact which are like the, that's the high end of like meets expectations, exceeds expectations. And then there's also outside outstanding impact which like maybe 8% of people get is what I heard. So like you're doing amazing essentially. There's also transformational impact which is like the top top which is. Yeah, you're going to ship a really big deal project in order to get transformational impact.

A (69:30)

Yeah. And usually behind the scenes these will be tied to budgets. Meaning that at the director level of like, let's say a group of like 100 L5s, only three would have. I'm just saying something, it might be five, but a certain number can get transformational impact. And so on the calibration meeting where all the managers get together and they, they all, you know, submit their ratings, there will be calibration where it needs to not fit the curve, but it needs to fit the buckets. So there, there oftentimes needs to be certain number on the lowest buckets and maximum, a minimum certain number in the lowest buckets of the, you know, the, the ones who do not meet the, the impact and only a certain number in the, in the top buckets. And it depends on how much these are enforced. It depends on the performance season, it depends on the organization. But there's always going to be a distribution, a force. Because what most companies learn, including Google, is if they don't force it, a lot of managers will just like shy away from having the hard conversations or reward, either rewarding their, their, their, their best performers as they should be, or being a bit more critical with the people who are not pulling their weight as much. And this is irrespective of this happens at every large company after a while and even when it doesn't for a few years, it can start happening after a few years. Like we've seen a lot of companies have like absolutely relaxed performance management in 2021, 2022. Like the, the job market was really hot. There was a time where they gave everyone exceeds. I think Google did that once as well to fight attrition. And now it's back to the usual. There is this bucketing and we have a longer deep dive on how calibrations work behind the scenes from the manager's point of view, which is actually really interesting eye opening. But as an engineer, not much you can do beyond document your impact, have a good relationship with your manager and hope that that manager stands up for the people on their team.

B (71:28)

Yeah, and I guess there are some aspects of the type of, you know, work that you do and kind of extracurricular activities, if you will, that will feed into and like look good on these performance reviews. And Google does have a lot of opportunities to do that kind of stuff. So there's lots of mentorship programs and not tech support, but like helping out with onboarding, helping out with, coming up with what they called code labs. So again, because Google is so unique, there has to be a lot of onboarding and kind of knowledge spreading internally to teach people how to work at Google essentially. So that opens up for a lot of opportunities for people to help out with that kind of stuff. If you like working with that kind of stuff, like kind of tech writing and like tech learning. Google has a lot of opportunities for that.

A (72:30)

Yeah, probably a lot more than most other companies. It sounds like they actually appreciate it as well. So I mean obviously you need to do like do, do good work, like don't write sloppy code and like it's full of bugs all the time and then do all the extracurricular things. But when you want to show that you're ready, especially, I guess this is true for, especially the levels like we're talking L3, L4, L5, above that. I Mean, it's kind of given that you do all these things on the side. In fact, they might hold it against you. If you're like an L6 and you're not mentoring anyone, they'll be like. Or you're not helping other things. So it's not going to help you from there because it's kind of baseline from there on.

B (73:05)

Yeah. Actually, that reminds me that one of the things that is built into the critique system and their code review process is something called readability, which is essentially, again, it's a monorepo, so anyone can see and review anyone's code. But the code review process is built up. So every change list, every cl, needs to get reviewed by three different. It can be the same person, but three different roles. One of them is the code owner and it has to be another engineer. You can't review your own code. But then one person also is just someone who needs to have readability in the language you're working in. And so readability. There is someone who knows about all the best practices and conventions and styles and all that kind of stuff. And so they have this way of earning readability in a language that has to. There's a whole process for it.

A (74:09)

Yeah, we talked about it with Irina on the podcast. She was ex Google. So. Yeah, she also went, you have a process, it's pretty straightforward. You need to like, shadow, I think, be signed off. That kind of stuff.

B (74:19)

Yeah, exactly. And like do a certain temper things and then eventually you'll get readability. It's easier to get these types of mentorship, kind of mentorship opportunities through readability across the company without necessarily like moving teams or like knowing people. Like, you have to know the people in that org in order to like.

A (74:41)

That'S a good trick to know about.

B (74:42)

Yeah, you can just like focus on readability. Like just look at OpenCls across the.

A (74:48)

It's so, so unique to Google, isn't it? Like, I. I don't know any other company that does this, like at Uber and other large companies. Like, yeah, like, you do mandate code reviews of like a code owner, but nothing to do with readability.

B (75:00)

Yeah. And I think it could be that that's probably an artifact of the Monorepo again as well. The Monorepo doesn't necessarily, like, they still do a lot of like, microservice architecture for like within the Monorepo. Like, it's not necessarily, like, either it's monolithic or it's microservices. Even if they do have, you know, microservices and like the tech in the teams or different products will be, you know, separate, maybe have different architecture, maybe like software patterns, ish compared across. But like the, again, like the tech is the same, the readability is the same. So you could almost think of it, I think, as several different companies that just happen to have the exact same engineering culture. Rather than, you know, trying to compare this type of stuff with how they do stuff at maybe Meta or Amazon. It's more one company, one tech stack. So it's like, then you're kind of more stuck in your silo, so to say, versus here where you know, someone with reliability can help someone working on a completely different thing.

A (76:13)

It's an interesting approach. So 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 their, 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, your manager says why they think they are, and then their peers say like, like, yeah, we agree or we don't, or what about Jane? And then 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, that they all know the context of your work roughly. The bad thing is it can be pretty biased or it might be pretty ignorant. Like there might be some managers who would veto you because like, well, I didn't hear about this person or I had this one bad incident. One of my teammates said, I don't know how they got into a fight with you, et cetera. So there can be some biases there. 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. It's not your managers, but it's this group of 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 happen 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. They will look at the framework that's there and the impact. Because again, with the manager group, there's the other risk that if you have a really strong manager who's really influential, they're just going to push everyone through and then you'll have some teams where people are promoted who are clearly not ready or not doing as great work, but they have a strong manager or a good manager from their perspective. There is a very interesting kind of downside of this promotions 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. Four years, one after the other. And he wrote this blog post and he failed every single time. So he started to understand how the system works. And by the time he understood it, it was a bit too late. 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 they said to be promoted to L5 senior, you need to have an impact on Google. Then he went back and then he was like, okay, I need to have a project that can have that impact. So he now looked for a project to get to promotion. He got that project, but then the project got canceled. And then the next year, I think he moved teams or he had to move teams because his team got canceled. So he had this series of bad lucks where. And then, and then in I think year four, he wrote in this article, I'm quoting him, my quality bar for code dropped from will we be able to main this thing for the next five years? To can this last until I'm promoted? I didn't file or fix any bugs unless they risk my project's launch. I wriggled out of all responsibilities for maintenance work. 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 frigging 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? Why am I doing this? And he's a smart guy, he built a really good business afterwards. But it felt to me he just got unlucky of of how his teams changed. But also this is where we should talk a little bit of promotion driven development that is very real inside Google because all the incentives are there for it. And there's this joke that goes around of why Google has so many chat products. I think they had Google, they had Google Wave, Gchat and they keep changing names. And also the product, also Google's payments promotion, it was Google Wallet, then GPay, then Google Pay, then it's now Google Wallet again. But 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. Like they have Google Chat or maybe called Google Workspace. I'm never sure. They have certain products that are pretty niche and they're launching and they get a bunch of attention and press from Google and they're often on just one platform. For example, they had a chat product just for Android. And if you look closer, the incentives are that Google really incentivizes. 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 meets 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, my understanding. And this goes back to Google has this thing called Killed by Google, a website that collects these 300ish Google products that have been launched. But they have been killed.

B (82:22)

Yeah, I mean technically not run by Google but.

A (82:25)

Oh, it's not, it's not run by Google. It's just external. External. That one is not a Google project.

B (82:30)

But that would be funny if someone Internal at Google is like, here's all the things we're bad at.

A (82:34)

No, but it's interesting because on one end Google is very heavily criticized because they are the biggest tech company which seemingly wastefully launches and then kills projects publicly. But at the same point I still wonder if this is kind of part of how Google operates where they do want to see people launching stuff. And again, because look at it like yes, we can make fun of how Google discontinues stadia gaming console or Google Reader, but show me another tech company that has as capable of LLMs as Google has big tech, their own models or self driving cars in San Francisco and maybe you cannot do one thing without the other. I don't know.

B (83:16)

The way I think of it is that Google has had a really good culture of just creativity and innovation and just allowing people to try things out and see what happens. Famously the 20% time, which it's not really around the same way it used to be. But there was this again kind of open secret that any Googler could spend up to 20% of their time on some other project, like some idea they have a pet project. A lot of I think the internal tools you talked about earlier comes from that kind of things where you just have the ability to like oh, it would be nice to have something like this and you build it for yourself and because it's Google it's automatically available for everyone. And then all of a sudden you have built a tool that people use and then you move team and now no one's maintaining it. And so I think part of it is that that Google allows you to be creative and innovative and try new things and just like yeah, launch, see what happens. But I think another part of it as well is I think of Google as being a very kind of engineering first and engineering driven organization. If you compare that to say Apple, which is much more kind of like the design and user experience driven and if you have it versus say a meta or something like that, they're much more like product driven. It's like if you're a product person, that's how you drive. I think at Google it seems to just be kind of just engineering first and maybe one of the main ones that do that where it's like it's the engineers or like you have much more ability to decide what to work on and like choose the path for yourself. If you're an engineer, like it's much easier to get product traction and essentially it's because if you're an engineer you can also Build it. Whereas like if you're a product person at Google, you'd have to convince engineers and do this whole thing of like getting headcounts and stuff. Whereas if you're an engineer, like you can just either do it yourself because you have so much available to you again through code, search and the monorepo. Like you don't have to start from scratch every time.

A (85:43)

And then one more interesting thing of how Google works, and I don't know if this is like engineering driven, but maybe it's connected. Their design docs culture is just really, really kind of famous to the point of apparently whenever you start a project, you're expected to write a design doc, which is a Google Doc, which has certain sections and these are kind of loosely handled. But it's things like context and scope, goals, non goals and overview. You might have your architecture diagrams, how it impacts other systems, the structure of your changes, maybe rollout plans, lifecycle. Many alternatives considered. Some other companies have actually started to use similar approaches or maybe just naturally spread. It's often called rfc. Request for comment. But at Google, so every project will be rejected, even smaller ones if they don't have a design doc. And it's expected that you write this and you send it around, you gather comments and then you start coding. Which is really interesting because you would think that as an engineering during culture, one thing that us engineers love to do is code and what we don't like to do is write docs. And yet Google settled on again, it is very engineering driven. Why do you think this might be? They just realize that consensus is important because they're also big. Right? They're the biggest and probably the biggest like engineering culture of this quality.

B (87:04)

Yeah, I mean, I think, I mean it might be something like, you know, they introduced the 20% time or like they just had a. Maybe even before that was formalized, like there was a culture of people just trying things out and maybe realizing that, oh, we're redoing the same things or building something that, oh, had you talked with any other people, you had realized that that was either not needed or not a good idea or it has a use case of one, you're building something for yourself, so that could be a part of it. But I also think in terms of just the Google culture itself and Googliness, which we haven't touched on, but googliness is basically this idea of like people who fit at Google should be googly. And it's kind of a vibe thing. And part of being googly is that like it's less of this whole like a bit less of the rockstar mentality that you know, you're the rockstar engineer who just like goes off and does his own thing. It's very much more collaborative. Teamwork, team spirit, enable everyone to do great things. And so I would assume it comes from that as well. Part of being able to keep the Googliness is to just be very open. There's actually we've mentioned the SRE book. There's also an Svebook, the software engineering at Google, the Office.

A (88:40)

I have it here on my desk. Software engineering at Google. It's also, it's available for free online. Google made it available like it's officially free. It's not like one of these pirated books. But yeah, it's pretty big.

B (88:53)

Yeah. And they write about this like that book in general goes through like it does talk about a fair amount of the tools that we talked about like the Piper and the Monorepo and the critique and all that stuff. But it also has a big section of why are we doing this in the first place? And there are some beliefs that software engineering is a team effort and these are the type of people that you should have in a group in order to do software engineering.

A (89:21)

Well, one thing that Google really gets, and we didn't talk about it so far, but they really get how software teams work. They've run both a lot of experiments. They famously run an experiment where they removed all managers and they figured out what's going to happen. They didn't know. They thought that teams would maybe work better without managers, just engineers. And turns out they didn't. And then they went back and they tried to figure out what do good managers do? What should they be technical. And they've done a lot of research and they have published a lot of these things. But at a lot of companies I think as a developer you get really frustrated for because it's oftentimes the business CEO or someone pushing developers like do this or that and they're asking why is it taking so slow? Why are you guys, I don't know, like lazy or do more with less this kind of stuff. But things like making a case that it would be nice to have a platform team internally. It's almost impossible at a lot of companies. But at Google there's like platform teams left and right which means they just build an internal product or internal platform that the other product teams use. And most companies like a non technical CEO would not understand like why would I need to do this? Like we Just we have our engineers like they can, I don't know, use open source tools or whatever. And even when you use the open source tools or for your CI CD system, you still need someone to maintain it at Google. Like it's probably one of the best places where yeah, everyone gets it because they've been doing this. The people up there are software engineers. The founders are, I mean they were PhD students but they are software engineers. Even though the founders are, are no longer there. But everyone all the way to the top understands and breathes software and I think they understand that the software is a series of trade offs. It's not just code. So even when it comes to AI, they're not going to be falling for what everyone else is saying that I don't know, AI will replace software engineers. If it would, Google would have zero of them. But Google knows the value of software engineers and the limitation of them.

B (91:28)

Yeah, exactly. But I think that also like to tie it back to killed by Google. That's probably why you have a lot of freedom to try things out and then you build products that might not make sense. And if you had a much more kind of product person influenced organization or design person influenced organization. Yeah they probably wouldn't have the graveyard of killed by Google. Like maybe there would be like, would probably be way smaller and they would probably not be as vocal about it. Like they wouldn't make all of these sweeping announcements at Google I o every year to only have that product, you know, go bust a couple months or years later. But, but that's like, that's the other side of the coin.

A (92:20)

Yeah. One interesting thing that comes up with Google outside and, but I want to touch on this. It's not really software engineering but it kind of impacts us okrs, objective key results. Now if you're, if you're a software engineer you probably like and you worked at a mid size or larger company, this probably came up like what are your okrs? What are your team's OKRs? The objectives, the key results and the goals. And apparently Google made this super popular, this framework, right?

B (92:49)

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 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. Some examples of when they introduced OKRs in the beginning back in 99, their first objective was build a great search engine. And then they came up with their key serve at least 10 million queries every day, achieve sub 0.5 second response time for searches, improve accuracy of search results based on user feedback. And the last one, hire world class engineering team. And you can kind of tell that because they separated out the goals from these very specific measurable things everyone knows to be on the same point and like, okay, so what's the most important thing? What are we prioritizing? What do we need in order to serve 10 million queries? We need the data centers, we need the network. Like we can't use normal DNS, we need to invent our own things, et cetera, et cetera.

A (94:35)

So I'm going to be honest, I'm always a little bit suspicious about OKRs in Google. To me, because the book Measure what Matters was published in 2018 and from there on it's really blown up. And I think everyone's using okrs because 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 ticket system they use, did that make them successful? Because I'm like, the smell that I have is I have a sense Google would have been successful whatever they used because you know, like it started with PageRank. They did something that everyone wanted. And I wonder if if okrs is something that, I mean it's probably works, but it could have been anything else because whenever I used okrs at least and we tried to use it, having a clear goal and a team that was focused on building something was always way more important than having whatever OKRs. Because there's a usual criticism of OKRs of like, well, if you make it a target, it's kind of like, it's kind of silly because now you're only optimizing for that. Because I saw at Microsoft, for example, when I worked in 2010 or 2012, the organizations were all focused on their goals and they only cared about their metrics and it was terrible. We couldn't do stuff that Google did, for example, like My team, we couldn't agree to add our Codex into the new Internet Explorer called Edge while Google Chrome had it bundled because the two orgs had different goals and they cared about download size and not what we cared about. So anyway, it's good to know that Google uses them. But I'm still still kind of like I wonder if that really makes all that much of a difference for them. I'm sure it helps, but I think it's a bit overblown.

B (96:29)

Yeah, I mean it might have helped in the early days. Just like I can imagine maybe convincing stakeholders or early investors and each other maybe of like, okay, what are the things that we need? And at the end of the day okrs is a tool, right? Like this is a way of framing and communicating priorities and what needs to happen with each other. It's like if you use it in a good way then you figure out all of like oh actually we would need to do something else or we need to do something additionally. So I think if you use it as a tool like you can use tools in very bad ways and you can use tools to great success. I'm sure Google apps had plenty of OKRs that are not even remotely close to what they did, you know, in these early years. But like yeah, maybe it helped like since they've been around since 99. Like probably they know, like you know, it's helpful. But yeah, I do think that the tendency of like oh, they use this so therefore we should use it and then we'll be Google is. Yeah, that's not how it works. Speaking of okrs as a tool for communication, communication in general at Google is at least has been very open and very transparent. So historically this has changed a little bit now we'll get into this but culture is shifting across the industry, including Google in late years. But historically it's been incredibly open and transparent Again maybe it's part of it being the monorepo and the fact that everyone has access to everything anyways. But since pretty early days Google used to have or still has them these weekly company wide town hall, all hands meeting, check in type thing. It's called tgif. So thank Google. It's Friday. That was the original. And then like with the engineering team being company really because this is for the company, not just engineers. It is global. So it's actually, it's on Fridays in one time zone but not in the other. I don't remember. But so it's more like TGIT now. So think Google, it's two Thursdays. Yeah, but basically like 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 at, when I was interning, you know, it was on Fridays and like there's, 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. Like I remember there was a Halloween one that had themed and like they had decorated the cafeteria and you'd just like have this weekly chance to like go hang out with your colleagues before going home from work. But like you'd learn all these things from across the company and then.

A (99:59)

So it's a fun, fun event, right? Like it's worth showing up.

B (100:02)

Exactly. It's a fun event but it's tied to one of like the kind of cornerstones of communication across the company and then that, you know, it kind of trickles down in a way because like Google organization is very fragmented. Like again, because Google is basically many different companies in one. So like you'll have, they're called product areas, like the big sort of completely separate companies. So YouTube is one product area, cloud is one product area, search is one product area, advertisement is one product area that are like the big ones. There's another one that I can't think of right now, but you'll have those. And then internally you'll have different departments and different teams organized in some way. But it depends. There's reorgs very, very frequently. So you mentioned teams can just evaporate and cease existing, which is because of reorgs, because of projects being sunset moving around. So like there's probably never been in like an org chart that's lasted more than a quarter inside of Google. But then like within all of these different organizational kind of factions you'll have you know, kind of all hands meetings and town hall meetings. Yeah.

A (101:24)

So you're saying it kind of like goes down, right? So like there's a company one every week but then you're going to have your, I don't know, your wider org and your, your like, you know, like the bigger org and then your, your teamly. You'll have a weekly teamly for sure. So like every week you'll have the TGIF or let's just call it as, as in your team meeting. And then every other week or every fourth week you would have some of the other orgs and they can just stack up.

B (101:50)

Exactly. And then there's the like functional orgs as well that comes into it, which I don't know if it's as much of a thing with engineers but like you know, they have the SRV or again the design or.

A (102:02)

Okay, so a bit of a culture shock if you come from like a 10% startup.

B (102:05)

Exactly. And like the devrel Org and then like each of those like discipline based groups, they'll have different, like there are different ones in different PAs. And like so it's, it's so much like it very, very much depends on where you are in what org, in what discipline.

A (102:23)

You're trying to say this is a downside of transparency. Right. Because hear me out. So at Uber we had something similar. It was a little bit ridiculous and like on the kind of the org wide all hands, which it didn't really concern most people, people were just coding on their laptop because they were expected to show up on the meeting room. People will be coding on their laptops. Like I don't want to be here but I need to show up because the SVP is here and whatever. But what's the alternative? Right? Because if you're saying we are transparent and we want everyone to know, we want everyone in Google to know what the CEO thinks would every engineer to know what the CTO thinks. You want to know what your director thinks and, and just what, like what's.

B (103:03)

Going on, what people are working on.

A (103:05)

Well then there's a lot of meetings or you can be what Apple does or like a more secretive thing where like look, you're in your team, you are not allowed to talk with anyone unless you have special clearance and you don't unless you're, you know, so you have your team meeting every week. That's it, don't worry about it. Oh, why are they like you know, drilling off the wall and like this somebody next to you, that's not your problem. Like, but I feel those are the two extremes and there's different sort of trade offs. The sort of trade off is you will be in the dark and you will have no clue why they're like wearing funny outfits today and why they're like all laughing. And then the other one that you well know, it's just like there's all these, oh, you've not been in that meeting. They actually told us there like, oh, no, sorry. I was trying to get some work done.

B (103:47)

Yeah. And just like it can probably be pretty overwhelming.

A (103:51)

Yeah.

B (103:52)

But I mean they are good also. Again, maybe because Google is so global, I think they are pretty good at, you know, recording. Like I know I've heard especially since the working from home like pandemic situation, like after that they have even better kind of processes in place for this kind of stuff. So like cross Atlantic meetings, for instance, like these days apparently like they do some all hands and stuff twice. So they'll do one for a time zone that makes sense for Europe, one that makes sense for us. Because that also used to be a thing where you can work on something that's primarily based in the US in Mountain View, but you can be based wherever you want. But you will have to wake up in the middle of the night to go to meetings if you want to know what's going on.

A (104:43)

So let's talk about some things. There's so many things, but some things that make Google special. And one of the things that came to my mind that I didn't really hear before, a term called Re Googlers. And you know, Google has this like fun terms for like new Googlers. Newgler. Ex Googler. Ex Googler. Re Googlers is apparently a program where Google Talent acquisition reaches out to former Googler saying, hey, you left Google a few years ago, want to rejoin and apparel is really successful. A bunch of people come back. That's. That's the part that is not really common at a lot of companies. And it's a program, it's working, people like it. And yeah, people are rejoining as well.

B (105:23)

Oh, interesting. I didn't know there was a program for it. I know plenty of people who've left.

A (105:28)

And rejoined, but I heard that there's an outreach program. Uber started to do something similar, but I think it was just in one of the offices. But someone told me that it seems to be happening and I don't know if the program is official. But yeah, the term Re Googler is. It's a fun term.

B (105:45)

Yeah, I mean I love all the names for the different Googlers. Yeah, it's like Nooglers. When you're a new Googler, you get the Noogler hats, the famous ones, like you know, the little caps with a little propeller on it. I actually, I have this. I got this little Android friend when.

A (106:05)

I was interning there that's a collectible now today.

B (106:09)

Yeah, exactly. It did have. So this is the little nuclear hat. It used to have the propeller, but I broke It Wow. And like it has the little Google backpack. You can even open it.

A (106:19)

Wow.

B (106:19)

It's just so cool. But I think this, I mean this is part of like the Googliness of it all. You know, like we talked a bit about the playfulness and how it's. It's just part of the culture. It's like the offices, things like this.

A (106:36)

But what is Googliness? Is it like kind of fun, quirky, geeky? What would you say it is?

B (106:43)

They go through this in the SVE book actually but like they have a couple of kind of like values or characteristics if you will of being googly. And maybe the term like being googly is like somewhat being like it might have been bigger previously and now it's. They talk about it differently. But being googly is a lot about thriving in ambiguity because things move so much all the time. There's lots of reorgs and you try things out. So that needs to be a part of who you are. There's a lot of values feedback which ties into the perf now grad feedback cycle challenges the status quo. I think we touched on this as well. That's also been from day one with trying to get people who look outside the box and really accept that things could be better puts the users first is maybe somewhat of an ideal rather.

A (107:50)

Than that sounds pretty ideal from using Google products.

B (107:55)

Yeah. Cares about the team. And yeah, this again goes back to the. It seems from. I mean I'm sure there's exceptions but in general it seems like the Google culture and Googliness is more about teamwork and succeeding together. I think we mentioned bonuses. One thing actually in the bonuses is they have what's called peer bonuses and also kudos which is how Googlers can they have a ways of sending an hour of massage to someone they think did a great job. And then there's the peer bonuses that are more proper monetary, not huge bonuses but a bit and those really incentivize doing things for other recognizing things or others.

A (108:51)

So there's like probably a few hundred dollars or something like that.

B (108:54)

I think so. Yeah. I can look it up but something like that.

A (108:58)

Yeah. But I don't think many companies have this like you know some do have the. You can send thanks and they're public and everyone's like oh that's nice. But usually there's not like a monetary something attached to it. That sounds pretty unique.

B (109:10)

Yeah. And then the last googly thing at least on the list is does the right thing which I think is maybe ambiguous a bit I mean, Google used to have the motto don't be evil, which they kind of phased out. And I think it was like 2018. But that was one of the tenets from very early on to just, I think it goes again with the status quo. There's plenty of examples of big corporations, you know, starting out with good intention and then maybe getting lost along the way.

A (109:46)

Well, it could be lost along the way, but also it could be like when you're big enough size, it goes back to when you start to be doing government contracts and then the government does something that is just either ethically wrong or a group of people disagree with it, or a large group of people disagree with it. Do you stop working with the government? And if so, you're now giving up that space for your competitors. And then, you know, it now goes into the territory of like, what about other governments? When you're a global company, if your software is used in every single country, what if one country attacks the other? Are you now supporting the evil country? Or if two countries attack each other, you know, like both sides will think so. All I'm saying is there could be a point where by being involved you can be part of it. So that might also be one part because that's also one thing that Google is being attacked on. For for example, not just Google, but all companies of, you know, like providing software for. I think maybe it's the US Defense Ministry because they're now using it for something and all the big tech companies now provide software there. And you know, the alternative is like pull out and give up on the market. And also I guess this goes back to like do the right thing. It's, it's in this book, I just read it. But the right thing for who? Right? Because as a software engineer, what is doing the right thing for a service mean? Does it mean that we will have a great on call experience and we will invest a lot of time maintaining the system? Or do we do the right thing by shipping features quickly so the business gets, stays ahead? Or do we do the right thing that when customers complain the tickets come to developers immediately and we wake up in the middle of the night? Like the right thing for who? Right, so there is a little bit of ambiguity there. Yeah, but, but to be fair, like it's, it's in the book here actually. Yeah, it's great that they printed it in the book. Do the Right Thing says has a strong sense of ethics about everything they do, willing to make difficult or inconvenient decisions to protect the integrity of the team and the product. It's interesting. So customer is not mentioned here, nor is user and there's no customer anywhere. They do say user but there's no customer. That's one thing I noticed with Google they never talk about customers and about 70 they only say users. And that's, I think that's an interesting thing because about 70% of Google's revenue comes from ads. So they need users but not as a customer. And this is one frustration by the way that like I personally have with Google, you know, you cannot, you can never get customer support. You're paying for the product but you cannot get due to a person. And this is, you know, it's very different to Amazon where Amazon does give you first class customer support but they do burn engineers into pushing to make sure that you know that the systems work, they're repaired, interesting trade offs.

B (112:42)

It makes sense in a way where like obviously Google Cloud platform, I mean, I guess the earliest like kind of precursor to that I think is when they opened up App engine back in 2012.

A (112:57)

App engine, yep. That was an early user of it.

B (113:00)

Yeah, because like again like the, the Google infrastructure was primarily built for Google. It was never meant to be built for customers. And then you know, they had these, you know, the externalized parts of this and that, you know, grew to become the Google Cloud platform. They obviously made design decisions and choices probably I'm assuming while externalizing some of these things like building basil coming from Blaze, Kubernetes from Borg, you know, they must have built in you know, parts of it that's like okay, so how do we make this work for other companies, other use cases. But yeah, it's an interesting difference between GCP and other cloud providers, like where it started from, so to say.

A (113:55)

Yeah, yeah, that is really new to Google. So I think Google Cloud in general it did start from App Engine which so unlike a lot of Google services it was not start from internally and externalized, but it was built as an app. I was an early user of App Engine. App Engine was so darn cheap, everyone used it because of it. It was a lot cheaper than using AWS and running your own EC2 instance and you didn't have to worry about scaling it auto scaled. And then what happened in 2010 or 2009 because I was a user of it, I built a side project on it that had a few hundred thousand users and I was paying pennies for it and there was like some big reorg inside Google and they shut down a lot of projects. I assume that they were not profitable. And overnight Google App engine changed their billing to be like 5x as expensive. And suddenly before they said, all right, you can deploy your code and we will auto scale it. You don't need to worry about it. And now they had to worry us about index rights and they exposed us to our infrastructure and everything became a lot more expensive. People were voted and they gave us 30 days of notice, which was really, really short. So it felt to me that it was a do or die moment in the sense that either that that org proves that it can be profitable or generate revenue or they're shut down. But it was my first time with Google where I felt really burnt. I used to think of Google as like this amazing place that, you know, will not trick their users. And I felt just tricked and I was really like miffed. And I wrote a really nasty letter on the, on the customer support forum because of course it's the only support forum was a Google Google Groups, Google forum or whatever that was. That's where the official engineering team worked with us. You can see that Google is terrible at dealing with paying customers. It's almost like they don't care. It's almost like they despised them a little bit. Not always, but in a weird way, like most companies will be, you know, like put them at the top and Google just treats them the same as free users. Or at least that was my sense. But yes, that's how Google Cloud started. And there's this really, really weird thing or unique thing with Google where everything that Google builds, every major product or that they invest in massively is number one, YouTube, Gmail, Google Maps, you could argue. But it's probably the most used map solution. Android, Chrome. And then you have Google Cloud, which is the number three cloud service provider across a bunch of different measurements. They're way behind aws, they're behind Azure, and they're very, they're not really seeming to catch up. They seem to be stuck in this perpetual third place. The strange thing about it to me is, is I would assume if it's Google, it's very easy how to make it. You know, number one is like I start Google, start using their own cloud service. And I mean that gives the confidence of everyone. Well, if Google is built on gcp, you know, like this is what, like you can, you can trust it. And AWS did this over a long, long set of time. They have moved over almost everything Amazon.com runs on AWS, as I understand. It took a long time, but now it's all runs on it. When I was at Microsoft, they just bought Skype and I was in the Skype. Org. They forced us to move over to Azure and we hated it. It was not ready. There's a lot of things, but we had to move it. And a good part of Microsoft runs on Azure. Not all of it like Bing I understand has their own infra. But Google doesn't really run on gcp or maybe some small parts of it do.

B (117:20)

Yes. So they've had a few from, from my understanding, my research, they, they have a few like they've made attempts to move and migrate some stuff over to GCP and there are things that run on gcp I don't know what, but some things do. The way that they, they've externalized their product, as they say, it's, it's very much like, you know, Kubernetes is not Borg by choice and Borg is set up for Planetscale is what they refer to it as. And that is not most use cases. It is very specific and they've made a lot of engineering decisions that again, everything from networking to databases to literally everything is customer. So like, does it actually make sense to just externalize that? Not really. But that also means that like, well, if, if that's what they have, like if they want to win in cloud, that would probably be a thing that they should do in order to, you know, really boost the platform to be as good as possible. But then again it's like do they have to win at cloud? Because maybe if they win at cloud they are not going to win at all the other things.

A (118:45)

Yeah, I think question is if they want to win. But I got this because I have been asking a few Googlers or GCP people about this because I still remember inside Microsoft people were not happy with your and it was just done. By the way, the guy who did it was Satya. Satya Nadella. He was pushing people to do it. He was not the CEO back then, but he is now. But Microsoft clearly could be number two with Azure because internally they're pushing it just as much as externally so they're going to keep improving it. But someone at Google, an engineer told us how like I have heard a lot of Googlers say that their internal infra is superior. And as engineer told us that superior is an interesting term here. It's not like feature to feature. Google internal is better than gcp. But the level of vertical integration across the entire development process from like doing the plan or doing your docs code reviews, all that is unmatched because every part of the workflow has been thought of and it's got these like nice hooks and as a developer it just works so much better. So there's all these like decades worth of integration of the custom stack that it just works between all the tools that there is tight coupling that would be not possible and in the end devs will just do whatever makes it easier work for them. Like Google as a company will probably be like well we want to be productive. Right. That's why you have your internal platform teams and as you said that's probably Google being productive and building their product and generating ad revenue 80% of the time and other 20% will be hardware sales and like some service sales and all that. It's probably more, more important that they, they grow their business as opposed to just growing the cloud. The cloud or configure it out and being, and maybe being number three in one of the biggest businesses in the world in the case of cloud is acceptable Just the same way as Google is number two on mobile in a lot of regions with Android they're not number one, they're number one in some part of the world, they're number two in some other parts of the world. So you're right, maybe Google is way bigger than this and maybe this is not a. They don't need to win at everything. Right. Like only in the, in the important search with self driving they're seeming to be investing heavily LLMs. Maybe those are things that they really want to win in.

B (121:02)

I mean speaking of trade offs in general I think like if you really think about it and if, if Google were to move everything to gcp like if that also I guess like because they built out, you know, their build system, their monorepo, all their developer tooling on top of the same infrastructure, it's.

A (121:26)

Different, it just might not work as much. Especially when you have like all the permission systems that are like built baked in internally. Who knows. I think it's trade offs. Right? Yeah, that's probably a good reminder that like you don't need to like you know, like there's no one solution and also history of a company as I think pretty relevant to understand why they are where. Where they are right now.

B (121:49)

Yeah, exactly. That's one of the big takeaways for me doing this research. Maybe I mentioned it earlier as well. I think one of the reasons why they can be so open about the stuff they're open about is that it happened this way because it was so early and they made some fairly early acquisitions and strategic pivots into. We're not just building one thing, we're building completely different things. Like the. Org is set up based on that. The workflow, developer tooling. Like everything is just so interconnected with Google, which is why I think it's been so interesting to learn about it.

A (122:33)

I'm thinking that the companies that are now growing as fast as Google did In the past, OpenAI is a good example of this, of some of the other AI startups. Or maybe Nvidia's growth is, is speeding up, although they're more in the hardware business or for social media, Snap or even Meta. Well, they were earlier a little bit, but let's say for OpenAI they are now, you know, they're building other things custom. We're not talking about they're using cloud. Like they're not going to. I mean OpenAI seems like they're investing in their own data center, but it's going to be whatever everyone else is doing. We're now talking about the LLM stack, for example, that might be custom. So like they're just taking whatever is there. They're not reinventing the app part because why would you. Snap is a social media company. They used. They were very heavily. I think they're one of the biggest Google Cloud customers and kind of Google always shows them off as like an example of like someone who grew with them because they could just throw money at Google and optimize it later. And even Uber has moved over to a mix of Oracle and Google Cloud from their own data centers. So it probably helped Google that they were early in the Internet. Right. Like there were just no good search engines back then. They were the ones who built this one thing I have to mention. Internal mobility. There's just so much internal mobility inside Google. And for large companies there is usually some level of internal mobility. But as I understand, inside Google is just really easy to move teams if you're not on a bad performance standing. You can pretty much move teams anytime, as I understand. And usually companies have a lot more limitations on who can move or can managers veto or not. And here it's a free for all. So like people can switch teams and people do switch teams a lot. Like, I think it's hard to talk with a Googler who, if they've been there for like 10 plus years, if they've not worked on several teams and sometimes changing teams like a few years in a row, like almost like knowing how big Google is, like these are like thousands of teams, tens of thousands of Teams, actually. And yeah, you can just go between them. Obviously for smaller offices it's a bit harder because there's not as many around you. But still.

B (124:44)

Yeah, I think there's a slight thing. So just to mention, during the pandemic, obviously Google started working from home. Just ask the rest of us. And my understanding is especially then the internal mobility kind of like from. And maybe a bit after that kind of spiked a bit as well. Again, like most of us, you realize that like, it's possible to do this without being in offices. And so I know of folks who were able to start working remotely for teams in new locations.

A (125:24)

Oh, so they were able to do internal mobility. Previously, you needed to be in the same location. Now they could remotely join that team for a while at least.

B (125:32)

Exactly.

A (125:32)

Or like, I'm pretty sure that's going to go back to where it was before. Slowly but surely.

B (125:37)

Yeah, because it does. It has done that. Like they, I mean, Google now is, I think almost everyone's on a hybrid schedule where they expect you to be in the office like at least two, three, four times a week. Probably depends on where you are. And I know there's some.

A (125:54)

And probably your manager.

B (125:55)

Yeah, yeah. And how important you are to Google, probably.

A (126:01)

Speaking of exceptions, there is this concept of singleton.

B (126:04)

Yeah. So a singleton is basically a person who is on a team, but it's the single person from that team working in the new location, essentially. So if there's a team, say Waymo, for instance, but they have this one person who really wanted to move somewhere else or refuses to work there unless they can work from that particular location, it's like, okay, then you're a singleton. So you might still work at a nearby Google office, but you'll be the only person from that team working in that office.

A (126:39)

Yeah. And I guess it only makes sense. These are for me, senior people, people with like key skills. Maybe if there was a reorg, they were left there. Like, you need to be in demand, typically for your knowledge or at your expertise.

B (126:51)

It's not super common and it's definitely an exception rather than a rule, but like, it does exist.

A (126:58)

One more thing that is very unique about Google is the nonstop rewrite. Like everything is being. Not everything, almost everything is being written every few years. And this does happen to some extent at most large companies, but with a lot slower pace. I don't know if it's the engineering enablement, the fact that there's a lot of new technologies invented by Google as well. Right. Like they, they, they created the GO programming Language, for example, GRPC protocol, so so many open source contributions or that the business is changing that frequently. But because of this, I mean, this is a good and a bad thing. Like if you work at Google, you're going to be really good at rewrites and migrations because with the, with the rewrite there, it's usually migration as well and then the deprecation and that's a good thing. The bad thing is that this is not usually the work that most engineers would want to sign up for. You're exc building the new thing, but again there's that thing. When you build the new thing, how are you going to get the customers over there?

B (127:53)

Yeah, but I think it's like on two sides there because they have the mono repo, they have direct access, so they can actually make. They do have a tool called ROSI which is a tool for doing large scale migrations.

A (128:12)

Well, with the migration, I guess there's two parts, right? There's a code rewrite itself which is always easier one, but you can automate that. And then there's a data migration which is going to be the tougher one and the more error prone one and the one that you want to get. Right? And by the way, that's a really useful skill to learn because like, usually most engineers only do migrations all the time, but when you do, you better know how to do it properly and with the right steps and with the right safety and planning. But once you've done it a few times and you burnt yourself, you'll be unstoppable.

B (128:42)

Yeah. Either Google can be the worst place for it because you do it all the time, or it's the best pace because they do it all the time so they know what they're doing.

A (128:49)

But you can also move teams, right? So once you've done a migration and you're seeing the next one's coming, you might just move teams. If you didn't, I mean, if you did an okay job, it should be easy enough, you can look at it from different ways. And obviously moving teams, it's probably going to be a bit more nuanced than that. You do need a manager, a new manager who will be supportive. But as I understand with Google, your current manager does not need, you don't need to ask for permission, you can just move because if you would, then that would tie people in a lot more and you know, you could have manager bias and all of those things.

B (129:18)

Another one of the aspects of Google being so big, like we've mentioned that they're basically different companies operating in the same company. So that is one thing to consider. So like if you're, you know, if you've been at another company, done internal migrations or yeah it was like move teams. Also worth keeping in mind that moving teams at Google might be a much bigger shift but then again it's probably a shift in like the tech stack is obviously the same like you. It's not moving companies in the way where you have to learn a completely new tech stack and like how they use their tools and all the different quirks of like yeah you've done kubernetes before but like how do they do kubernetes at this new place? Rather the thing that you're going to run into is probably more on the how do you prioritize what are the communication like all the like softer things might be very different moving from team to team.

A (130:15)

And I guess one thing about Google that is kind of special although a lot of other companies do it these days, but just how much they contributed to open source and the industry, the broader industry like some of the biggest project that they have built or open sourced or started and now are still sponsoring and investing Kubernetes obviously one of the big huge ones, Angular which React is now a lot more popular but it's still, I think it's gaining popularity again and Google is very heavy user of this front end framework TensorFlow for machine learning. It's so widely used. I mean we cannot not mention the LLMs with the. That was not the technology but the paper that kickstarted all of this with attention is all you need the GO programming language, Chromium as the browser engine and just so many other things. I think Meta has a bunch of strong contributions in Microsoft in certain areas but I feel Google has a really wide range from backend frameworks, machine learning, front end frameworks, protocols. My sense is that overall they might be the single most kind of contributor to like the kind of broader open source ecosystem. Especially when you take the papers into account that kicked off even more projects or software businesses.

B (131:38)

Yeah. And inspired people as well. And like looking through some of the papers even from early on, but even later papers that I look at like they're also very open with just like learnings of like what works, what doesn't, what should you take from this? What should you not take from this? And I do feel like I was reading through some of their old blog posts as well. They had a tech blog for or maybe just a blog for Gmail. The Gmail Team had a blog that they wrote from 2007-16 where they just talked about the time that Gmail went down and they had to go in and recover data from all their tapes. It seems like they haven't ever. Or like they don't think of sharing this information as some kind of, you know, moat or something they need to be secretive about because, like, what would happen if other companies copy us? I really like that about Google, actually.

A (132:40)

I mean, I think it used to be like that. I feel that might be slowing. Or maybe there are just not many blogs. I don't remember, like any major engineering teams sharing. Oh, here's like cool learning. So I think that might have been the earlier years.

B (132:51)

Yeah, it could have been.

A (132:53)

And I think now it might be a bit more controlled. And there is no, like one Google engineering blog. Right. I don't even know of, like, some other teams, but still for the open source for sure, and for the paper. So the research and the open source is there. And I mean, to be fair on conferences, Google speakers do show up and they do share, they do talk. It might be a little bit changing because now Google does sell to developers. They have some developer tools like Firebase, a lot of Google cloud. So now they do have dedicated folks who are. Flutter is another good example. Like, on those areas, they're kind of a lot more active of sharing. Like, all right, here's how to use it, how to build it, et cetera. But yeah, still, I asked this on the podcast episode about Kubernetes. Like, I still didn't really understand why did Google release Kubernetes? Because they had Borg and it worked really well for them. And so why bother building something that they didn't even use? Like, they just put it out like, oh, here's kind of some, some lessons from Borg that others can use. And I think where we got to is that they probably did that because, well, first of all, now looking back, it was. It was good for their. Very good for their cloud business to have a technology where it's very easy to move from, let's say, containers on AWS or Azure to gcp. Also, by knowing this, there's not much harm. It wasn't too much investment for them to do it, but it now helps the recognition of the brand, it helps with recruitment. And they're also now pretty much steering the technology that is the winner. Kubernetes. They have a huge say in it. Like, yes, it's an independent organization that's there, but most of the contributors are still at Google. So they actually have a pretty good say in that. So maybe it's a mix of these things, but it never felt to me that it was like some sort of business decision. It was probably some engineers thinking like, it's a cool idea, why not? And then you can justify the business for it. So I wonder if a lot of Google is like this. Like engineers are like, oh, here's an idea. I'm like, okay, let's see if we can justify some business numbers.

B (134:56)

One of the things, again, 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 the culture is shifting. There's the winds of change in Google following partially just the vibes of the industry as a whole, but partially very much internally. Also during the pandemic they had some big leaks, so they stopped some internal transparency in the all hands and the full access to everything going on. I know that's been restricted.

A (135:46)

Yeah. 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 where Google started, how they built all these cool things to what is Google like today from all that we've gathered. And I guess maybe we should just reflect a little bit on how the whole, as you said, the whole industry has gone through a massive change, which was, I mean, there was a couple of left and right things. First there was a pandemic which the whole world thought would be a disaster. And then it turned out to be a blessing for tech because everyone started to hire like crazy and interest rates were still down. There was close to zero interest rates in the US and worldwide on borrowing money for more than a decade. And this was just interest rates were just about to go up before COVID And then because of COVID every country cut it down to like zero for another two years. So tech had this thing where there were still like zero interest rates, meaning investors couldn't really put their money anywhere. But like tech stocks or startup investment tech had a big boom. Everyone started to hire. So this was a great time. And this was 2020 and 2021. I, I had so many friends and, and former colleagues who like got 30, 40, 50% compensation increases, like just by going to a company that did similar things, but they just raised money. It was a great time and a really hard time to hire or to retain. People kept leaving left and right. I heard of Hiring manager, a hiring manager who had a engineer sign and ready to join them. But they didn't, didn't show up on the first day. And I was like, oh, called them up and like, oh yeah, I got like a 20% higher offer. Sorry, I'm working somewhere else now. And then this was great for like a year or probably a bit more than a year. And in 2022, just as lockdowns ended and the world recovered, tech started to crash down. There was like mass layoffs across companies. I think it all started with the fast bankruptcy. One click checkout, sort of fast just went bankrupt. From being one of the hottest companies in tech to just bankrupt overnight. And then a bunch of other startups, including like Stripe and some other. Almost every kind of large company did layoffs. And this turned out later that as we look back it had to do with interest rates rising. And when interest rates went up, this meant that companies and investors looked for profitability. So everyone suddenly focused on that and there was a bunch of overhiring in the previous year. So suddenly we had this like dual shock effect of going from everyone in tech is in demand and people could not hire enough boot camp graduates because there were not enough university graduates to just lay off. Shocks happening as well, a few company bankruptcies and just a really kind of negative vibe in the industry. And 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 a 3% layoff because of the financial crisis. They then did some layoffs after they bought Motorola in 2014, 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. This was 2023 and then in 2024 there were some more layoffs coming in. Not as many as before, but it 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 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. And maybe it's not your fault either. But on one end, it's a change that hasn't happened before. On the other end, I was like, come on, you cannot have it all, everything for the whole time. Especially for such a large company. One part of me is like, well, I mean, it's kind of sad that it's over, but my other sites and at least startups have a chance. At least they can point to one thing Google does not do perfectly.

B (140:11)

Yeah, I mean, it does seem like they had a really good run for a while. And like, I'm sure there's pockets at Google that is still probably a fantastic place to work. But I do think, like, it's not necessarily bubbles bursting, but yeah, like, vibe changes and like, part of that is the industry, but like, part of it is also just like the actual products. So in terms of like, you know, YouTube was and is in many ways the new TV, like, it is dominant, but then TikTok comes along and TikTok is, you know, much more focused on the users and grabbing your attention and getting you pulled in. Whereas, like, YouTube has definitely done that as well. But like, not to the same extent in terms of the shorts. But then all of a sudden like now YouTube has, has and kind of has to push for shorts because they, like now they're in the attention war. And similarly with, you know, like, I feel like there's much more in like the, the kind of public stratosphere in terms of. Yeah, it's like, oh, Google sure has a lot of our data and they're sure doing things with it. And you know, Google search results are like, a lot of them are sponsored. This doesn't feel great. So I think there, there's a bit of a shift as well in terms of just, you know, like, they don't. Yeah, they, they cut the don't be evil. But like, maybe they leaned into it as well. Who knows?

A (141:51)

Well, but I think this is the part where. So I saw Manu Kornet, who writes all these comics. He was for 12 years at Google. He then quit Google and joined Twitter. And then lucky for him, he joined right as Elon Musk bought Twitter. But he joined, he told me that they loved Google because he, over the 12 years, I think from 2010 to 2022, towards the end, he started to become disillusioned of Google because he joined with, you know, he believed like what they said, that don't be evil, that make the world a better place, whatever and you know, build cool stuff. And then he started to see how a lot of his comics started to become more reflective of how he's thinking of just how like he had a comic of Google's naming of the throwing darts, how it's all chaotic. It was, it was starting to criticize a company where clearly like there's a lot to criticize about Google, but and some of them, sometimes profits started to come up on some of his comics on how Google is prioritizing profits. And so here's the thing, like, you know, when you're going up, including at Google, like you reach the L6 level, which is staff engineer does the same level as a manager. Now if you think about it as a software engineer, you think like, oh, I just want to think about the code, my colleagues. And then as a manager, you need to think about the business and your budgets and headcount and hiring and firing. Now you're now paid the same like a staff engineer and the manager is paid the same. And they kind of are expected similar things. So a manager or one level up, especially a senior staff engineer, is kind of expected to understand where the, you know, like a bit more of the managerial side, where the business lives and how it makes money. And one thing that I think anyone working at Google or any other company needs to understand is where does your salary come from and how can Google keep paying top of the market? And it's to do with their profits just keep increasing. It's ridiculous. If you look at the chart, every year Google grows about like 15 to 20% in revenue, which is bonkers because they're now so big they're making like 300,000something billion dollars per year. But as long as that happens, things will be good, right? There's not going to be large layoffs, there'll be large bonuses, all the perks, new offices built, etc. As soon as that slows or it goes to zero, bad things will happen because there will be layoffs. And you know, Google's doing everything to not make that happen. But eventually that reality will creep in, which is at some point your job might involve helping Google make more money so that they can hit this thing. Or if it's not making more money, then help investors believe that next year they will make more money, which has to do with all of the things why Google is going all in on AI or if that doesn't help, then tell them how you're going to cut costs faster. So I think at some point, both in the life of a company, but also in your seniority, you cannot ignore the business and then you cannot ignore how they make money, how they will make money. Will it naturally grow without you doing anything? Because if so, you're in a good place. Or does Google, for example, need to expand the areas that IT services, which, which will include things that are controversial. Right? Like, like again, like, will it get into military contracts? And. And the easy answer will be no. But now when, when you need to increase Your revenue by 20% and by not saying, by saying no to them, you cannot do that, then the, there's all, all these things that, that trickle down as, as a result of that.

B (145:20)

So yeah, it's, it's growing up in a, in an industry and in an economy that only goes up. Well.

A (145:27)

And then Google has. It went from being a startup in a garage not even 30 years ago. Wow. In 1998. Like just an idea. To one of the biggest companies in the world. I think fourth biggest company right now by market cap. And you know, like, how much more that can you grow? Like, I'm sure you can grow. Right. But where is it? Like, okay, they can now, you know, they can aim to overtake. Right now it's Nvidia and Apple and Microsoft ahead of them. But then watch. And will growth always continue? I mean, this is more of a philosophical question, but I think all of big tech will eventually have to reckon with this question because we went from tech companies being kind of underdogs. There's people who still remember Facebook just being an idea or be used by teenagers. Same thing with older listeners or viewers when Google did not exist to. Yeah, they won. And now the question is, how do they keep winning? Eventually winning is innovating, but at some point it might be trying to lock out other competitors, which, you know, Google is being sued right now by the U.S. department of justice for offering Apple a bunch of money and for Apple accepting to be their default search engine and not having any competition on, let's say, iOS. It was interesting how things change.

B (146:42)

Yeah. And it's interesting. It's like the amount of power these companies have as well. I personally couldn't imagine life without Google because, like, you know, it's my calendar, it's my email, it's like. So, yeah, I have a background in design and there's this general idea in design that really good design is design. You don't Notice because it just becomes a seamless part of your day to day experience. Like you can point out bad design easily because those are the things that you notice and that provide friction in your life. And Google is like, they have a lot of things that just, you barely think of them because they're so ingrained in your life. Which means that, you know, they do wield a lot of power. Like, you know, you've probably had that, you know, when they decide to change some aspect of Google Calendar or change, you know, a color of something or whatever, you know, you have like, know you, you can, your whole day can be completely thrown off.

A (147:45)

Yeah, and I think there's a good question because I think so far a lot of what we talked about Google and what makes Google really unique is how they started. There was a startup, it innovated so much, they had 20% time, they kind of got rid of it in 2013. So about 10 years ago, the vibe is also changing. But the reality is that anyone who joins Google today, it's a very different company than it would have been even 10 years ago. Because there's a phase of growing and innovating and there's now pocket, there's pockets of innovation, right? AI is still up for grabs. There's a really open battle between all the leading AI companies, including Google. It's kind of fun and exciting, but there's also areas that are just one, if you start to work on Gmail, I mean it's already market leading. Like what is your mandate going to be? It's probably going to be, I mean, you know, keep existing users, don't let them churn or extract more money from them in terms of ads because that's how you make money or upsell them to something. But it'll be mostly like maintenance and don't mess up. Or if it's a cash cow product like Google Search, you know, we've now seen reports that some of the executives knowingly kind of made Google Search worse to have people see more ads, to generate more revenue. But the point is like working on a product that has been built, it's been proven, it's been innovated, there's now very small innovations compared to what it used to be like. And so at some point, which I don't think is necessarily a bad thing by the way, but at some point this thing comes where like, okay, like if you want to work on something that used to be like the old Google, it's probably going to be startup or if you're lucky, it'll be a team inside of Google that has a greenfield project. Again, all of those things happen all the time. But yeah, but for some of the big areas, it's different work to work there. And this is, by the way, how, this is one of the few ways we used to be able to, when I was working at Uber and we were a lot smaller than Google, how we used to be able to get people with Google offers with stronger overall compensation numbers. Except us, because we would tell them, like, look, you can totally go to Google, like get paid really well and all that. And you know, you can be a cog there. Like, you know, like do your little, small, little thing, you know, like tweak a few things and just be unsatisfied with your work. Or you can come here, you can, you can get less, less cash. But like, here's all this stock which, you know, it's, it's the same. We promise. Well, I mean, but we couldn't promise, but that, that's the nature of stock. But if everything goes well, you'll have this huge impact here. You know, you'll have the CEO see your work or everyone and we're building something new and you'll have freedom. And that was the thing that made a lot of people do it. In fact, I think that's the reason that people will leave this really cushy place called Google is if they just get a little bored and they feel that they could do so much more.

B (150:32)

Obviously there's always innovation, but just like it just looks different today I think and the scale of it is different because I mean, yeah, like Google Calendar does come out with new fun things fairly often and you know, there's new features in Google Meets and Google Chat and all these things. But yeah, it's a much smaller scale. So I think it's like you can definitely still be like, do fun, innovative stuff at Google, but it's, yeah, it's not going to be the new Gmail.

A (151:07)

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, not, not the ideal Google, but the one that, that, that we know today who could get a bunch of value out of working there and when could be a good time assuming you managed to get in? Because I think we should be clear, getting in is, is super hard. But for those there, what could be good question to ask of, like, am I in the right place or should I use this privilege that I'm working at Google. Because once you're at Google it's so much easier to go anywhere and maybe explore some other avenues.

B (151:43)

There are some of the things that we've been sort of talking about the whole episode. 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 with completely different things at Google.

A (152:15)

So you're basically saying like if you're interested in the frameworks in the industry that startups use, 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.

B (152:30)

Right, exactly.

A (152:31)

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 and who knows?

B (152:43)

Exactly. So that's one part of it, another part. Like if you're someone who likes, 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.

A (153:05)

It's interesting because the perception outside will be that Google is stable as a whole. I mean maybe teams change but you're saying, you know, things change so just get used to like you might get new managers or several a year.

B (153:18)

Yeah, exactly. Like reorgs are a staple.

A (153:22)

Yeah. Actually I think I talked with someone, I think it was Google who said like I had like, you know like seven managers or six managers in a span of a year. It was just a lot of this was someone pretty senior so like was being thrown around a little bit. But yeah, yeah.

B (153:37)

And then on the flip side of that, I think 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. Like they didn't completely get rid of it more phased out it more became like 100 to 20% time where you can work on things but it's going to be, you know, in addition to your normal work. But they do also keep, 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 the like killed by Google is definitely true but it's not like all of it's wasted. Like they have, they, yeah they've done so many chat apps and so many social network type things where the products didn't survive but the technology got, you know, it got incorporated into what's Google chat now and Google Meets and you know, 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 like kill your darlings thing, if you're not good at killing your darlings, then probably just do startups instead of Google.

A (155:15)

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, some time, even a year, it's one of the most recognized brands even to date. Like there are some other companies that are, that you'll keep going up and down. Right now OpenAI for example is also very, very recognized and of course you know, meta. But Google has been like this for almost 30 years, almost since the beginning and it continues to be. And part of it is the bar of getting in is just very high. So there's this thing, I think this is, it's kind of funny that we're saying like should you work or should you not? Well first of all like can you get an offer? Because most people unfortunately cannot. And this is made even worse that Google's headcount has been flat, pretty much in fact slightly declining since the last three years, which has never happened before. So until then they were growing basically it was easier to get in considering assuming the same number of candidates applying every year. So it is kind of getting harder to get into Google so it's not taking for granted. So like my suggestion would be is if there's a reach out from a company like Google and it can be a challenge to just go through an 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, including the scale ups and startups that are super hot, OpenAI and traffic, they will hire very similarly than how they hire from Google. 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 OpenAI Entropic as I mentioned, ramp 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 the companies that can pay more than Google or can match it, or can have a bigger promise with equity will often just take the shortcut. Instead of interviewing so many people with no proven tracker, just go to the source. So that's one. And then there's a network because if you're someone who is curious or talks with other people inside Google, you can build up a really good network. Just getting to know people. The X Google network is very strong. The fact that there's a sugar network who as I understand they help each other, there's like investment networks and all these things. So if you have the opportunity to potentially get into Google, see if you can and then decide if you want to do that, having it behind your back, it can strengthen your resume and your opportunities for like a decade or even more to come. You can always say you're ex Googler. And the thing is not many people will be able to say that globally, especially as a software engineer. So yes, one more thing to keep in mind.

B (158:06)

I know it's changed, but there is one thing of interviewing with Google. Like it is a bit of a funnel. So like there are some of the interview process that's just like, you know, get, get your foot in the door to begin with. And then like once you're in there, like I do think you still have somewhat of a choice. And you know, you get to talk to some, a few different teams at least. You used to like talk to a few different teams, like see the vibes before you like jump on fully.

A (158:38)

Yep. And Google that 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 you Deciding they're 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's kind of harder to get into than most places. And I've heard that recently about like 6 months ago this happened that a bunch of people were rejected and very disappointed that they couldn't get into. So it's one of these things. Again it can be frustratingly hard to get in when you want to get in. But again it's good to know because I hope that we were able to share some details because this environment really is not for a lot of people and you do need to put it up with a lot of things that come with large companies. And in this case the 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, yeah.

B (160:06)

Again like maybe there's a pocket somewhere. I'm sure there's some team, but in general, yeah. And I guess that also would maybe be like my last reflection on who would fit at Google. Like it is a big company. It is so big. There's so many people. Again like I was there for like not even four months and in that time I, I met so many people and like, yeah, if you go to an after work and meet someone, it's like, yeah, you're talking to someone who might as well be at a completely different company. And also like when I left and then after, like after a couple months I happened to be in London again and I went to the office and visited and like in just like four or five months like I, I recognized like almost no one. And the people I knew, it's like no, they'd already moved or actually like this used to be the case where the London office used to be kind of a holding hub as well. Like people would be hired and then go to the London office for a year and then they would move to the Zurich office because like immigration wise that was easier from a lot of company, a lot of countries. And so there was just this constant flux of like new people, old people. It's like, oh, where are those people now? They moved. And if that's not your vibe, if you like, like knowing your co workers and feeling like oh, this is like a nice space where like, you know, it's fairly stable then yeah, Google's probably not for you.

A (161:37)

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. They're one of the few companies who built their own model. Microsoft doesn't even do that, or if they do, they're kind of hiding it. 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 positions. Sometimes they'll go from engineer to sometimes tlm, sometimes the PM and back. So there's a lot of mobility. 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 Google's perks and pension program and whatever that I will not have a very comfortable life. And you see people in their 50s or so say that they are early retiring after a decade or more at Google. And some of this has to do with a bit of a bias that like 10 or 20 years ago joining Google getting stock meant that the valuation brought it up. But again, it's rare to see companies like this. So that's just kind of an interesting positive. And you know, maybe similar to banks used to be places like this where like in tech divisions when I worked at JP Morgan, it was pretty common for people to retire from there because it was stable, it was predictable and there were some lifers as we called them. But I mean, I think it just shows the tech industry is changing. You know, now there are stable companies, the startups that turn into stable companies that are still innovating but they kind of won their market. So. And Google is definitely one of them in some of parts and in some pockets. Very exciting and doing a bunch of interesting stuff.

B (163:48)

We've just spent how many hours talking.

A (163:51)

About Google about Three.

B (163:52)

Yeah, we could probably go on. And we, we do have, you know, we have written deep dives to accompany this podcast. So if you want to go in even more detail about some of this stuff, go check out the Deep Dive articles. We'll have lots of links. And again, because Google is so open, a lot of this, like a lot of this data, you'll just be able to find, like you can find the papers we've talked about, you can read the books we mentioned.

A (164:18)

And that's the thing. One thing that I would just close with is we could go on. We're trying to cap it at a reasonable length, as reasonable as it got. And we do have more structured notes in the show notes below that we're linking in the Pragmatic Engineer deep dives as well in previous deep dives. But don't forget that for every company that is a large company, it's not just one place. There's so many different teams and everything that we might have said or covered about how things generically work, it might be absolutely false 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, you know, reasons people go to Google, for example, or leave Google, might be their manager. They had an amazing manager at a company and they happened to move to Google and then they followed them and the other way around. So, you know, people come and go between companies like Google Meta, big tech startups and scale ups. And there are some things that can be generalized. But yeah, don't forget if you meet interesting and valuable people, just keep in touch with them because they might end up in interesting places that might or might not be like these. And I hope that these details were interesting and probably collected for the first time in this format. This was an experiment for us as well, so let us know what you think of it.

B (165:44)

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

A (165:55)

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 Andrew and culture, check out our Deep Dive article in the Pragmatic NGO 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 one.