Google’s engineering culture

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

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

this episode is for you. This podcast episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsor. So let's get started. Hi, I'm Gergay, your podcast host and author of The Pragmatic Engineer. Hi, I'm Elin, and you may or may not know me as The Researcher.

of the pragmatic engineer, you might have seen my byline in some of our deep dives and survey articles. And today we're going to try out this new format to bring you a deep dive. by talking you through everything Google. So I was an intern at Google for a couple months back in 2015. I was based in the London office. worked as a UX intern, actually, before I worked as an engineer after that. So I have a little bit of...

Like inside vibes, but not that much. Let's start with, everyone knows Google for sure. You cannot not know it. But what are some interesting stuff we found about them? The numbers, if we're going to go there, like.

It is easy to forget how big Google is sometimes. So, yeah, the latest numbers, there's 182,000 employees across all of Alphabet. But obviously the majority of that is in Google. We have numbers from 2020 that there were about 50,000 engineers. And that's up. So like in 2015, which was the first time they... came out with a lot of the numbers about the engineering org there were 25 000 engineers i think size wise this makes them

Similar to Microsoft in total employee count for engineers, a bit unclear. Maybe Google has more, maybe Microsoft. Probably similar to Amazon, but Amazon has weird numbers because they kind of mesh the workers, but they're a lot bigger than Meta, for example.

like they're they're like i think two three times bigger so they're easily one of the biggest kind of top tech companies in the world if not the biggest i i think the question is with microsoft but i think when it comes to prestige uh compensation uh they're they're easy number one in in this regards uh scale of of work that people work on and speaking of of scale uh you know like again microsoft might have similar number of employees but when it comes to google

i think numbers are a bit unclear but around three to four billion people per month use their services between search gmail youtube I mean, all of these are marketing services, right? I think search is more than 1 billion people per day, which is kind of like every, I think, 9% in the world uses search. YouTube has 2.5 billion monthly, which is more than TV viewers. And then Gmail has 1.8 billion active users. And I'm pretty sure looking at my newsletter.

about 70% or 60% of emails are Gmail. 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 like over 50 market share like 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 uh

Like there's five 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. Yeah, that's a lot of parallel processing. There's 2.6. million videos uploaded every day, almost a billion a year, and a billion hours of video is consumed every day. Yeah, those are just large numbers. And I think, like, 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 like Chrome. the leading web browser android which is still the leading smartphone platform globally by a lot by about 70 in the us ios is now getting bigger so that can be a bit misleading

But then there's things like self-driving. 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, 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.

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 the googleplex the googleplex yeah really cool office like really cool uh kind of perks and 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 a big one, Seattle. And they have a lot of offices, smaller ones in the U.S., L.A., Pittsburgh, Boulder, a lot of specialized ones. Cambridge and Massachusetts is pretty big as well. Yeah, the Seattle office is definitely one of the bigger ones. And you might hear it referred to as Kirkland as well, because Kirkland is the suburb of Seattle where it is.

And it's, yeah, lots of cloud is based there. Yeah. And then Europe and the UK have large offices. The biggest one known in Europe is Zurich. It's actually probably Google's European HQ in terms of engineering, if you will. And a fun fact is that Zurich pays almost as much.

in compensation as in the U.S., which is really, really interesting, a lot higher than their other European offices. London is another huge office, Dublin a big one. Dublin, I think, might be bigger than Zurich in terms of people. but not necessarily engineering. They have a lot of sales. Oh, you're right. I actually used to have friends, non-technical, who were in Dublin. You're right. I was thinking engineering. Engineering is the biggest.

hub for sure munich is a big one for engineering as well and in germany they have a berlin one i i understand that it's a bit smaller And in 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 it. It's tiny compared to all these other ones.

Yeah, there's actually one here. I'm based in Stockholm, so they have an office here as well that's grown a fair bit. It's like a few hundred people. Fairly big on the engineering side, work a lot on video meets and calls and stuff. And a lot of US tech companies would stop here, but Google obviously being Google, they have engineering offices a lot of other places. Bangalore and Hyderabad are two massive offices in India. They've grown so much as well.

And growing. Those are, like, a lot of the open positions are based in India. Yeah, we had an issue with that when I used to work at Uber as an engineering manager.

We were hiring in Bangalore. And what we found is we had trouble hiring senior engineers because whenever we'd extend an offer and that person was interviewing at Google, Google would... offer 10 more than whatever we did always 10 more so i 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 and this was a big kind of But there is this thing about Google, by the way, if you have a competing offer.

Google and they want you and then you're like senior and above Google almost always will offer more they don't care too much about their internal bands again over time this might have changed and for more junior positions this could have changed but I had a director friend who was situation between having a competing offer at meta and google and and 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. Google has so many offices, right? And engineering can pop up anywhere. Yeah, exactly. They have a pretty big one in Brazil as well, in 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 dollars in revenue 75 of that comes from ads and i think google like they've done good for themselves because they figured out such a good revenue model from day one for themselves so they've always been able to offer all of these high

salaries and pay for so much stuff i'm gonna challenge you a little bit because i so like we know like google is insanely profitable right like there is no doubt about it however when we look a little bit closer at the unit economics and you know we're gonna we're gonna 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 again

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 up 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 i think google is 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 Visa or other companies. Now, one interesting thing that I wanted to bring up is when you joined Google, there was...

this note from a founder who got acquired by Google called Treas Banzal. A 10-person startup got acquired several years ago. And on a blog post, this is what he wrote.

uh 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 with great food great desk and a high speed link to every person in google's 200 000 person network and it's like visiting America as a foreigner, everything you see inside feels oddly familiar because of his 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 just how it is one company, but it's also more. Yeah.

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, you can reminisce my memories of Google.

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 so that you can only talk about with other Googlers, which, yeah, are like, so it's more like they're in the same alternate universe bubble as you rather than at the same company as you.

And yeah, the badge is really the passport to that, really. It's a really fascinating place to be. So Google has... the most unique tech stack in the world and and we're going to go into a lot more detail but they have custom built everything so unlike almost every other startup or company that has some level of standard tech stack that the rest of the industry uses google just uses their own stuff and it works really well

them which which has an interesting outcome yeah yeah we'll get into a lot more detail 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 algorithmic interviews and they kind of, I guess the perception of how Google having a hiring bar made it go mainstream across the tech industry.

And then they also invented roles like the SRE role, which is now kind of pretty widespread across other companies as well. Yeah, exactly. Even though it might be called something slightly different with like, you know, DevOps, reliability, engineering, 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, CodeSearch. We'll talk about a lot of them today.

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, A-B 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 the fast-moving bottoms of approach to product development. And this practice of having your engineering teams have access to these tools really

did become the baseline for standout tech companies. For the last 15 years, pretty much every major tech company has had entire teams of people rebuilding this kind of feature flagging, A-B testing stack of tools internally.

But now something interesting is happening with the latest generation of tech giants. Rather than building these tools, companies like OpenAI, Entropic, Figma, Notion, and a bunch of others, they're just using Statsig. Statsig has rebuilt this entire suite of data tools that was available. All backed by a single set of product data.

And one really nice thing about Statsig, 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... The other thing is scale. Since Static already processes trillions of events per day, which is enormous data by the way, they also scale with you. Plus you can integrate Static into your existing product data easily as well.

giving your product team an access to incredible data tools, go to statsig.com slash 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 uh tools the tool set that someone will see if they start to work inside google or if they're they're working there they see them

Yeah, exactly. And I think actually it's like why this tech stack looks the way it does is very like it. It's because it was search, it's like, well, this needs to be global from day one. So we need to have this infrastructure from day one to get the speed and reliability that we want.

And so that's why they just jumped straight ahead with like, we'll just build custom stuff from the ground up. So yeah, like they scaled into six digits of machines in the early 2000s. So like hundreds of thousands of machines. Yeah, in their data centers. Yeah, there was a pragmatic engineer post from Anessa Reef a couple months ago, I want to say, where he talks about he started at Google.

uh 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 has hundreds or maybe thousands of machines. Yeah, yeah. This is Dave O'Connor, and he was telling me that I think in Ireland they visited... a data center because they they want to see how they worked and they wanted to see if they could use them and in the end they figured out they couldn't

But they asked like, okay, how do you manage your machines? And they were like, oh, we just do manual updates. And like, 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 were 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, like they knew like, okay, we cannot do whatever else is doing. We need to figure out, build new automation, build new tools.

and that's actually how they invented the site reliability engineer role they they actually needed software software engineers who now became experts at like operating infrastructure which was unheard of because until then you had the it guys who who knew how to configure you know windows machines or linux machines and knew how to patch them how to plug in how to you know make sure like do all these things

but they were not software engineers because why would you hire a software engineer to do that? So like Google did a bunch of these things. And that's where, obviously, one of the biggest internal tools, which we mentioned, Borg, comes from, which is orchestration system. And Kubernetes was inspired by this. In fact, Google created Kubernetes based on lessons learned from Borg, and they released it in open source.

And internally, they still use Borg. Yeah, exactly. So yeah, so Borg is basically, it's a cluster operating system. And then, you know, do you know what Google's kind of internal version of Datadog is called? Borgmon. Oh, yeah. There's also one called Monarch. I'm not sure which one is which. But yeah, so they have this monitoring which is like integrated into Borg. And this is one of the reasons, by the way, people are like, oh, why doesn't Google just move to Kubernetes?

And well, I mean, then they would need to replace some of these things. Oh, and then they have this thing called Third Eye, which is 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 you've got all the hooks, got all the APIs. Yeah, like all of the tech stack is custom. Like there's nothing that's not custom in the Google tech stack. So Borg, they call it a cluster operating system.

And one of the first things they built is 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.

because it was like planet scale search from the get-go, they never had to think about... you know like oh what's the data center for like the smallest need because their need was so huge from the get-go well and there was this interesting thing right where until google the way to operate servers was to buy these really expensive sun racks the

the kind of like, you know, like mainframes, pretty much super powerful machines. And Google also had this innovation where they started to just use plain old PCs initially initially just took simple PCs that they put together on like the mainframe the CPU the the hard drive they just put it together and put it in data center and people were like what that's that's so silly but they're like look we're getting a lot better value for a buck instead of a two thousand dollar 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. 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.

uh they 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 gonna fail anyway so yeah

Let's just go with the cheap stuff that's easy to replace and just build amazing tooling on top of it that makes it nice and easy for us to operate on. So like, yeah, today it's... obviously like cloud computing is it's the status quo it's what everyone's doing but at the time again like they did this in 2003 2004 this was unheard of and probably anyone who heard of it was like what are you doing why are you why would you do that

Well, Jeff Bezos might have heard of it because he was an investor and, you know, like AWS later launched their public cloud. But yeah, it was. Yeah, and I think it wasn't just unheard of it, but I think this goes back to like Google was seen in a 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 your memory allocation work in java stuff like that or like if you know they would ask about design patterns or stuff like that and google like would ask brain teasers they they famously they would ask like okay how many golf balls can you fit in a 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

When mainstream, you know, people started to optimize for it, and it turned out that they also rejected people who were smart, but they were just not good at brain teasers. Most companies hire for the programming language that they were using.

made up maybe that was like cold fusion back in the day or like again java or python or whatever and google to this day doesn't care about what language like you're using they just want you to use and write code with and um a coding exercise oftentimes you you can use any language or sometimes you use sealer code if it's an algorithmic interview this is one of the reasons they love algorithmic interviews no no language no specific language required

Yeah. And I guess that makes sense as well, because the Google tech stack is so unique. It doesn't like it won't matter anyway. 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 also like they couldn't use or didn't want to use opted away from using normal like networking stacks and switchboards and stuff they built that from scale as well yeah why 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 like jobs and memory and cpus like across machines so the actual ip address to the machines

Like it has to happen fluidly because they don't allocate specific machines. It's broader than that. It's more like cluster level. And a cluster is like. racks of machines. So they needed that, that abstraction, they needed next level outside of like, you know, what, what's a rack, what's a cluster, that kind of stuff. Exactly. Because it's like, well, we have so many machines that it doesn't matter. And the machines again, like, because they were, especially in the beginning.

kind of like cheap and easy as like we don't like a machine will fail we don't care we'll like another machine will come in and take over and similarly they built out the google file system back in 2003 or

Well, they talked about it in 2003, 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 like the Google file system on top of that. which was later preceded by Colossus, which is what they use now. And then on top of that, they built out all of these database-like services.

things like Bigtable, like Spanner. Like there's not just like the one database because it depends obviously on the uses of the database. Like what are you optimizing for? And so internally they have lots of different variables. and like kind of database systems as well where they will have some of their data centers are like more specifically for

you know, better for a certain type of data storage and certain types of database. You know, Bigtable is more NoSQL, sparse, it's distributed, it's persistent. Spanner, you have a more SQL-like interface.

It's more important for real consistency across the world. Yeah, so as a trade-off, is it write-intensive? Is it read-intensive? What kind of data are you storing? How structured does it need to be? How are you... wanting to access it right so these are all the differences between the reasons they they have and then like as you said the distribution like like you just want it on one machine and if it dies it's totally fine or you want guaranteed

uh that are distributed then 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 were so many like 50 plus or or even more that people use and they're all like built by like actually experienced teams That's kind of an interesting side question. Why so many databases? Yeah, like databases optimized 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 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.

Wow. I mean, tape is durable, so. Yeah, there are, in the SRE book, 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. 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.

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?

Yeah, and then the fast is better than slow, which was a defining part of the culture and one of the core tenets for their product, which was search at the time. Yeah, and if anything, that obsession with speed, it's become even more critical today.

given how competitive the market feels right now. 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. Yeah, that was a 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 season sponsor, Linear. Linear actually dominated the project management responses this survey as a tool that techies love using. In fact, it was the most loved project management tool. It wasn't even close.

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 switch to Linear. 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.

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 to support that. Totally. I'm going to be spending more time with...

and your 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 slash pragmatic. And then outside of infrastructure, like Google has...

so many other custom systems I'll just name a few because I think like it's we could take forever and going into them but instead of instead of GitHub You know, for source control, they use Piper, something called Piper. That's their version control system. Instead of pull requests, they have this thing called CLChangeList. For their code review tool, it's called Critique.

uh 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 infamous tool that that inspires source graph uh so you can you can search all of google's repositories and they they do have a monorepo but

They have incredible amounts of code, and it's rapid. Again, 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 searches, they had... parts that were better than source graph's own offering i think now source graph is catching up but i still remember when i first used

source graph at uber and it was just so fast and it 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 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 20...

they started publishing numbers on it. Back in 2015, there were already a billion files in the monorepo. Two billion lines of source code. It was 86 terabytes of content with 40,000 commits every single day. It's interesting because one of the reasons why they were able to build the monorepo and operate it the way they did was also because they built it.

on the Google infrastructure that they already have. So the data centers and networking, they built out their, no, build tool, Blaze. Blaze, which they open sourced a thing called Bazel, which is similar enough, which is also really fast and really good. Yeah. And it's this distributed build system that is kind of core of how they build. It's very distributed very quickly. It enables the monorepo.

in the ridiculous scale it's at, but it's also deeply ingrained into how they do the development itself, which is very in the cloud, actually. 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 CITSI, which is the way they're programming, which is, yeah, like not on device, but...

you know, connect to clients in the cloud. These days, it seems like they mostly do that through a tool called Cider, which is actually a fork of VS Code. Now it is, right? It used to not be. Yeah, it used to be something else. It used to be a web-based tool. 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 it's looking much nicer than it did when i was there i hear a lot more people are using it so yeah again like because everything is custom everything is also so connected so like cider is deeply integrated into critique that they use for code reviews, which is deeply integrated to their CI test automation program.

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 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 GRS slash linear, and they have Boganizer, again, a custom tool.

And they have this tool called Taskflow, which is a UI on top of Boganizer for boards, Kanban, and other kind of management tooling. And then they have Guts, which is Google Universal Ticketing System. it's much more for for tech really tech support when you open like a ticket you know you can think of it at like zendesk or like jira tickets or or just any ticketing system but it's so interesting how they even built that for themselves as well

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

the same environment that you're already in because it's using the same infrastructure. Yeah. Now, one interesting thing about Google that I hear... is this kind of tech island. I think long time Google engineer or executive Urs Hertha 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 framers with like react or And for database, it'll be Postgres or something that is out there. But for Google, everything is separate.

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 very expensive to onboard. It's just... for new joiners you know they have to throw away every knowledge and

At some point, it might also be maybe just not as tempting to go work at Google if you know that whatever you use there, it's not going to be useful for your next job. But I don't think this has changed. I think Google is like, nah, you know, like they probably talked a little bit about it, but. And maybe it cannot even change that much because it doesn't feel to me that it started because Google said, like, no, we need to do something different. Yeah, I think it's more...

Like we've been talking about, like they kind of had to do something different from the get-go. And I think when you end up in a situation where basically you've invented your entire own kind of internet or like way of communicating across. computers like from the ground up and you build out stuff on top of that like yeah I don't know even know if it's possible for them to move over and that's actually so when they started

GCP, the Google Cloud platform, you know, a lot of that is what they refer to as externalizing. So they're externalizing. They're not open sourcing because it's still like they're on their own tech.

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 big table spanner

Yeah, basically everything 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, yeah, it's the internalized dRPC. They use protobuf. as like the messages for how to communicate across services and then gRPC is the way they do that yeah all all this internal tooling i think like

for 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've gotten used to it when they go outside.

they're often really kind of taken aback by how little other companies have it. For example, if you spend most of your career at Google and move to any other company, like often Googlers will look for the equivalent of like whatever Google tool had. at this company which might or might not not not exist but there was uh this uh a person that need code as his name is namadiv singh who uh well he he's

creates one of the most popular coding solutions. He worked at Google for, I think, about a year, and he said... he did a video about the one of the worst things about google and he he said how it's too many internal tools and what he said is i'm coding him

Google has this problem that they have an internal tool for literally everything. And sometimes all the internal tools don't have massive teams supporting them. Sometimes it's just one guy working on an internal tool, trying to get promoted, then maybe they get promoted and then they stop maintaining that tool.

and how you're used to forced to use it. And then nobody knows how to fix a bug. You have to go and read the code and you have to fix it yourselves. And that's not fun. No one enjoys that.

and then he said i would rather not have this internal tool in the first place because at least i can just solve the problem from scratch but now that is there i need to use this internal tool so i think it can get out of hand it 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 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 about the perks, right? Like they're just so known for...

for the perks, especially if you visit a friend at Google, I mean, it's a thing that stands out, right? I think the micro kitchens. Yeah. I mean, the Google offices in general are, I mean, I've been to other... big tech offices as well and like i mean the the kind of playfulness and quirkiness is definitely not unique to google but it's also unique to google

It's unique to Google. If you have the chance to go visit a Google office, especially one of the bigger ones, do it. It's a fun time. Yeah, people can bring in visitors. You get free lunch or breakfast. or whatever dinner probably as well.

and i mean the decor is unique like you know like i've been to many offices right like obviously what worked at uber but went to meta spotify etc like and they all have like cool decor at places but google is everywhere like the thing that reminds me the most of 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 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 that's just many one of the many decors yeah and and those are very they're quirky they're location based they're kind of theme based so yeah the mic 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. And in the Zurich office, they have one with a... One of those like secret bookcase doors. So like you'll be in this micro kitchen that looks like a Library basically with these huge books uh bookcases and one of them opens up to like a secret room in the back when i was in the london office back in 2015 they had you know the london phone boxes

They had tons of those across the offices where it was like, 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 and then like i think the per the list of perks is really long i mean it keeps changing per location but they'll be like you know from the usual kind of in the u.s the four okay while 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 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 uh like you know like like missus would come in and like you could just get it in the office which was very famous in

in the like 2000s or so to like the napping pods to some of these things but these keep changing but i think one thing that hasn't changed is which is kind of like the biggest perk of all is the compensation package which is just like wow like you know there's this tri-modal model of of like the the local companies that that that compete locally and

companies that like try to pay the top of the local market and companies that pay the top of the regional market, that's 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 will pay let's say for a senior software engineer and like what this means in terms of numbers is in silicon valley uh california a senior software engineer

could make around four or five hundred thousand dollars 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 senior software engineer in the u.s like 220 000 uh

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 so you could get more you could get less but for for london this whole total composition package which is not all salary so salary is only one part of it it will be for senior software engineer will be something like 200 to 250 50 000 pounds in in munich it will be somewhere to 190 to 220 000 euros and in in turik it will be

300 to 330 000 euros which is like a big jump again differences in taxes and areas and and again for every other location in in india and in sydney etc 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 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 things with smart people these amazing perks and you've been paid a bunch Because a company that does pay you pretty well, not this well, but they pay you pretty well, is Amazon. They give you a very respectable total conversation with pretty good stock and cash and all that.

But then you get nothing. Like, there's no perks. There's no nothing. They're like, you know, you want to go out for a team dinner, pay for yourself. Whereas at Google, like, this is not even a question. Like, you know, like there will be team events and of course you're not going to pay for it. No, exactly. Like, they take...

good care of their engineers and have done, again, like from day one, basically. 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. 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 probably have a rotation of every six weeks.

uh 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 uh they monitor the 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 issue. 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 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 2 in 30 minutes, and Tier 3 is best effort. So you can imagine Tier 3 is internal services, Tier 1 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.

if you would have been on call for the whole month which you're not going to be on call you can either choose vacation or pay like 40 minutes of your time for every hour so anyway they do a bunch of compensation they pay really well for being on call And then they limit time spent on call at the same time. You cannot go for on call for more than two weeks per quarter, which is going to loft less than other companies. So it's just like...

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. So far, you would almost think that Google is paying us to... advertise them but they're they're not no they make it easy but i guess where's the catch 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 like you can't actually fix everything yourself because everything is custom so like you can't put the expectation that Everyone can go and fix their Kubernetes pods 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. And because they invested this much in it.

Exactly. If you work at Google, you'll likely be an SWE, a software engineer. That's the big role that Google has. But Google also has tons of...

There are a lot of other types of roles and niche roles as well. SRE is obviously one of the bigger niche ones run that they have, but there's also quite a lot of other... smaller ladders and roles that they have depending on, you know, like some roles are more prevalent in some parts of the organization and with some products or product areas. So you'll have stuff like...

DevRel, they have UX engineers, which are kind of like more front-end engineers working more with design implementation. 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 like more specific type of roles and working with the infrastructure. They have tons of other roles, but the big one and... the most on paper apparently all of these different ladders are supposed to have you know like same compensation same prestige same everything but it seems like in reality The SWE roll, SWE roll, is...

good kind of a bit like higher class essentially and part of that is because when you're in SW like because it's kind of the default go-to role that's the one where you have the most internal mobility you can work on like any team 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, ENs, 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 uh so it's basically you can think of them as like a spectrum where you have ems on one side where it's you know the person like you know they have direct reports they take care of the team they do all the

EM things. And then on the other side, you have an IC individual contributor who's a tech lead. So tech leads are in charge of, you know, overall architecture, tech. aspects of projects, of products. They'll make sure that, you know, like tech decisions get made. They have the top say.

they get appointed by 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 yeah but so my understanding of this role because we introduced it at uber and it was influenced by google i think we had a google svp come over and then it was introduced

My understanding of the idea of this role originally was, well, first let's talk about levels. 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 and la principal uh l9 distinguished and l10 partner so like a fellow yes google fellow google calls a fellow uh i think microsoft calls a 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 else l7 will be a senior injury manager which is the same as the senior staff. L8 is director, which is now principal engineer. So the same level, the same compensation, and it goes to L9 senior director, L10 VP, and then there's an L11 on the manager track.

uh for senior vp which does not exist on 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 L6, people need to decide, are they going to... be on the icy ladder try to make their way to l7 l8 and so on or switch the manager ladder but at some point you kind of like get stuck but maybe not necessarily an uncomfortable way so like when people get to like l7 or l8 you know you're not really gonna go

higher. And at Google, 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 the tech lead de facto, and they could manage their team, that small team.

Like 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 duper 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 a and as an engineer you're not doing as much work as before a little bit less

And as a manager, you're managing a team so people can get frustrated. But for Google, it worked, as I understand. So detective managers are typically, they're not like... looking to go to that next level it's just more recognizing that hey they're doing both of these pieces of work when you're judging their performance don't compare an L8 tech lead manager to an L8 IC who will be pushing out a lot more code

Yeah, my understanding also is that this role is especially, like you kind of mentioned as well, in small teams. usually like more of like 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 like 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 like but it's like you know a couple people rather than you know a full established team that has like way more cadence and way more kind of em type work there 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 ones. 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 a fun fact about the levels. So entry-level software engineers start at L3. Those are new grads.

and by the way the whole l thing as i understand it is to do there there might be l l1 and l2 within google is just not for engineering because they're also salary levels as well uh phds uh if you have a php you start l4 minimum so there's uh one uh some other companies do the same thing by the way who hire for uh phd students but that was an interesting thing for me to know uh at uber when i was hiring interns we heard

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 do algorithmic coding interviews. So there you go. 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 uh didn't actually go to university but like very very entry level uh but like obviously the there's expectations also on like all the low l levels which is you know, across the 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. Well, yeah. So this used to be the case, but it's kind of changed. So like Google has this, had this thing, well, 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 uh 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, 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 ship 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 nicely into the performance reviews and promotions at Google. The performance process, it used to be called perf. And it used to be kind of...

You know, one of those things that is, like, people famously complain about. But they actually did a big rehaul in, I think, 2022, where they moved to a new system called GRAD, which stands for Googler. Googler review and development. 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 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 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

In December, you're going to get like a final like output in February and you will get the bonuses of March and either you'll be happy or you'll be unhappy. Yeah. And I think one of the differences like. I think the perf process was like way more heavy on you as an individual doing all the heavy lifting.

where you had to spend yourself a lot of time putting together reports and 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, it'll depend on your manager, it seems like. Yeah, and so Google used to be known, and I think they still kind of are. They're trying to be pretty fair in how they do performance reviews and promotions, and we'll see that with promotions. I mean, the manager still has a big say, but they're trying to focus on outcomes, outputs, etc. They're doing more. There's a lot of training for managers going on, anti-bias training.

all of these things and the the process is really well documented and it is more heavyweight than most big tech companies and people take it seriously well i mean after until a few years and i'm sure after a few like after like you know five ten years before just probably like all right here we go again especially if you're not wanting to move up and 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, as I understand, this is kind of an 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 meets. You're going to get your target bonus no matter what. It was actually with Perf 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 outstanding impact, which... like maybe eight percent of people get is what i heard so like you're doing amazing essentially uh 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. 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 all submit their ratings, there will be a calibration where it needs to not fit the curve, but it needs to fit the buckets.

there oftentimes needs to be certain number on the lowest buckets and maximum minimum certain number in the lower 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 uh well 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 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 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 slash eye-opening but as an engineer not much you can do beyond you know document your impact have a good relationship with your manager and hope that that manager stands up for the people on their team yeah and i guess i mean there's some aspects of like you know the type of

you know, work that you do and kind of extracurricular activities, if you will, that will feed into and look good on these performance reviews. And Google does have a lot of... opportunities to do that kind of stuff so like there's lots of mentorship programs and not tech support but like uh helping out with onboarding helping out with

coming up with what they called code labs. So again, because Google is so unique, like there has to be a lot of onboarding and kind of knowledge spreading internally to on... to teach people how to work at Google, essentially. So that opens up for a lot of opportunities for people to help up with that kind of stuff. If you like working with that kind of stuff, like kind of tech writing and like tech learning.

Um, google has a lot of opportunities for that yeah probably a lot more than most of their companies it sounds like they actually appreciate it as well so i mean obviously you need to do like do do good work i don't write sloppy code and like it's full of bugs all the time and then do all the extra curricular things

but when you want to show that you're ready especially i guess this is true for especially the the levels of like we're talking l3 l4 l5 above that i mean it's kind of a given that you do all these things on the side in fact 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 yeah there's 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 like anyone can see and review anyone's code uh but the code review process is built up so like every every change list every cl needs to get reviewed by three different it can be the same person but like three different roles one of them is uh the code owner and like it has to be another engineer like 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, you know, all the best practices and conventions and styles and all that kind of stuff. They have this way of earning readability in a language that, you know, has to like, there's a whole process for it.

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. Yeah, exactly. And like do a certain temper of 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 person people in that org in order to like That's a good trick to know about. focus on readability, just look at open CLs across the... It's so unique to Google, isn't it? I don't know any other company that does this. At Uber and other large companies, you do mandate code reviews of a code owner, but...

nothing to do with readability. 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 like 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 like 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. It's an interesting approach. So outside of performance reviews, the other one is promotions.

And promotions are different at Google because there is this thing called a promotion committee. So my understanding is that Google has been really big about trying to not be biased in promotions. The way promotions work at most companies is when you're up for promotion, the group of your manager and your manager's peers all get together.

and they're like all right is you know johnny ready for a promotion and they all kind of talk about why you know your manager says why they think they are and then their peers say like yeah we agree or we don't or what about jane and 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 is 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 etc so there can be some biases there and what google has them for a long time is they they said all right let's just make this whole process unbiased let's have a promotion committee where no one knows you like it's it's not your managers but it's like this group of like senior or staff plus engineers and other engineering managers at a different part of the org

And they just get a written packet, a little bit like their hiring committee that we're going to talk about. they decide your promotion based on that. And what this means, they don't know anything about you. They don't know who you are. I mean, they will understand the context, but they haven't worked 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.

well, 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... uh you know 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 is big on impact so

they said to be promoted to L5 Senior, he needs 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. And so, so he had this like series of bad lucks where, and then, and then, and I think year four.

He wrote in this article, quoting him, my quality bar for code to drop from, will we be able to main this thing for the next five years? So can this last until I'm promoted? I didn't file or fix any bugs unless they risk my project 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 freaking promotion. And in the end, he quit Google.

But this whole story showed how it's super easy to fall into Google into the promotion trap, which is... i need this project to get me promoted and that's it and he actually explained and in the end i think he said like what am i doing here like why am i doing this and he's smart a smart guy he built a really good business afterwards but

It felt to me he just got unlucky of how his teams changed. But also, this is where we should talk a little bit about promotion-driven development that is very real inside Google because all the incentives are there for it. And, you know, there's this joke. uh that goes around uh of why google has so many chat product products i think you know they had google like they had google wave gchat uh and

And they keep changing the 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 like 300-ish Google products that have been launched, but they have been killed. Yeah. I mean, technically not run by Google, but... No, it's not run by Google. It's just...

That one was not a Google project. That would be funny if someone internal at Google was like, here's all the things we're bad at. 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.

Again, because look at it. Yes, we can make fun of how Google discontinues Stadia, a 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. The way I think of it is that...

Google has had like 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 is not really around the same way it used to be. But there was this, yeah, 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 but 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 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 you know convince engineers and like do this whole thing of like getting head counts 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 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 their their design docs culture is just really really kind of famous

to the point of apparently whenever you start a project you you're expected to write a design doc which is a google doc which has like certain sections and you know these are kind of like loosely handled, but it's things like context and scope, goals, non-goals, an overview. You might have your architecture diagrams, how it impacts other systems, the structure of your changes, maybe rollout plans, lifecycle, and many.

alternatives considered some other companies have actually started to to use similar approaches or maybe just naturally spread it's often called rfc request for comment but at google so every like 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-driven 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? I just realized that consensus is... important because they're they're also big right they're the biggest and probably the biggest like engineering culture of this quality yeah i mean i think uh 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 like, oh, we're like redoing the same things or. building something that like oh had you talked with any other people you had realized that like that was either like not needed or not a good idea or like it has a use case of one like you're building something for yourself

So that could be a part of it. But I also think in terms of just like 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 rock star mentality that, you know, you're the rock star engineer who just like goes off and does his own thing. It's very much more like... collaborative teamwork team spirit enable everyone to do great things and so it probably like i would assume it comes from that as well like part of being able to keep the googliness is to just be very open and there's actually like we've mentioned the SRE book there's also an SVE book

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

but yeah yeah it's pretty big yeah and they they write about this like that book in general like goes through like it does talk about a fair amount of the tools that we talked about like the the piper and the monorepo and the critique and all that stuff but it also has you know a big section of like you know 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 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 you know they famously run an experiment where they removed all managers

and they figured out what's going to happen they didn't know like they they thought the 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 like They've done a lot of research and they have published a lot of these things, but...

You know, at a lot of companies, I think as a developer, you get really frustrated for, because it's oftentimes the business, you know, 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. 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 that 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 storage 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 but the people up there are software engineers the founders are are i mean they were phd students but they are software engineers even though the founders are are are no longer uh 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 is it's not just code so even when it comes to like ai uh they're they're not going to be like falling for what everyone else is saying that i don't know like hey i want to play software engineers like if if it would google would have zero of them but google knows the value of software engineers yeah and the limitation of them

Yeah, exactly. But I think that also, like to tie it back to killed by Google, like, like, that's probably why, like, you know, you have a lot of freedom to try things out. And then you build products that might not make sense. And like 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 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 OKRs. Objective Key Results. Now, if you're a software engineer, you probably like...

and you worked at a mid-sized 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? 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 of how they operated so yeah like objectives and key results objectives is like You know a kind of more high-level goal of like this is what we want to build and then the key results are Specific measurable things that you can measure

in order to know that you're moving towards the goal. Some examples of when they introduced OKRs in the beginning, back in 99, like their first objective was build a great search engine. And then they... had they came up with their key results 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 a 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 is... 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. We can't use normal DNS. We need to invent our own things.

etc etc so i i'm gonna be honest like i'm always a little bit like suspicious about okrs and google like To me, like, because it is the book Measure What Matters was published in 2018. And from there on, it's really blown up. And I think everyone's like using OKRs because it like 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 use because you know like it started with page rank they did something that everyone wanted And I wonder if OKRs is something that, I mean, it's probably, it works, but it could have been anything else.

whenever i used okrs at least and you know we we tried to use it like having a clear goal and 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 a microsoft

example when i worked in like 2000 like 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 agreed to add our codecs 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 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. Yeah, I mean, it might have helped in the early days. I can imagine maybe convincing stakeholders or early investors. And each other maybe of like, okay, what are the things that we need? And like, end of the day, OKRs is a tool, right? 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 and very bad ways and you can use tools to create 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... The tendency of like, oh, they use this, so therefore we should use it, and then we'll be Google. Yeah, that's not how it works. Speaking of OKRs as a tool for communication, communication in general at Google.

is is and at least has been very open and very transparent so historically like this has changed a little bit now we'll we'll get into this but like culture is shifting across

the industry, including Google, in late years, but historically it's been incredibly open and transparent. Again, like, maybe it's... like part of it's being the the monorepo and the fact that everyone has access to everything anyways but you know since pretty early days uh google used to have the or still has them these weekly

company-wide town hall, all-hands meeting, check-in type thing. It's called TGIF. So think Google, it's Friday. That was the original. And then like with the... engineering team being a company really because this is for the company not just engineers uh 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 think google it's to thursday yeah but basically uh like it used to be more like sergey and larry on stage talking about stuff doing open q a's You'd have different teams come in and 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 out 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 a company. So it's a fun event, right? Like it's worth showing up. 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 tickles 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. You'll have those. And then internally, they, you know, you'll have, you know, different departments and different teams organized in some way. But it's like, it depends. There's reorgs very, very frequently.

So you mentioned like teams can just evaporate and cease existing, which is because of reorgs, because of, you know, 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 uh 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. 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.

you're like you know like the bigger org and then your your teamly you'll have a weekly team leave for sure so like every week you'll have the tgif or let's just call it 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 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 org and the design

Okay, so a bit of a culture shock if you come from like a 10% startup. 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. You're trying to say this is a downside of transparency, right?

because it's cheering 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 lap because they were expected to show up and on the meeting room people will be coding on their laptops like i i don't want to be here but i i need to show up because the svp is here and whatever but

like what's what's the alternative right because if you if you're saying we are transparent and we want everyone to know you know like we want everyone in google to know what the ceo thinks like with every engineer to know what the cto thinks you want to know what your director thinks and

And just like what's going on, what people are working on. 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 assembly next to you? That's not your problem.

But I feel those are the two extremes and like 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 will know, it's just like, there's all these, oh, you've not been in that meeting. They actually told us they're like, oh no, sorry. I was trying to get some work done. Yeah. And, and just like, it can probably be pretty overwhelming. Yeah. But I mean, they are good also because, 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. These days, apparently, 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 uh like you can work on something that's like primarily based in the u.s in mountain view but you can be in and 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 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, Noogler, ex-Googler, ex-Googler. Re-Googlers is apparently a program where...

Google talent acquisition reaches out to former Googler saying, hey, you love Google a few years ago. Want to rejoin? And apparently it's really successful. A bunch of people come back. 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. Oh, interesting. I didn't know there was a program for it. I know plenty of people who've left 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 as 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. Yeah, I mean, I love all the names for the different Googlers. I have a few, 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 the little propeller on it. I actually, I have this, I got this little Android friend when I was interning there.

Wow, that's a collectible now today. Yeah, exactly. So this is a little Nugler hat. It used to have the propeller, but I broke it. Wow. It has a little Google backpack. You can even open it. wow 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've we've talked a bit about the the playfulness and how it's it's just part of the culture

It's like the offices, things like this. But what is Googliness? Is it like kind of fun, quirky, geeky? What would you say it is? They go through this in the SVE book, actually. uh but like they have a couple of kind of like values or characteristics if you will uh of being googly and

Maybe the term being googly is somewhat being... It might have been bigger previously, and now 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 know you try things out so that needs to be a part of of who you are There's a lot of values feedback, which ties into, you know, the perf, now grad feedback cycle. Challenges the status quo.

I think we touched on this as well. Like that's also been like from day one with trying to get people who look outside the box and really accept that, you know, things could be better. Puts the users first. is maybe somewhat of an ideal rather than... Yeah, that sounds pretty ideal for me using Google products. Yeah. Cares about the team.

And yeah, this is, again, goes back to the, like, 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...

Like how Googlers can, you know, they have ways of sending like an hour of massage to someone they think did a great job. And then there's the peer bonuses that are... like more proper like monetary like not like huge bonuses but like a bit and like those really incentivize you know doing things for other recognizing things for others so there's like probably a few hundred dollars or something like that i think so yeah i can look it up but

Something like that. Yeah, but I don't think many other companies have this. Like, you know, some do have that 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. Yeah. And then the last googly thing, at least on the list, is just 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 tenants from very early on to just... I think it goes, again, with the status quo. There's plenty of examples of big corporations starting out with good intention and then maybe... getting lost along the way well it could be lost along the way but also it could be like when you're big enough size like it goes back to like 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?

the evil country or or if two countries attack each other you know like both sides will think so all i'm saying is there there could be a point where by being involved you you can be uh part of it so that that might also be a one part because that's also one thing that google is being attacked on for for example uh 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 the alternative is to pull out and give up on the market. And also, I guess this goes back to do the right thing. It's in this book. I just read it. But the right thing for who, right? Because...

As a software engineer, what does doing the right thing for 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 are 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's a little bit of a boogie there

Yeah. But to be fair, 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 unconventional. 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 always only see 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 through to uh

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 in into pushing to make sure that uh you know that the systems are work that they're they're repaired Interesting trade-offs. 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 2008. Google App Engine. Yep. That was an early user of it. Yeah. Because, like, again, like... 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 Basel. 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? Yeah, it's an interesting difference between GCP and other Clyde providers, like where it started from, so to say.

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 a... 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 AC2 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 site 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 assumed that they were not profitable. And overnight, Google App Engine changed their billing to be like 5x as expensive. And suddenly before... they they said like all right like you can deploy you know your code and we will auto scale you don't need to worry about it and now

They had to worry us about like index rights and like they exposed us to our infrastructure and everything became a lot more expensive. People revolted and they gave us 30 days of notice.

which was like 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 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 i was really like miffed

Now, I wrote a really nasty letter on the customer support form because, of course, the only support form was a Google groups or Google forum or whatever that was. That's where the official engineering team worked with us.

you can see that google is terrible like dealing with paying customers it's almost like they don't they don't care them it's almost like they despised them a little bit not always but but in a weird way like most companies will be you know like put them at the top and google just trees 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 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 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 uh what like you can trust it and aw

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 all runs on it. When I was at Microsoft, they just bought Skype and I was in the Skype org. 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. Yeah, so they've had a few, from my understanding, my research, 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've externalized their product, as they say. It's very much like, you know, Kubernetes is not Borg by choice. And Borg is set up for planet scale. you know what they refer to it as yeah and that is not most use cases it is very specific and they've made a lot of engineering decisions that you know like with

Again, everything from networking to databases to literally everything is custom. So does it actually make sense to just externalize that? Not really. But that also means... Well, if that's what they have, if they want to win in cloud, that would probably be a thing that they should do in order to really boost the platform to be as good as possible. But then again, 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. Yeah.

i i think the question is if they want to win but i i got this intro because i have been asking a few googlers or gcp people about this like what because I still remember inside Microsoft, people were not having music gesture, 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, you know, Microsoft clearly could be number two.

with azure because internally they're pushing it just as much as externally so they're they're gonna keep improving it but someone at google an engineer told us how like i i have heard

A lot of Googlers say that their internal infra is superior. And this 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 the entire development process from like you know like 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 percent of the time and other 20 percent will be hardware sales and like some service sales and all that it's probably more important that they grow their business as opposed to just growing the cloud the cloud or configure it out and be

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 and maybe this is a this is not a they don't need to win at everything

Right, like only in the important search with self-driving, they're seeming to be investing heavily. LLMs, maybe those are the things that they really want to win in. I mean, speaking of trade-offs in general, I think. If you really think about it, and if Google were to move everything to GCP, I guess because they built out... you know, their build system, their monorepo, all their developer tooling on top of the same infrastructure. It's different.

It just might not work as much, especially when you have like all the permission systems that are like built, baked into internally. Who knows? I think it's trade-offs, right? Yeah. It's probably a good reminder that like you don't need to. like you know like there's no 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. 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 is like it just like it happened this way because it was so early and you know they made some fairly early acquisitions and strategic pivots into you know

Like, 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 so... It's been so interesting to learn about it. And 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 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 they're just taking whatever is there. They're not reinventing that part because why would you? Snap. 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 there's just so much internal mobility inside google and there 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 you're not in a bad performance standing you can pretty much move teams anytime as i understand and 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.

uh if they've been there for like 10 plus years if they've not worked on several teams and and something and sometimes changing teams like a few years in a row like almost like and 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 but still yeah i think there's a there's a slight thing so

Just to mention, during the pandemic, obviously, Google started working from home, just as 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 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.

Oh, so they're able to do internal mobility. Previously, you need to be in the same location. Now, they could remotely join that team for a while, at least. Exactly. I'm pretty sure that's going to go back to where it was before slowly, but surely. Yeah. Cause 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 at least two, three, four times a week. Probably depends on where you are. And I know there are some exceptions. I'm probably your manager. Yeah. Yeah. and how important you are to Google, probably. Speaking of exceptions, there is this concept of singleton. 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 like 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 like from that team working in that office yeah and i guess it only makes sense these are 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 your expertise. It's not super common, and it's definitely an exception rather than a rule, but it does exist. 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.

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 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 rewrite, there's usually migration as well and then deprecation. And that's a good thing. The bad thing is that this is not usually the work that most engineers would want.

sign up for you're excited about building the new thing but again there there's that thing when you build the new thing how are you going to get the customers over there yeah but i i think it's it's like on on two sides there because they have the mono repo they have direct access to like uh they can actually make they they do have a tool called rosie uh which is a tool for doing like large-scale uh migrations 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 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 don't need to 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

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. 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 did, 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, like...

It's probably going to be a bit more nuanced than that. You do need a manager, a new manager who will be supported. 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 could have manager buy.

and all of those things. 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 and 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...

The tech stack is obviously the same. 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 you kubernetes at this new place rather the the thing that you're gonna 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. 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 projects 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 a very heavy user of this front and front. framework. TensorFlow for machine learning, it's so widely used.

i mean we cannot not mention the llms uh with the that was not the technology but the paper that that kick-started all of this with attention is all you need the go programming language chromium as the the browser engine and just just so so so many other things i think you know meta has a bunch of strong contributions in Microsoft's in certain areas. But I feel Google has a really wide range from like backend frameworks, machine learning, frontend 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.

Yeah, and inspired people as well. And 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 the just like learnings of like what what works what doesn't what should you take from this what should you not take from this and I do feel like

And I was reading through some of their old tech blog posts as well. They had a tech blog for... or maybe just a blog for like gmail like the gmail team had a blog that they wrote from like 2007 to 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 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 yeah it could have been

uh and i think now it might be a bit more controlled and there is no like one google engineering blog or i don't even know of like some other teams but still for the open source for sure and for the paper so that the research and the open source is there and i mean to be fair on conferences google speakers do show up and they 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... you know flutter is another good example like on their those area they're kind of a lot more active of sharing like all right here's how to use it how to build it etc

But yeah, I still asked this on the podcast episode about Kubernetes. 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 lessons, some boring 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 uh very good for the 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 this technology that is the winner Kubernetes. They have a huge say in it. Like, yes, it's an independent organization.

that's that's there but most of the contributors are still at google so they actually have a pretty good say in that so 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 that's a cool idea why not

And then you can justify the business for it. So like, 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. One of the things, again, like...

we're doing this research from the outside looking in right like we're able to get to the stuff we can get to and we've talked to people um and one of the things that has come up is definitely like the culture is shifting Like there's like, you know, the winds of change in Google following, you know. Partially just like the vibes of the industry as a whole, but partially very much internally. Also during the pandemic, you know, they had some big leaks. So like they stopped.

some internal transparency in the all hands and the full access to everything going on. I know that's been restricted.

yeah so so let's let's talk a bit more about this because i feel this is like the google of today basically we've kind of arrived from like where google started how they built like all all these cool things to what is google like today from from all that we've gathered and i guess maybe we should just like reflect a little bit on how the whole and as you said the whole industry has gone through a massive change which was

i mean there was a couple of like kind of like left and right things first there was a pandemic which the whole world thought would be 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

of 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 percent 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 a hiring manager who had an 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 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 there was i think it all started with the fast bankruptcy one click checkout server 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 bootcamp 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 was this went up all the way to 2023 big tech had big layoffs and google had the first ever layoffs in almost the first in company history in 2008 they did like a three percent layoff because of the financial crisis they then did some layoffs after they bought moral in 2014 but

Since then, they haven't really had any layoffs. And Google used to be known as the place with great job security, work-life balance, almost impossible to get fired if you do a minimum good enough job. then they did like six percent 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 is 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 but still it's it's like you know it's a company at some point you might get fired and you'll get a good severance but they'll tell you that it's game over 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. So one part of me is like, well, I mean, it's kind of sad that it's over, but my other side...

And at least startups have a chance. At least they can point to one thing Google does not do perfectly. Yeah, I mean, it does seem like they had a really good run for a while. And I'm sure there's pockets at Google that is still probably... 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 um so in terms of like uh 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 not to the same extent in terms of the shorts. But then all of a sudden, now YouTube has and kind of has to push for shorts because now they're in the attention war.

And similarly with, you know, I feel like there was much more in 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. You know, Google search results are like a lot of them are sponsored. This doesn't feel great. So I think 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? Well, but I think this is the part where... So I saw Manu Kornet, who... writes all the all the these comics he was for 12 years at google he then quit google and and joined twitter and then unlucky for him he joined right as elon musk bought twitter but he joined he told me that he they love google because he

over the 12 years i think from 2010 to like 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 or whatever uh and you'll 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 my And 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, 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.

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?

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 which is bonkers because they're now so big they're making like 300 something billion dollars per year but as long as that happens things will be good right there's not going to be large layoffs there will 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 really 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 it...

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 percent and by not saying

by saying no to them, you cannot do that, then there's all these things that trickle down as a result of that. Yeah, it's growing up in a...

in an industry and in an economy that only goes up. Well, 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 what? 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.

this question because we went from tech companies being kind of underdogs you know like there there's people who still remember facebook just being an idea or like you can be used by teenagers same same thing with you know older older listeners or viewers when google did not exist to like yeah they they won and now the question is how how do they keep winning and 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. Yeah, and it is, 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 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, you can, your whole day can be completely thrown off. 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 pockets of innovation, right? AI is still up for grabs. There's a really open battle between all the leading AI companies, including Google.

Google, it's kind of fun and exciting. But there are 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 turn.

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 car 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... 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 it's a 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 a startup. Or if you're lucky, it'll be a team inside of Google that has a Greenfield project. Again, like all of those things happen all the time.

But yeah, 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 coc your work or or your your like every 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. Obviously, there's always innovation, but 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 it's, 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. 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 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 super hard. But for those there, what could be a 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. 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. 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 this ml framework that is out there that makes you in demand for other places right exactly so if you like keeping up with the industry like keeping up with the tech industry's cutting edge

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

And yeah, then Google is probably not for you either. That'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 yeah exactly like reorgs are a staple yeah i actually i think i talked with someone i think it was google who said like i had like you know like seven managers in a 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 and then on the flip side of that i think if you if you do like trying new things and innovating and trying things out like i think google is good for that as well you know like you mentioned they did You know, 20% time was way more of an established thing in the past. Like they didn't completely get rid of it. It more phased out. It more became like 120% time where you can't 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 startup-based, completely new apps that very quickly 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 like there is the like killed by google is definitely true but it's not like all of it's wasted like they have 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 probably also not going to look the way that you imagine it to look like. And if you get in love with your idea. And, you know, the whole I kill your darlings thing. If you're not good at killing your darlings, then probably just do startups instead of...

Google. Yeah. Well, one thing I'll add is Google is very, very good for one thing, which is the pedigree. So if you have, if you worked at Google for, let's say, you know, sometime, even a year. It's one of the most recognized brands even to date. There are some other companies that keep going up and down. Right now, OpenAI, for example, is also very, very recognized.

course you know meta but google has been like this for almost 30 years almost since the 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 that 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, assuming the same number of candidates applying every year. So it is kind of getting harder to...

to get into google so it's not saying for granted so like my suggestion would be is if there's a reach out from a company like google It can be a challenge to just go through an interview process even if you have no intention because your 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 they're super hot open ai 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, RAM, Stripe. So many of them will be from Google.

like 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 with no proven tracker just go 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 ex-Google network is very strong. The fact that there's a Zugler 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... your your resume and your opportunities for for like a decade or even more to come you can always say your ex-googler and the thing is not many people will be able to say that globally so especially as a software engineer so yes one more thing to keep in mind

i know it's changed but like there is one thing of like 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. 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 you meet our 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... conversation how we're excited 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 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 six 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 up with a lot of a lot of things that come with with large companies uh 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 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 would probably hate this place. Probably. Yeah, 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 like went to the office and visited and like in just like four or five months like I recognized like almost no one and the people I knew it's like no they'd already moved or

Actually, this used to be the case where the London office used to be kind of a holding hub as well. People would be hired and then go to the London office for a year, and then they would move to the Zurich office, because immigration-wise, that was easier from 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 no 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. 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, 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 company where a lot of people retire from so this is the company where it's

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, you know, they'll go from engineer to TLM, sometimes to PM and back.

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 they as it does retirement doesn't necessarily come at

around 65 or whatever the legally mandated is, a lot of people will say, I'm retired earlier because I have saved up enough together with Google's perks and pension program and whatever that I will now have a very comfortable life. people in their you know like 50s or so say that they are like 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. uh companies like this so that's 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 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 as we called them but i mean i think it just shows the tech industry is changing you know now there are stable companies to 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 in some of parts and in some pockets very exciting and and doing a bunch of interesting stuff we've just spent how many hours talking about about three

Yeah, we could probably go on. And 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 will have lots of links. And again, because Google is so open. A lot of this data you'll just be able to find. You can find the papers we've talked about, you can read the books we mentioned. 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 for once 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 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 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. Yeah. Let us know your feedback and hopefully we'll see you in the next one. This was our Google Podcasts episode. If you'd like to get even more details about Google's NGO 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.