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 engineing point of view? We've spent months researching this topic to bring you the most detailed deep dive to date on Google's engineing 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 Gerge, your podcast host and author of The Pragmatic Engineer. Hi, I'm Alen and you may or may not know me as the researcher uh of the pragmatic engineer. You might have seen my by line in some of our deep dives and survey articles. Uh, and today we're going to try out this new format to bring you a deep dive by talking you through uh, everything Google. So, I I was an intern at Google for a couple months back in 2015. I was based in the London office. Uh, worked as an a UX intern actually. Um, that was before I uh, worked as an engineer after that. Uh so I have a little bit of of like inside vibes but not that much. >> Let's start with everyone knows Google for sure. You you cannot not know it but what are some interesting stat 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 the latest numbers there's 182,000 employees across all of Alphabet. Uh 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 work, there were 25,000 engineers. I think size-wise this makes them similar to Microsoft in total employee count for engineers. A bit unclear. Maybe Google has more maybe Microsoft. Probably similar to Amazon, but Amazon has weird numbers cuz they kind of mesh the the workers, but they're 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 I think the question is with Microsoft, but I think when it come to prestige uh compensation, uh they're they're easily number one in in this regards. Uh scale of of of work that 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 3 to 4 billion people per month use their services between search, Gmail, YouTube. I mean all of these are marketing services right I think search is more than 1 billion people per day which is kind of one like every I think nine person in the world uses search uh YouTube has 2.5 billion monthly which is more than TV viewers and then Gmail has 1.8 8 billion active users and I I'm pretty sure looking at my my newsletter about 70 or 60 70% of emails are are Gmail. >> Yeah, for sure. I' I've seen the same stats and like if you broaden out the Google Workspace apps like including Drive and Docs and Calendar and stuff, they have over three 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 5 billion videos on YouTube. Not all of them are necessarily like up and available. like the latest numbers 360 hours of content is uploaded every single minute. >> Yeah, that 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 just large numbers. And I think like you know this is the thing with Google, right? Technically it's not even called Google. Technically, it's Alphabet, which the biggest part is is uh Google that that still owns things that like Chrome, the leading uh web browser, Android, which is still the the leading smartphone platform globally by a lot by about 70%. In the US, uh iOS is now getting bigger. So, that can be a bit 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 is Whimo which is 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 is engineering so they're engineering offices there's about like there's more than 25 ones, but the kind of the the big ones that we we should definitely mention, headquarters, Mountain View in Silicon Valley, >> the Google Plex. >> The Google Plex. Yeah. Really cool office. Like really cool u kind of perks. Android figures. It was so cool. I I was there last year. Addiosmani uh took me around on on the Chrome team in New York office also big one. Seattle and they have a lot of offices in smaller ones in in the US. LA, Pittsburgh, Boulder, a lot of like specialized ones. >> Cambridge and Massachusetts is pretty big as well. Yeah, the the Seattle uh Seattle office is definitely one of the bigger one. And uh you might hear it referred to as Kirkland as well because Kirkland is the suburb of Seattle where it is and it's um yeah, lots of cloud is based there. >> Yeah. And then Europe and the UK have large offices. The biggest one known in Europe is Turk. It's actually probably Google's European HQ in terms of engineering if if you will. And a fun fact is that Turk pays almost as much in compensation as in the US which is really really interesting. A lot higher than their Europe other European offices. London is another huge office. Dublin a big one. Dublin I think might be bigger than Zurich in terms of people but not necessarily engineering. >> Ah >> like they have a lot of sales. >> Yeah. Yeah. Makes sense. Makes sense. >> Oh, you're right. I actually used to have friends uh nontechnical uh who who were in Dublin that Yeah, that was You're right. You're probably the big but I was thinking engineering. >> Engineering is the biggest hub for sure. >> Munich is a big one for engineering as well in 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. Like the thing with Google is they do have like some smaller bits. For example, even in Budapash, Hungary, they had a very small engineering office. I think they still have, but it's it's tiny compared 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 uh grown a fair bit. It's like a few hundred people. Fairly big on the engineering side. work a lot on uh video meets and calls and stuff >> and a lot of US tech companies would stop here but Google obviously being Google they they have engineering offices uh a lot of other places Bangalore and Hydrobot are two massive offices in in India >> they've grown so much as well like they're and growing like those are like a lot of the open positions are based in India >> yeah we we had an issue with that when I when I used to work at uh Uber as an injury manager. Uh we were hiring in Bangalore and what we found is we had trouble hiring senior engineers because whenever we'd extend an offer and that person was interviewing at Google, Google would offer 10% more than whatever we did. Always 10% more. So after a while back, this was back several years ago, but the team kind of backed down and they started to hire like less experienced engineer. It this was a big kind of hiring fight. But there is this thing about Google, by the way. If you have a competing offer, Google and they want you and then you're like senior and above, Google almost always will offer more. They don't care too much about their internal bands. Again, over time, this might have changed and for more junior positions, this could have changed. But I had a director of friend who was in the situation uh between uh having a competing offer at uh Meta and Google and and and it was really high already and then Google just really wanted this person and they just offered more. Google like when you become in demand this is a really interesting situation but it's it's kind of an open secret on on the job market and then they have offices Tokyo, Japan, Sydney, Australia and probably every kind of major city and and you'll have like so Google has so many offices right and engineering can pop up anywhere. >> Yeah, exactly. They they have a pretty big one in u Brazil as well in Sa Paulo. They have a lot of search engineers. But it's also it's funny um because one of the stats for Google is like they've always had such good revenue. So like back in in 2024 there was $350 billion in revenue. 75% of that comes from ads. And I think Google like they've done good for themselves because they figured out such a good revenue model from day one for themselves. So they've always been able to offer all of these high salaries and pay for so much stuff. >> I'm going to challenge you a little bit because I so like we know like Google is insanely profitable, right? Like there is no doubt about it. However, when we look a little bit closer at the unit economics and you we're going to we're going to quickly move to engineering, but let's talk about the kind of where the money comes from. Google's like profit margin of like you know on $100, how many dollars is profit is 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 Aen they do about $60 or 60% profit rate but those companies don't pay as much as Google does for their engineers. So there's this interesting thing where there have been companies earlier who have found out similarly really lucrative really good business models again like with Mastercard you know you you make a transaction they take a percentage they built out the global network boom profit but they don't compensate engineers or they don't they don't kind of treat engineers the way Google does which we're going to talk a lot about. So, I think Google did something interesting where like by the end of this episode, we're going to have a better idea of what actually happened. But there's two things, right? Either they they created this new thing where they became so profitable because they treated engineers so well. Or despite being so profitable, they're treating engineers really well and maybe they're becoming even more profitable and now a lot bigger than Mastercard or or Visa or other companies. Now one interesting thing that I I wanted to bring up is is when you joined Google there was this uh note from a founder who got acquired uh by Google called Treyas Banzal uh 10erson startup got acquired several years ago and on a blog post uh this is what he wrote uh he wrote working at Google is like having a second passport go to animate your 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 100,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 is just slightly slightly different. I thought this is fascinating. So like you when you join Google you have suddenly access to all the offices you you 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 and to all of the the people. I think this is something that a lot of people don't realize from the outside of just how it's it is one company but it's also more. >> Yeah, that actually resonates quite a lot with my exper 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 is like like it feels more like you can talk to other Googlers and it feels like they would be at like working at a completely different company but you you're in this like alternate reality bubble where when you're in the bubble you know so many things 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 the passport to that really. It's a 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 customuilt everything. So unlike almost every other startup or company that has some level of standard tech stack that the rest of the industry uses, Google just uses their own stuff and it works really well for them. uh 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 algorithical interviews and they kind of I guess the perception of of how Google having a hiring bar made it go mainstream across the tech industry and then they also invented roles like the SR role which is now kind of pretty widespread across other companies as well. >> Yeah, exactly. Even though it might be called something slightly different with like you know DevOps, reliability engineering etc etc. One thing that is very unique about Google is how many internal tools that they've built. Borg, blaze, piper, critique, code search. We'll talk about a lot of them today. >> Yeah, we're going to get to them. In many ways, Google was one of the first modern software companies and how we think about them today. Not just all the perks that they provide, but building best-in-class internal tools. They also pioneered something that we take for granted today. Great data tools for product and engineering teams. Google was one of the first companies to take analytics, dashboards, AB testing, feature controls, all of them together seriously. They built advanced tools and made it available to their thousands of engineers and data scientists. This was the approach that enabled a fastmoving 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. Um, for the last 15 years, pretty much every major tech company has had entire teams of people rebuilding this kind of feature flagging AB testing stack of tools internally. >> But now something interesting is happening with the latest generation of tech giants. Rather than building these tools, companies like OpenAI, Antrophic, Figma, Notion, and a bunch of others, they're just using Statsig. Static has rebuilt this entire suite of data tools that was available at maybe 10 or 15 giants in a such a powerful way until now. They built experimentation with proper statistical analysis, feature flags for save deployments, session replace analytics, and more. All backed by a single set of product data. >> And one really nice thing about Statig, it's it's not just about saving engineering time. It's about getting worldclass infrastructure from day one without having to build it yourself. Rather than arguing about metrics definition or troubleshooting broken tools, engineering teams can just focus on building a really great product. >> The other thing is scale. Since already processes trillions of events per day, which is enormous data, by the way, they also scale with you. Plus, you can integrate Staxig into your existing product data easily as well. If you're interested in giving your product team an access to incredible data tools, go to stats.com/pragmatic. They have a generous free tier, a $50,000 starter program, affordable enterprise plans. Just tell them the pragmatic engineers 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 uh the existing tools didn't work for their scale. So maybe let's let's talk through some of the unique uh tools tool set that someone would see if they start to work inside Google or or if they're they're working there, they 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 like because it was search. It's like well this needs to be global from day one. So we need to have this in infrastructure from day one to get the speed and re and reliability that we want. And so that's why they just jumped straight ahead with like we'll just build custom stuff from the ground up. So yeah, like they scaled into six digits of machines in the early 2000s. >> So like hundreds of thousands of machines. >> Yeah. In their data centers. Yeah. There was a pragmatic engineer post from an SR a couple months ago I want to say where he talks about he started at Google uh doing S sur in 2004 I think it was and already when he started there were hundreds of thousands of machines and this was during a time when large data centers had hundreds or maybe thousands of machines. >> Yeah. Yeah. This this this is Dave O Connor and he was telling me that I think in Ireland they they visited a a data center cuz they they wanted to see how they worked and they wanted to see if they could use them and in the end they figured out they couldn't but they asked like okay how do you manage your your machines and they were like oh we just do manual updates and 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 cuz we we're planning 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 what everyone else is doing we 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 or software engineers who now became experts at like operating infrastructure which was unheard of Because until then you had the IT guys uh who who knew how to configure, you know, Windows machines or Linux machines and and knew how to patch them, how to plug in, how to, you know, make sure like do all these things, but they were not software engineers cuz why would you hire a software engineer to do to do that? So like Google did a bunch of these things and and that's where obviously one of their biggest uh internal tools which we mentioned bore comes from uh which is orchestration system and and Kubernetes uh 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 it's a cluster operating system >> and then you know do you know what uh Google's kind of internal version of data log is called? Borgmon. Oh, yeah. There's also one called Monarch. I I I'm not sure which one is which, but yeah. So, they have a so they have this monitoring which is like integrated into Borg. And this is one of the reasons by the way Google people are like oh why doesn't Google just move to Kubernetes and well I mean then they would need to replace some of these things. Oh and then they have this thing called uh third eye uh which is their which is pretty much what Sentry is from the outside world and that's also nicely integrated into all of these systems. It's kind of like got all the hooks got all the APIs. >> Yeah. Like all of the tech stack is custom. Like there's nothing that's not custom in the Google tech stack. So, Borg uh they call it a cluster operating system and it's yeah like one of the first things they built is like realizing okay we need huge data centers we need so many more machines than anyone's ever had. What do we need in order to operate this in a way that is automated and not manual because that's not going to scale. The Google data centers are are and always were built kind of like from the ground up by Google and designed in ways that would fit their scale. Like because it was like planet scale search from the get- go, they never had to think about, you know, like, oh, what's the data center for like the smallest need because their need was so huge from the get-go. Well, well, and 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 literally just took simple PCs that they put together on like the the main frame, the CPU, the the hard drive, and 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 $2,000 machine. We can have 20 $100 machines and we can have throughput of three times." And then they started to take this a bit more seriously and I started to manufacture their own servers, which cannot be bought by anyone, but 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 you know, but as as you just just to your point like they they they they built a larger scale compute than anyone needed at the time. >> Yeah. Exactly. And like with their ambitions and knowing how big they wanted to be and the kind of support they wanted to provide, it's like well this is what we need to do. I think maybe also because of the 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 going to fail anyway. So yeah, let's just go with the cheap stuff that's easy to replace and just build amazing tooling on top of it that makes it nice and easy for us to operate on. So like yeah, today it's obviously like cloud computing is it's the status quo. It's what everyone's doing. But at the time again like they did this in 2003 2004 this was unheard of and probably anyone who heard of it was like what are you doing? Why are you why would you do that? Well, Jeff Bases might have heard of it because he was an investor and you know, like AWS later launched their their public cloud, but but yeah, it's it it was Yeah. Yeah. And I think it it wasn't just just unheard of it, but I think this goes back to like Google was seen very kind of weird a little bit or like almost mythical for how they hired cuz like the the way most tech companies would hire at the time is they would ask you programming questions of like I don't know they hired a Java programmer they would ask you all right how does you know the memory allocation work in Java or stuff like that or like if you know they would ask about design patterns or stuff like that and Google like would ask brain teasers they they would 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. Uh they they stopped this several years later because once this kind of went mainstream, you know, people started to optimize for it and it turned out that they also rejected people who were smart but they were just not good at brain teasers. Most companies hire for the programming language that they were using made up maybe that was like cold fusion back in the day or like again Java or Python or whatever. And Google to this day doesn't care about what language like you're using. They just want you to use and and write code with in in um a coding exercise oftentimes you you can use any language or sometimes you use code if it's an algorithmical interview. This was one of the reasons they love algorithmical interviews. No 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. like they need you to have open horizons simply flexible and solve problems because you're going to solve them differently at Google anyway. Going back and speaking of just how custom it is, the fact that like when they built out these data centers, they also like they couldn't use or didn't want to use opted away from using normal like networking stacks and switchboards and stuff. They built that from scale as well. Yeah. Why? >> Uh so they have something called B4 uh which is like the backbone networking infrastructure that has ridiculous bandwidth and that's the thing that their like they built out so that their data centers and the ridiculous scale of of the machines could talk to each other and uh that Borg was able to coordinate uh you know job allocations. They also chose not to do DNS the standard way because uh they developed something called Borg naming service. So the BNS um and that's because obviously like at that point and very often you will you know have a specific IP address and specific ports. >> Yeah. >> Um but Borg from the get-go was very like well any anything can run anywhere. So they wanted a level high of abstraction higher than that. What Borg does is that they allocate resources for like jobs and memory and CPUs like across machines. So the actual IP address to the machines like it has to happen fluidly because they don't allocate specific machines. It's broader than that. It's more like cluster level and a cluster is like racks of machines. >> Mhm. So they they needed that that abstraction. They need a next level outside of like you know what's a rack, what's a cluster, that kind of stuff. >> Exactly. Because it's like well we have so many machines that it doesn't matter and the machines again like because they were especially in the beginning kind of like cheap and easy. It's like we don't like a machine will fail. We don't care. We'll like another machine will come in and take over. And similarly they built out the Google file system back in 2003 or well they talked about it in 2003 um which was also necessary because of that. So like a a huge decentralized uh file system like in 2003 they had hundreds of terabytes of storage across thousands of discs and machines accessible by hundreds of clients. It had this like basically a storage stack where you had discs like actual physical hard drives and then an abstraction called D above that for a disk but like the disc could be either a disk or something else. Uh and then you had the like the Google file system on top of that which was later preceded by Colossus which is what they use now. And then on top of that they built out all of these like database like services. So things like big table, like spanner, like there's not just like the one database because it depends obviously on the uses of the database like what are you optimizing for? And so internally they have lots of different variables and like kind of database systems as well where they will have some of their data centers u are like more specifically for you know better for certain type of data storage and certain types of of database you know big table is more nosql it's sparse it's distributed it's persistent spanner you have a more SQL like interface case it's more important for like real consistency across the world. >> Yeah. So I guess the trade-offs are like is it like write intensive, is it read intensive, what kind of data are you storing, like how structured does it need to be, how are you wanting to access it, right? So these are all the differences between the the reasons they they have and then like as you said the distribution like like do you just want it on one machine and if it dies totally fine or you want guaranteed uh that it's 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 go back to like why are there so many databases? There's so many databases like we just did on the pragmatic engineer survey. There were so many like 50 plus or or even more that people use and they're all like built by like actually experienced teams. That that's kind of an interesting interesting side question. Why so many databases? >> Yeah, like databases optimize for different things and so there's different use cases for them. But one of the things with Google from again fairly early on, Google branched out and like they didn't just focus on the one search product, you know, they built out Gmail which was basically email with built-in spam filters was like the pitch from early on as well as a gigabyte of storage which was also unheard of at the time. Uh and then they branched out into you know Google calendar, Google Docs. Um they did some really big and smart acquisitions like YouTube, uh Android, you know, they they had the the in tech infrastructure that they had. Um and then they started h getting all of these new use cases, uh basically companies operating on top of this stack. And so they were able like had the needs, had the expertise and had the data centers and the infrastructure to build out all of these different offerings uh for their own products. I don't know if this is still happening, but they did actually for a long time at least and possibly still they also had backups for all of their data service uh data centers on physical tape. >> Wow. I mean ta t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t durable. So >> yeah, there are uh in the SRV 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 like huge outages in 2011 and 2012 from Gmail and the Gmail one in particular, there was a bug and they lost like 0.2% 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 gape >> 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 tenants 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 the number one. It's pretty clear that that engineers or or even teams that are faster than their 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 it. In fact, it was the most loved project management tool. It wasn't even close. From the responses, it was clear that the big part of this was due to how fast Linear is to use. Right after we posted a survey results, Linear reached out wanting to work together, and it was a super easy ACS. I've since been talking with the Linear team about how OpenAI and Perplexity switched to Linear. And a big reason for these companies to move was how Linear enables velocity in their product workflows. I'll actually link the OpenAI story in the show notes below because it's such an interesting read. 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 the Lunar team over the coming months and I'm excited to share more about the product and the story behind the company. If you're curious to get a feel for the product yourself, head over to linear.app/pragmatic. And then outside of just infrastructure, like Google has so many other custom systems. I I'll just name a few cuz I I think like it's we could take forever in going into them, but instead of instead of GitHub, you know, for source control, they they use Piper, something called Piper. That's their version control system. instead of pull requests they they have this thing called DL change list uh for their code review tools called critique uh and it's integrated with so many other tools that they have a lot of AI function now built into it it's it's a little bit like GitHub's poll request review uh code search has been a very kind of famous tool that that inspires source graph uh so you can you can search all of Google's repositories and again they they they do have a monor repo but they have incredible amounts of of code and it it's it's rapid. It's again it's from a search company you wouldn't expect anything less but apparently for a long time when I talk with source graph founders they were saying that code search is was they had parts that were better than source graph's own offering I think now source graph is is catching up but I still remember when I first used source graph at Uber and it was just so fast and I was like wow this is so so cool to use but apparently that 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 it wouldn't be worth it building for for your own. Yeah. And a lot of that actually comes from the fact that they have this monor repo. So the monor repo, they talked about it publicly first in like 2015. They started publishing numbers on it. Back in 2015, there were already a billion files in the monor repo. 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 monor repo 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 um no build tool blaze >> blaze which which they open source a thing called basil which is similar enough which is also really really fast and really good. >> Yeah. And it's you know this distributed build system that yeah it's kind of core of how like it's core of how they build u it's very distributed very quickly. It enables the monor repo in in the ridiculous scale it's at, but it's also deeply ingrained into how they do the development itself, which is very in the cloud actually. like most Googlers will not have code locally on their machines and kind of haven't uh ever it's kind of a system uh called clients in the cloud or sitsy uh which is the way they 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 they mostly do that through a tool called cider which is actually a a fork of VS Code >> well now now it is right. It used to not be >> it used Yeah, it used to be something else. >> It used to be a web- based tool. >> Yeah, I I I used it a little bit when I was interning there and uh I think like back then it felt kind of niche, but then I think that's uh changed a lot. I guess partially since forking VS Code, I'm I bet it's it's looking much nicer than it did when I was there. >> I 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 tap uh test automation uh program. They have tools like try quarter which runs tests static analysis all that stuff. They actually speaking of rapid they actually have uh 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 monor repo 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 linear they have buganized again a custom tool and they have this tool called task flow which is a UI on top of buganizer for boards cambban and other kind of management tooling and then they have guts which is Google universal ticketing system it's was more for for tech related tech support when you open like a ticket you know you can think of it like zenesk or like juro tickets or 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 I guess when you have the infrastructure so unique it's like well you need to implement this so where does that goes come in and actually I think buganizer in particular is also probably the integration with cider and critique and but like because everything is so custom everything is like made for each other as well. So using buganizer, you know, you can report but also like fix do small fixes like immediately in the same environment that you're already in because it's it's using the same infrastructure. >> Yeah. Now, one interesting thing about Google that I I hear is this kind of tech island. I I I think longtime Google engineer or executive Ursera might have said this. Google is 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 a AWS tooling or for containers it'll be kubernetes or for front-end frameworks with like react or uh and and like for database it'll be postgress or or something that is out there but for Google everything is uh separate and there was this recognition even inside Google that this could be a problem that they're so unique that they cannot take advantage of other open- source projects for example developing but but also it's it's a very expensive to on board it's just for new joiners you know they have to throw away every knowledge and at some point it might also be maybe just not as tempting to go work at Google if you know that whatever you use there it's not going to be useful for you know your your next job but I 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 it didn't start because Google it didn't feel doesn't feel to me that it started because Google said like no we need to do something different. >> Yeah. I think it's more like 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 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 uh a lot of that is what they refer to as external izing. So they're externalizing. They're not open sourcing because it's still like they're on their own tech stack, but they are externalizing. So making offers that, you know, can be used by other companies. So Kubernetes is the externalized version of Borg and it's not the same, but it's, you know, heavily inspired by it. Like slightly different architecture, slightly different feature set because it's it doesn't have to cater to to just Google. And the same for you know big table spanner yeah basically everything in the in the Google cloud platform and act actually also to mention gRPC gRPC which is a way of communicating across services that is something that is also externalized uh internally it's called stubby and that is the way that they communicate across services and it's yeah it's the internalized um gRPC they use protobuff as like the messages for how to communicate across services and then gRPC is the way they do that. >> Yeah. All all this internal tooling I I think like for a feedback I I often hear from people going to Google is how they're just really surprised at how it is. And of course people who've been there for long enough they gotten used to it when they go outside they're often really kind of taken aback by how little other companies have it. For example, if you spend most of your career at Google and move to any other 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 person neat code as his name is Namadiv Singh who uh well he he creates uh 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 quoting him. Google has this problem that they have an internal tool for literally everything. So and sometimes all those internal tools don't have massive teams supporting them. Sometimes it's just one guy working on an internal tool trying to get promoted that maybe they get promoted and then they stop maintaining that tool and now you're used to forced to use it and then nobody knows how to fix a bug. You have to go and read the code and you have to fix it yourselves and that's not fun. No one enjoys that. And then he said I would rather not have this internal tool in the first place because at least I can just solve the problem from scratch but now that is there I need to use this internal tool. So I think it can get out of hand and sounds like a Google sometimes gets out of hand and he was specifically saying his problem is not with the big tools like Borg that are really wellmaintained really well written but there's it's just everywhere. So it's and because of this uh as I understand you know Google has so many migrations going on all the time especially you know pro promotions come into play which we're going to talk about shortly but let me show you this image when it comes to Google they there there's this like two two things to choose there's the the main thing that's deprecated don't even think about it the new thing that is under construction and this is by by Manu uh Cornet who worked there for I think 12 years and he was saying that by the way this is true for a lot of tech companies but especially Google. So let's talk about how Google works. Now the first thing I kind of think about like when I you know people think like oh what do you know about Google even as engineers it's it's about the perks right like they're they're just so known for for the perks especially if you visit a friend at Google I mean it's the thing that stands out right I think the 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. Um, >> it's unique to Google. >> If if you have the chance to go visit a Google office, especially one of the bigger ones, do it. It's It's a fun time. >> Yeah, they people can bring in visitors. You you get like free lunch or breakfast or or whatever dinner probably as well. And I mean, the decor is unique like you know like I I've been to many offices, right? Like obviously what worked at Uber but went to Meta, Spotify, etc. like and they all have like cool decor at places, but Google is everywhere. Like the thing that reminds me the most of of Google is the old Facebook office back in 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 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 micro kitchens, a micro kitchen is basically like a space in the office where you can get free snacks and coffee and tea and and and just like often just like a a nice little like chill break room where you can socialize and hang out with people. Yeah, there's just so much personality to them. In 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 a library basically with these huge book 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 the offices whereas like you you know you can go in and like do a quick call or like a oneperson meeting room. They had uh 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 choy 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 Nler hats, which I did have, but it broke and I have lost it somewhere. And then like I think the perk the list of perks is really long. I mean it keeps changing per per location but there'll be like you know from the usual kind of in the US the 40k on 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 don't need a budget. I mean it's it's changing over time and again this is what I mean by by location. And then there used to be like more historic perks that I don't I don't think exists, but there used to be like on-site massages where you can get like like uh like you know like like mass would come in and like you could just get it in the office which was very famous in the in the like 2000s or or so to like the napping pots to some of these things. But these keep changing. But I think one thing that hasn't changed is which is kind of like the biggest perk of all is the compensation package which is just like wow. like you know there's this trrimodal 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 a top tier Google is is a very top tier company which means that they can pay anywhere from two to four times the compensation so the total compensation that other similar companies would pay let's say for a senior software engineer and like what this means in terms of numbers is in Silicon Alley uh of California, a senior software engineer could make around $4500,000 per year in total composation, which means, and this is where like it gets interesting, there's a base salary, there's a stock that vests per year that you can sell because it's liquid stock, and then there's a cash bonus. And then this will be something for a senior software engineer in the US like 220,000 uh in in California base salary maybe 200,000 per year in stock and maybe $35,000 in target bonus and these last two they can change based on your performance you could get more you could get less but for for London this whole total compensation package which is not all salary so salary is only one part of it it will be for senior software engineer will be something like 200 to 250,000 pounds. In in Munich, uh it will be somewhere to€190 to€ 220,000 and in in Turk it will be 300 to€330,000 which is like a big jump again differences in taxes and areas and and again for every other location in in India and in 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 you. In many ways, Google feels like this amazing like you get everything. You get to work on the largest scale things with smart people, these amazing perks, and you've been paid a bunch because a company that does pay you pretty well, not this well, but they pay you pretty well is Amazon. They give you a very respectable total compensation with pretty good stock and cash and all that, but then you get nothing. Like there there's no perks. There's no nothing. They're like, you know, you 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 and of course you're not going to pay for it. >> No, exactly. Like they they take good care of their engineers and have done again like from day one basically. And 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 at Google and similarly well at Amazon, Meta, Microsoft at all the other companies you are expected to when you're on a team you share the on call on your team. Now, in the case of Google, on call is not nearly as enforced or as stressful as at every other company. At every other company, you join like a six person team. You'll probably have a rotation of of every six weeks. 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 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's toil service level objectives where they want to make sure that that teams whose SLOs's are are breached, they stop production work and fix the underlying issues. So they basically provide time for teams to become healthy again and you know not get woken up all the time at night by systems that break which 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. Uh tier one means that a page that comes it needs to be acknowledged in 5 minutes, tier 2 in 30 minutes and tier three is best effort. So you can imagine tier three is internal services, tier one is important services, but then they pay for the on call accordingly. So they say if your if your team owns a tier one service and you're on call, you get 66% of your normal salary. like if if you would have been on call for the whole month which you're not going to be on call you you can either choose vacation or pay like 40 minutes of your time for every hour. So anyway they they do a bunch of composite they pay really well for being on call and then they limit time spent on call at the same time. You cannot go for on call for more than two weeks per quarter which is going to less than other companies. So it just like it it like mind-b blown like Google all does all these things. They pay engineers like best in the industry or close to best in the industry. They give all these perks and then they relieve them from on call. So it's almost like it's it's it's amazing to to be and then not just relieve but they actively help and mandate teams to make their systems better. So this is like paradise for an engineer. Like so far like you would almost think that Google's paying us to like 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 pots or whatever. Like 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, uh you'll likely be an SWE, the software engineer. That's the big role that Google has. Um but Google also has tons of like there are a lot of other types of roles and niche roles as well. Like S is obviously one of the bigger niche ones run that they have. Uh but there's also quite a lot of other smaller ladders that and and roles that they have depending on you know like some roles are more prevalent in some parts of the organization and with some products or product areas. So you'll have stuff like Debrell, they have UX engineers which are kind of like more front-end engineers working more with design implementation and that that there's like a scale there that goes from more like front-end engineer to prototyper which is a separate career ladder. They have research scientists, they have within the sur 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 SW role is good, kind of a bit like higher class essentially. Uh, 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, you like it's much easier to like move somewhere else because that's the default that engineering managers will look for and hire for. And speaking of managers, they have engineering managers that are, you know, EM, they take care of teams. that's their primary focus is making sure that the team is healthy. uh they also have two roles that is the tech lead role and then the tech lead management role >> tech lead manager >> which is unique to Google where uh so it's basically you can think of them as like uh a spectrum where you have EM on one side where it's you know the person like you know they have direct reports they take care of the team they do all the EM things and then on the other side they you have an a IC individual contributor who's a tech lead uh so tech leads are in charge of uh you know overall architecture tech aspects of projects of products they'll make sure that you know like tech decisions get made they have the top say they get appointed by EM but then there's this slide in scale in between where you can have tech leads who also have direct reports and here we talk about tech lead managers 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 uh SVP come over and then it was introduced. My understanding of the the idea of this role originally was well first let's talk about levels and then well we we'll get to why this role is kind of important. So the 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 L8 principal. Uh L9 distinguished and L10 partner. >> So like or fellow, yes, >> Google fellow. >> Google calls it fellow. Uh I think Microsoft calls it partner. And around like at the senior software engineer at the staff engineer level at L6 another path starts which is the manager path which is >> which is where injury manager u there's sometimes an L5 injury manager that's more of an entry level but I think they'll use it internally and then L L7 will be uh senior engine manager uh which is this the same as the kind of this the senior staff uh 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 I see L3 to L10 and then manager from L6 to L11. And at every level, it starts to become harder and harder to to go go up the path. And around like L6, people need to decide are they going to be on the IC ladder, try to make their way to L7, L8, and so on, or switch to manager ladder. But at some point, you kind of like get stuck, but maybe not necessarily an uncomfortable way. So like when people get to like L7 or L8, you know, you're not really going to go higher. And at Google there there are are people with really long tenurs like you know 10 years 20 years even more and they're very comfortable there. And so you have these individual contributors who are really good at their work. They're they're the tech lead de facto and they could manage their team that small team like and typically these are small projects but they don't really want to be on the manager ladder cuz they want to stay IC's and they don't really want to be promoted. So this tech lead manager role is kind of created for those people. And this is really important context because some other companies took over this uh role. So the duber for example and what they found is people who went into this thought that they would be promoted to the next level. But it's really hard to be promoted when you're kind of expected to both be an as an engineer you're not doing as much work as before a little bit less and as a manager you're managing a team. So people can get frustrated but for Google it worked as I understand. So the technic managers are typically they're 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 like in like small teams uh 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 but it's like you know a couple people rather than you know a full established team that has what 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 and usually it's stable teams. Usually, it's not ones. And also, if if you're on a team of like four or five people, there's going to be not as many promotions and and so on. And also, 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, it's to do their there might be L1 and L2 within Google. It's just not for engineering because they're also salary levels uh as well. uh PhDs uh if you have a PhD you you start at L4 minimum. So there's one uh some other companies do the same thing by the way who hire PhD students but that was an interesting thing for me. Uh, no. Uh, at Uber when I was hiring interns, we hired a PhD and then HR told me that that person needs to be at the next level. And I was like, okay, sure. Like, fine. But I I guess it's it's one of the reasons you see like, okay, having a PhD pays off. But again, we asked the same questions from the PhDs as we did from from the new grat. So, they still needed to algorithm the 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 comp uh our industry that if you're in a very low L like you're supposed to kind of progress to a higher level within like X years. >> Well yeah so 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 and then if it didn't happen uh there will be questions asked and some pressure and eventually they might actually just fire the person saying hey like why did they not to what we expected and once you reach a terminal level there's no pressure and what has happened at Google is I they've changed the terminal level to L4 because over time it's now to get promoted to L5 you need to like ship a kind of a pro 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 as they grow. >> But uh I think this leads into nicely into the performance reviews and promotions at Google. The performance process it used to be called Perf and it used to be kind of you know one of those things that is like people famously complain about. But they actually did a big rehaul in I think 2022 where they moved to a new system called Grad, which stands for Google review and development. >> If you ever worked at a a big tech company, it's a pretty similar performance review process. People will 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 in December. There's bonus meetings behind the scenes. In January, they get finalized and then they get paid out in March. And so basically like for the input that you put in November and December, you're going to get like a final like output in February and you will get the bonuses in March and either you'll be happy or you'll be unhappy. >> Yeah. And I 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 uh where you had to spend yourself a lot of time uh you know putting together reports and like paper trails essentially about all the things that you do. And with grad supposedly it's been pushed more to the managers I believe which if you have a good manager is probably an amazing thing because you know you'll have a lot less work. Uh but if you end up with a Yeah. like it it'll depend on your manager it seems like. >> Yeah. And so Google used to be known and I think they still kind of are. They're trying to be pretty fair in in how they do performance reviews and and promotions and and we'll see that with with with promotions. I mean, the manager still has as has a big say, but they're trying to focus on uh outcomes, outputs, etc. Like they're they're doing more there there's a lot of training for managers going on antibbias 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, 5 10 years, people are 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 or feedback scores uh in terms of like, you know, if if you're meeting or if you're exceeding if if you're above. But there is this interesting thing called the Perf score resetting when you change teams." So, this is >> Oh, yeah. As I understand, this is kind of a open secret that if you change teams during a perf season, so basically like right after the perf season has on your first perf season on your team, you will always get meats 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 uh 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 it mean they map to uh impact instead. Uh so you have uh 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 8% 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 a 100 L5s only three would have I'm just saying something. It might be five but a certain number can get transformational impact. And so on the calibration meeting where all the managers get together and they they all you know submit their ratings there will be a calibration where it needs to not fit the curve but it needs to fit the buckets. So there there often times 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 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. uh it depends on the performances and depends on the organization but there's always going to be a distribution a force because uh what most companies learn including Google is if they don't force it a lot of managers will just like shy away from having the hard conversations or reward either rewarding their their their their best performers as they should be or being a bit more critical with the people who are not pulling their weight as much and this is irrespective of this happens at every large company after a while and even when it doesn't for a few years it can start happening after a few years like we've seen a lot of companies have like after relaxed uh performance management in 2021 2022 like the when the job market was really hot they there was a time where they gave everyone exceeds I think Google did that once as well to fight uh attrition and now it's back to the usual of like there there is this bucketing and we have a longer deep dive on how calibrations work behind the scenes from a manager's point of you which is actually really interesting slash eye opening but as an engineer not much you can do beyond you know document your impact have have a 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 is some aspects of like you know the type of you know work that you do and kind of extra extracurricular activities if you will that will feed into and like look good on these performance reviews. Uh, 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. Um so because 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 out with that kind of stuff. If you like working with that kind of stuff, like kind of tech writing and like tech learning, uh, Google has a lot of opportunities for that. >> Yeah, probably a lot more than than most other companies. It sounds like they actually appreciate it as well. So I mean obviously you need to do like do do good work like don't write sloppy code and like it's full of bugs all the time and then do all the extracurricular things but when you want to show that you're ready especially I guess this is true for especially the 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 they might hold it against you if you're like an L6 and you're not mentoring anyone they'll be like or 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 there's actually that reminds me that one of the things that is built into the critique system and their uh code review process is something called readability. Uh which is essentially again it's a monor repo 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 uh needs to get reviewed by three different not 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. And so the 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 we we we talked about it with with Arena on the podcast. She was ex Google. So yeah, she also went you have a process is pretty straightforward. You need to like shadow I think be signed off that kind of stuff. >> Yeah. Exactly. and like do a certain number 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. Yeah, you can just like focus on readability like just look at open open CLS across the >> It's so so unique to Google, isn't it? Like I I don't know any other company that does this like at at Ruber and other large companies like Yeah. like you do mandate code reviews of like a code owner but nothing to do with readability. >> Yeah. And I think it could be that that's probably an artifact of the monor repo again as well. The monorreo doesn't necessarily like they still do a lot of like micros service architecture for like within the monorreo 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 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 it's an interesting approach. So uh outside of performance reviews the other one is promotions. That's and promotions are different at Google because there is this thing called a promotion committee. So, my understanding is that Google has been really big about trying to not be biased in promotions, the way promotions work at most companies is when you're up for promotion, the group of your manager and their your manager's peers all get together and they're like, "All right, is you know, Johnny ready for a promotion?" And they all kind of talk about why, you know, and your manager says why they think they are. And then their peers say like, "Yeah, we agree or we don't or what about Jane?" And 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 or it might be pretty ignorant. Like there might be some managers who would veto you cuz 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 done 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 to work with you. They have no bias for or against you. And so the decision should be a lot more like objective, right? So they will decide on your impact on they will look at the framework that's that's there and and the impact because again with the manager uh 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 or good man well good manager from their perspective. There is a very interesting kind of downside of this promotion committee. Uh 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. uh and he was stuck on that level for four straight years trying to get promoted for years one after the other and he wrote this blog post and he 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 uh he uh you know submitted his he was doing a bunch of maintenance work h and then the promotion committee said that he had not proved that he could handle technical complexity and they didn't see the impact again Google's big on impact so they said to be promoted to L5 senior he needs to have an impact on Google then he went back uh 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 get to promotion and he got that project but then the project got cancelled and then the the next year I think he moved teams or he had to move teams because his team got cancelled and so so he had this like series of bad lucks where and then and and then in in I think year four he wrote in this article I'm quoting him my quality bar of for code drop from will we be able to main this this thing for the next 5 years to can this last until I'm promoted I didn't file or fix any bugs unless they risk my project launched. I wriggled out of all responsibilities for maintenance 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 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 a smart a smart guy. He built a really good business afterwards. But it felt to me he just got unlucky of of 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 and you know there's there's this joke uh that goes around uh of why Google has so many chat products. I think you know they had Google like they had Google wave ghat uh and and they keep changing the names and also the product also pay Google's payments promotion it was Google wallet then G pay 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 they're 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 meat's review, or you could move to a new team and get a meets review anyway. So often teams will move to a new team and either start a new project or or join in. There's just not much incentive to stick around on a project that's not doing great for the 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 that's that's the gist of it. my my understanding and and you know this goes back to Google has this thing called killed by Google a website that collects these like 300ish Google products that have been launched but they have been killed >> yeah I mean technically not run by Google but uh >> oh it's not it's not run by Google it's just external external that one is not a Google project but >> that would be funny if someone internal Google is like here's all the things we're bad at >> no but it's interesting because on one end it's Google is very heavily criticized because they are the biggest tech company which seemingly wastefully launched which is then kills projects publicly. But at the same point, I I I still wonder if this is kind of part of how Google operates where they they do want to see people launching stuff. And again cuz cuz look at it like yes we can make fun of how Google like you know like discontinues Stadia a gaming console or or or Google reader but show me another tech company that that has as capable of LLMs as Google has big tech their own models or self-driving cars in San Francisco and may 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. uh like famously the 20% time uh which it's 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 the internal tools you talked about earlier comes from that kind of things where you just have the ability to like oh I I It would be nice to have something like this and you build it for yourself and because it's Google it's automatically available for everyone and then all of a sudden you have built a tool that people use and then you move team and now no one's maintaining it. And so I think part of it is that that Google allows you to be creative and innovative and try new things and just like yeah launch see what happens. But I think another part of it as well is I think of Google as being a very kind of engineering first and engineering driven organization. If you compare that to say Apple which is much more kind of like the design and user experience driven and if you have it versus say a meta or something like that they're much more like product driven. It's like if you're a product person that's how you drive. I 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 a product person at Google you'd have to you know convince engineers and like do this whole thing of like getting headc 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 mon repo 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 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 roll out plans, life cycle, 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 dock. 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 things 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. Uh why why do you think this might be? They just realize that consensus is is important because they're they're also big right? They're the biggest probably the biggest like engineer culture of this quality. >> Yeah. 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 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 it's kind of a vibe thing. Um, and part of being googly is that like it's it's less of this whole like a bit less of the rockstar mentality that you know you're the rockstar engineer who just like goes off and does his own thing. It's very much more like collaborative teamwork, team spirit, enable everyone to do great things. And so it pro like I would assume it comes from that as well like part of being able to uh keep the googliness is to just be very open and there's actually like we've mentioned the sur book there's also an SV book um software engineering at Google the office >> yeah I have I have it here on my desk software engineering at Google it's also it's available for free online uh Google made it available like it's officially free it's not like one of these pirated books. But yeah, it's 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 monor repo 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 you know software engineering is a team effort and u like 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 that teams would maybe work better without managers, just engineers, and turns out they didn't. And then they went back and they tried to figure out what do good managers do, what should they be technical and and like they've done a lot of research and they have published uh 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 it's often times the business you know CEO or someone pushing developers like do this or that and they're asking why why is it taking so slow? Why are you guys I don't know like lazy or 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 you know that they just build an internal product or internal platform that the other product teams use and most companies like a nontechnical 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 open source tools or for your CI/CD system you still need someone to maintain it at Google like it's probably one of the best places where yeah everyone gets it because they've been doing this that 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 tradeoffs. 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 AI will replace 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. Uh 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 uh 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 IO every year to only have that product u 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 us OKRs objective key results. Now if you're if if you're a software engineer you probably like and you worked at a midsize or larger company this probably came up like what are your OKRs? What are your teams OKRs? The objectives the key results and the goals and apparently Google made this super popular this uh this framework right? >> Yeah exactly. So technically they didn't invent it. uh they were actually introduced in the 70s at Intel which is so long ago but there's this guy John Door who uh was at Intel before he joined Google kind of early and uh 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. method. So yeah like objectives and key results. Objectives is like you know a kind of more highle 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 sub0.5 second response time for searches improve accuracy of search results based on user feedback and the last one hire worldclass 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 what are we prioritizing? What do we need in order to serve 10 million queries? We need the data centers. We need the network like we can't use normal DNS. We need to invent our own things etc etc. So, I I'm I'm going to be honest like I'm always a little bit like suspicious about OKRs and Google like to me like because it it is uh the book Measure What Matters was published in 2018 and from there on it's really blown up and I think everyone's like using OKRs cuz 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 I don't know like using Jira made whatever company successful, SpaceX successful. I'm not sure they've used Jira, but like whatever ticketing system they use, did that make them successful? Cuz I'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 I wonder if if OKRs is is something that I mean it's it's probably it works, but it it could have been anything else cuz whenever I used OKRs at least and you know we we we try to use it like having a clear goal and and a and a team that was focused on building something was always way more important than having whatever OKRs because there's a usual criticism of OKRs of like well if you make it a target it's kind of like it's kind of silly because now you're only optimizing for that. Because I saw at Microsoft for example when I worked in like 2000 like 2020 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 we couldn't agree to add our codecs into the new Internet Explorer called Edge while Google Chrome had it bundled cuz the two orcs had different goals and they cared about download size and not not what we cared about. So anyway, it's good to know that Google uses them, but I I'm still kind of like I I 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 just like I can imagine like maybe convincing stakeholders or like early investors and each other maybe of like okay what are the things that we need and like at the end of the day OKRs is a tool right like this is a way of framing and communicating priorities and what needs to happen with each other. It's like if you use it in a good way then you figure out all of like oh actually we would need to do something else or we need to do something additionally. So I think if you use it as a tool like you can use tools in very bad ways and you can use tools to great success. And I'm sure Google has had plenty of OKRs that are not even remotely close to uh what they did you know in these early years. Um, but like yeah, maybe it helped like since they've been around since 99 like probably they know like you know it's helpful. Um, but yeah, I do think that the tendency of like oh they use this so therefore we should use it and then well be Google is yeah that's not how it works. Speaking of OKRs as as a tool for communication, u 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. Um again like maybe it's like part of it being the the monor repo 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 companywide town hall all hands meeting check-in type thing. It's called TGIF. So, thank Google it's Friday or that was the uh that was the original. Um and then like with the engineering team being or the 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 thank Google it's t Thursday. >> Yeah. But basically, uh, like it used to be more like Sergey and Larry on stage talking about stuff, doing open Q&As's. You'd have different teams come in and like present what they're working on or what they've built. Um, and I think it's it's one of those kind of cultural cornerstones it seems where like I remember when I was at um when I was interning you know it 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 um the cafeteria and you'd just like have this weekly chance to like go hang out with your colleagues before going home from work that like you'd learn all these things from across a company. >> Um and then >> so it's a fun 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 trickles down in a way because like Google organization is very fragmented like again because Google is basically many different companies in one. So like you'll have they're called product areas like the big sort of completely separate companies. So YouTube is one product area, cloud is one product area, search is one product area, advertisement is one product area. Yeah, >> that are like the big ones. There's another one that I can't think of right now, but you'll have those. And then internally 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 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 it kind of like goes down, right? So like there's a company one every week, but then you're going to have your I don't know your wider org and your your like you know like the bigger org and then your your teamly will you'll have a weekly team for sure. So like every week you'll have the TGIF or let's just call it as as in your team meeting and then every other week or every fourth week you would have some of the other orgs and they can just stack up. >> 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 SRB or and the design or >> Okay. So a bit of a culture shock if you come from like a 10% startup. >> Exactly. and like the Devril or and then like each of those like discipline based groups they'll have diff 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 hear me out so at Uber we had something similar it was a little bit ridiculous and like on the kind of the orwide all hands which it didn't really concern And most people people were just coding on their lap cuz they were expected to show up at on the meeting room. People will be coding on their laptops like I I I don't want to be here but I I need to show up cuz the SVP is here and whatever. But like what's what's the alternative? Right? Cuz 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 want every engineer to know what the CTO thinks. You want to know what your director thinks and >> and just what 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 disassembling next to you? That's not your problem. Like, 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 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 there like oh no sorry I was trying to get some work done. >> Yeah. And and just like it can probably be pretty overwhelming. >> Yeah. Um but I mean they are good also again maybe because Google is so global I think they are pretty good at you know recording like I know I've heard especially since the working from home like pandemic situation like after that they have even better kind of processes in place for this kind of stuff. So like cross crossatlantic meetings for instance like there these days apparently like they do some all hands 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 US in Mountain View, but you can be in in 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 reglers and you know Google has this like fun terms for like new Googlers newler exgoogler googler. Reg Googleers is apparently a program where Google talent acquisition reaches out to former Googlers saying hey you left 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 pro 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 I someone told me that it seems to be happening. And I don't know if the the program is official, but yeah, the term regooler is it's it's a fun term. >> Yeah. I mean, I I love all the names for the different Googlers. I have I have a few. Yes. Like noolers. When you're a new Googler, you get the nooler hats, the famous ones, like you know, the little caps with the little propeller on it. >> I actually I have this uh I got this little android >> friend when I was interning there. Uh, >> wow. That's a collectible now today. >> Yeah, exactly. It did have. So, this is the little nuclear hat. It used to have the propeller, but I broke it. >> Wow. >> And like it has the little Google backpack. You can even open it. >> 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 uh like the offices, things like this. >> But but what what 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 like being googly is like somewhat uh being like it might have been bigger previously and now it's they talk about it differently but like 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. Uh there's a lot of values feedback which ties into you know the the Perf now grad uh feedback cycle. Um 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 uh maybe somewhat of an ideal rather than >> Yeah, that sounds pretty ideal from from 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. Um, and then there's the peer bonuses that are uh like more proper like monetary like not like huge bonuses but like a bit uh 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 I don't I don't think have many companies have this. Like, yeah, some do have the you can send thanks and they're public and everyone is 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 does the right thing, which I think is maybe um ambiguous a bit. I mean Google used to have the motto don't be evil which they kind of faced 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 as again with the status quo like there's plenty of examples of big corporations you know starting out with good intention and then maybe getting lost along the way. Well, it it 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 uh doing government contracts and then the government does something that is just either ethically wrong or or a group of people disagree with it or a large group of people disagree with it. Do you stop working with the government? And if so, you're now giving up that space for your competitors. And then you know it now goes into the territory of like what about other governments when you're a global company. If your software is used in every single country, what if one country attacks the other? Are you also the evil country or or if 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 part of it. So that that might also be one part because that that's also one thing that Google is being attacked on for for example uh not just Google but all all companies of you know like providing software for I I think I think maybe it's the the US defense uh ministry because they're now using it for something and all the big tech companies now provide software there and you know the alternative is like pull out and give up on the market. Yeah. And also I I guess this goes back to like do the right thing. It's it's a it's in this book. I I just read it. But the right thing for who? Right? Cuz u as a software engineer, what what is doing the right thing for a service mean? Does it mean that we will have a great on call experience and uh we will invest a lot of time maintaining the system or do we do the right thing by shipping features quickly so our the business gets stays ahead or do we do the right thing that when customers complain the tickets come to developers immediately and we wake up in the middle of the night? like the right thing for who, right? >> So, there is a little bit of ambuggy there. >> Yeah. >> But but to be fair, like it's it's in the book here actually. Yeah. It's great that they printed it in the book. Do the right thing says has a strong sense of ethics about everything they do. Willing to make difficult or inconventional 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 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 say users. And that's I think that's an interesting thing uh cuz about 70% of Google's revenue comes from ads. So they need users but not necessarily customers. 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 you're paying for the product but you cannot get through to a 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 in into pushing to make sure that uh you know that the systems are work 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 the earliest like kind of precursor to that I think is when they opened up App Engine back in 2008. engine. Yep. I was an early user of it. >> Yeah. Uh because like again like the the Google infrastructure was primarily built for Google. It was never meant to be built for customers and then you know they had these you know they externalized parts of this and that you know grew to become the Google Cloud Platform. They obviously made design decisions and choices pro I'm I'm assuming while externalizing some of these like building basil um coming from blaze kubernetes from borg you know they've must have built in you know parts of it that's like okay so how do we make this work for other companies other use cases but yeah it's a it's a different it's an interesting difference between GCP and and other cloud providers is like where where it started from so to say. >> Yeah. Yeah. That that that that is really new to to Google. So I think Google cloud in 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 an app I was an early user of app engine. App Engine was so darn cheap everyone used it because of it. It was a lot cheaper than using AWS and running your own ET EC2 instance and and you didn't have to worry about scaling it. autoscaled. And then what happened in 2010 or 2009 cuz I was a user of it. I I built a side project on it that had a few hundred thousand users and I was paying pennies for it and there was like some big reorg inside Google and they shut down a lot of projects I assuming 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 autoscale you don't need to worry about it and now they had to worry us about like index rights and They exposed us to our infrastructure and everything became a lot more expensive. People were voted and they gave us 30 days of notice which was like really really short. So it felt to me that it was a do or die moment in the sense that either that that or proves that it can be profitable or or generate revenue or they're shut down. But it was the first time with Google where I felt really burnt. I 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 forum because of course it's a the only support forum was a Google Google groups or Google forum or or whatever that was. That's where the official engineering team work with us. You can see that Google is terrible at dealing with paying customers. It's almost like they don't they don't care. 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 the top and Google just treats them the same as free users. At least that was my my sense. But yes, that 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 uh across a bunch of different measurements. They're way behind uh AWS. They're behind Azure and they're very they're not really seeming to catch up. They seem to be stuck in this perpetual third place. The strange thing about it to me is is I 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 what like you can you can trust it and AWS did this over a long long set of time. They have moved over almost everything. Amazon.com runs on AWS as I understand. It took a long time, but now it's all runs on it. When I was at Microsoft, they they just bought Skype and I was in the Skype or they forced us to move over to Azure and we hated it. It was not ready. There's a lot of things, but we had to move 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 from my understanding my research they they have a few like they've made attempts to move and migrate some stuff over to GCP and there are things that run on GCP. I don't know what but some things do. the way that they they've externalized their product as they say it's it's very much like you know Kubernetes is not Borg uh by choice and Borg is set up for planet scale is you know what they refer to it as >> and that is not most use cases it is very specific and they've made a lot of engineering decisions that you know like with again like everything from networking to databases to like literally everything is custom. So like does it actually make sense to just externalize that? Not really. But that also means that like well if if that's what they have like if they want to win in cloud that would probably be a thing that they should do in order to you know really boost the platform to be as good as possible but then again it's like do they have to win at cloud because maybe if they win at cloud they are not going to win at all the other things. Yeah, I I I the question is if if they want to win, but I I got this because I have been asking a few Googlers or GCP people about this like what because I still remember inside Microsoft it people were not happy music and it was just dumb. By the way, the guy who did it was Satia Sachia Nadella. He 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 going to keep improving it. But someone at at Google an engineer told us how like I I have heard a lot of Googlers say that their internal infra superior and it's 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 planner doing your docs code reviews all that is unmatched because every part of the workflow has been thought of and it's got these like nice hooks and as a developer it just works so much better. So there's all these like decades worth of integration of the custom stack that it just works between all the tools that there is tight coupling that would be not possible and in the end devs will just do whatever makes it easier work for them like Google as a company will probably be like well we want to be productive right that's why you have your internal platform teams and as you said that's probably Google being productive and building their product and generating ad revenue 80% of the time and other 20% will be hardware sales and like some service sales and all that, it's probably more more important that they they grow their business as opposed to just growing the cloud. The cloud or can figure it out and being and maybe being number three in one of the biggest business in the world. Um, in the case of cloud is acceptable just the same way as Google is number two on 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. May 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 in the important search with self-driving there seem seeming to be investing heavily LLMs maybe those are the things that they really want to win in >> I mean speaking of of tradeoffs in general I think like if you really think about it and if if Google were to move everything to GCP like if that also I guess like because they built out, you know, their build system, their monor repo, all their developer tooling on top of the same infrastructure. It's different. >> It just might not not work as much as especially when you have like all the permission system that are like built baked in into internally. Who knows? I I think it's trade-offs, right? >> Yeah. >> It's probably a good reminder that like you don't need to like there's no no one solution. And also history of a company is I think pretty relevant to understand why they are where where they are right now. >> Yeah, exactly. That's one of the the big takeaways for me doing this research. Maybe I mentioned it earlier as well. Like 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 or is set up based on that the workflow developer tooling everything is just so interconnected with Google, which is why I think it's so it's been so interesting to uh learn about it >> and and I I want I'm thinking that the companies that are now growing as fast as Google did in the past. Open AI is a good example of of this of some of the AI other AI startups or maybe you know Nvidia's growth is is speeding up although they're more in the hardware business or for social media Snap uh or even Meta. Well, they they were earlier a little bit, but let's say for for OpenAI, they are now, you know, they're building other things custom. We're not talking about they they're using cloud like they're not going to I I mean, OpenAI is 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 the LLM stack, for example, that might be custom. So, like they're just taking whatever is there. They're they're not reinventing that part cuz why would you? Snap is a social media company. They used they were very heavily I think they're one of the biggest Google cloud customers and kind of Google always shows them off as like an example of like someone who grew with them because they could just throw money at Google and optimize it later. And even Uber has moved over to a mix of Oracle and 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 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 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 if they've been there for like 10 plus years if they've not worked on several teams and and some and sometimes changing teams like a few years in a row like almost like and you know knowing how big Google is like these are like thousands of of teams tens of thousands of teams actually and yeah you can just go between them. Obviously for smaller offices 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 um just to mention during the pandemic obviously Google started working from home just as 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 like it's possible to do this without being in offices. Uh, and so I know of of folks who were able to start working remotely for teams in new locations. >> Oh, so so they were able to do internal mobility. Previously, you needed to be in the same location. Now they could remotely join that team for a while at least. >> Exactly. >> I'm pretty sure that's going to go back to where it was before slowly but surely. >> Yeah, cuz it does it has done that. like they I mean Google now is I think almost everyone's on a hybrid schedule where they expect you to be in the office like at least two three four times a week probably depends on where you are and I know there's some >> follow your manager. Yeah. >> Yeah. And like how important you are to Google probably. >> Speaking of exceptions, there is this concept of singleton. >> Yeah. Yeah. So a singleton is basically a person who is on a team but like it's the single person from that team working in a new location essentially. Uh so if there's a team say Whimo 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 uh it's definitely an exception rather than a rule, but uh like it does exist. One more thing that is very unique about Google is the non-stop rewrite like everything is being re not everything almost everything is is being written every few years and this does happen to some extent at most large companies but with a lot slower pace I don't know if it's the engineering enablement the fact that there's a lot of new technologies invented by Google as well right like they they they created the go programming language for example gRPC protocol so so any 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 a with a rewrite, there's usually a 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 to 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 monor 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 errorprone 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 migrations all the time, but when you do, you better know how to do it properly and 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 know, 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 on once you've done a migration, you're seeing the next one's coming, you might just move teams if you I mean, if you did an okay job, it should be easy enough. You you can look at it from different ways. And obviously moving teams I 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 know, you could have manager bias 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 and or uh yeah like move teams also worth keeping in mind that moving teams at Google might be a much bigger shift but then again it's probably a shift in like the tech stack is obviously the same like you don't 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 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 all the like softer things might be very different uh 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 project that that they they have built or open source 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 it's I think it's gaining popularity again and Google is very heavy user of this front-end framework. TensorFlow for machine learning it's so widely used. I mean we we cannot not mention the LLMs uh with the that was not the technology but the paper that that kickstarted all of this with ascension is all you need the go programming language chromium uh as the the browser engine and just just so so so many other things I think you know Met Meta has a bunch of strong contributions in Microsoft's in in certain areas but I feel Google has a really wide range from like backend frameworks machine learning front content 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 that kicked off even more projects or or software businesses. >> Yeah. And inspired people as well. uh and like looking through some of the papers uh 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 like I was reading through some of their old like tech post blog posts as well uh like they have like they had a tech blog for or maybe just a blog for like Gmails like the Gmail email 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 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 papers. So the 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 uh like 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 lot more active of sharing like all right here's how to use it how to build it etc. But but yeah, I still asked this uh on on the podcast episode about Kubernetes. Like I still didn't really understand why did Google release Kubernetes because they had Borg and it worked really well for them. And so why bother building something that they didn't even use? Like they just put it out like oh here's kind of some some lessons from Borg that others can use. And I think where we got to is that they probably did it because well first of all now looking back uh it was it was good for their uh very good for their cloud business to have a technology where it's very easy to move from let's say containers on AWS or Azure to GCP also by 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 it They and they're also now pretty much steering the technology that is the winner, Kubernetes. They have a huge say in it. Like yes, it's it's 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, so maybe it's it's a mix of these things, but it never felt to me that it was like some sort of business decision. It was probably some engineers thinking like, it's a cool idea, why not? And then you can 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 here's an idea. I'm like, okay, let's see if we can justify some 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. uh like it there's like you know the winds of change in Google um 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 they had some big leaks uh so like they stopped some internal transparency in the all hands and the full access to like everything going on um like I know that's been restricted. >> Yeah. So, so let's let's talk a bit more about this because I 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 all that we've gathered and I guess maybe we should just like reflect a little bit on how the whole as you said the whole industry has gone through a massive change which was I mean there was a couple of like kind of like left turn 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. Uh there was close to zero interest rates in the US and and worldwide on on borrowing money for more than a decade and this was just interest rates were just about to go up before COVID and then because of COVID every country cut it down to like zero for another two years. So tech had this thing where there were still like zero interest rates meaning investors couldn't really put their money anywhere but like tech stocks or startup investment uh tech had a big boom everyone started to hire so this was a great time and this was 2020 and 2021 I I had so many friends and and former colleagues who like got 30 40 50% compensation increases like just by going to a company that did similar things but they just raised money. It was a great time and a really hard time to hire or or to retain. People kept leaving left and right. I heard of hiring manager a hiring manager who had a engineer sign and ready to join them but they didn't didn't show up on the first day and I was like oh called them up and like oh yeah I got like a 20% higher offer. Sorry I'm 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 sort of fast just went bankrupt from being one of the hottest companies in tech to just bankrupt overnight and then a bunch of other startups including like stripe and some other like almost every kind of large company did layoffs. And this turned out later that as we look back it it had to do with interest rates rising and when interest rates went up um this meant that companies and investors looked for profitability. So everyone suddenly focused on that and there was a bunch of overhiring in the previous year. So suddenly we had this like dual shock effect of going from everyone in tech is in demand and people could not hire enough boot camp graduates because there were not enough university graduates to just layoff shocks uh 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 3% layoff because of the financial crisis. They then did some layoffs after they bought Motorola in 2014. But since then, they they haven't really had any layoffs. And Google used to be known as the the place with like great job security, work life balance, almost impossible to get fired if you do a a minimum good enough job. And then they did like 6% layoffs just cutting people with like including people with 10 15 20 years of experience just sending an email to them at night. And I think this really changed the mood at Google. This was 2023 and then in 2024 they they there were some more layoffs coming in not as many as before but it's now seems like that kind of period of Google was perfect in so many ways. perks, money, work life balance, clubs, investing in everything. Like it was just impossible to hire away from Google pretty much. Now there's a bit of a sense of there is some level of being cutthroat. Not as much as their competitors like Meta or Amazon where it's a lot more tougher, but but still it's it's like, you know, it's 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 it's game over. And maybe it's not your fault either, but on on one end, it's it's a it's a change that hasn't happened before. On the other end, I was like, come on. You you cannot have it all everything for the whole time. Like, especially for like such a large company. So, like one part of me is like, well, I mean, it's kind of sad that it's over, but my other sites and at least startups have a chance. At least they can point to one thing Google does not do perfectly. >> Yeah. I mean, it's it does seem like they had a really good run for a while. And like I'm sure there's pockets at Google that is still probably a fantastic place to work, but I do think like it's not necessarily bubbles bursting, but yeah, like vibe changes and like part of that is the industry, but like part of it is also just like the actual products. Um so in terms of like uh you know YouTube was and is in many ways the new TV like it is dominant. Um but then Tik Tok comes along and Tik Tok is you know much more focused on the users and grabbing your attention and getting you pulled in. Um whereas like YouTube has definitely done that as well but like not to the same extent in terms of their shorts but then all of a sudden like now YouTube has has and kind of has to push for shorts because they like now they're in the attention war and similarly with you know like I feel like there was much more in like the the kind of public stratosphere in terms of yeah it's like oh Google sure has a lot of our data and they're sure doing things with it and you know Google search results are like a lot of them are sponsored this doesn't feel great. So I think there there's a bit of a shift as well in terms of just you know like they don't yeah they they cut the don't be evil but like maybe they leaned into it as well. Who knows? >> Well, but I think this is the part where so I saw Manu Cornate who writes all the all the the these comics. He was for 12 years at Google. He then quit Google and and joined Twitter and then lucky for him he he joined right as Elon Musk bought Twitter but he joined he told me that he he loved 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 the don't be evil the make the world a better place the whatever uh and you know build cool stuff and then he started to see how a lot of his comics started to become um 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 my and some of the sometimes profits started to come come up on on some of his comics on how Google is prioritizing profits. And so here here's the thing like you know when you're going up uh including at at Google like you reach the L6 level which is staff engineer that's the same level as a manager. Now if you think about it as a software engineer you think like oh I just want to think about the code my colleagues and then as a manager you need to think about the business and your budgets and headcount and hiring and firing. Now you're now paid the same like as a staff engineer and a manager is paid the same and they kind of are expected similar things. So a manager or one level up especially a senior staff engineer is kind of expected to understand where the you know like a bit more of the managerial side where the business lives and how it makes money and one thing that I think anyone working at Google or any other company needs to understand is where does your salary come from and how can Google keep paying top of the market and it's to do with their profits just keep increasing. Uh it's ridiculous. If you look at the chart, every year Google grows about about like 15 to 20% in revenue, which is which is bonkers because they're now so big. They're making like 300 and something billion dollars per 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 uh layoffs and and you know Google's doing everything to to not make that happen. But eventually that reality will creep in which is at some point your job might involve helping Google make more money so that they can hit this thing or if it's not making more money then help investors believe that next year they will make make more money which is has to do with all of the things why Google is going all in on AI or or if that doesn't help then 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 like how they make money how they will make money will it naturally grow without you doing anything because if so you're in a good place or does Google for example need to expand the areas that it services which which will include things that are controversial right like like again like will it get into military contracts and and the easy answer will be no but now when when you need to increase your revenue by 20% and by not saying by saying no to them, you cannot do that. Then the there's all all these things that that trickle down as as a result of that. So >> yeah, it's it's growing up in a in an industry and in a an economy that only goes up. >> Well, then Google has it it went from being a startup in a 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 than can you grow like I'm sure you can grow right but 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 but but then what and will growth always 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 or like being be used by teenagers. Same same thing with you know older older listeners or 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 it might be trying to lock out other competitors which you know Google is being sued right now by the US 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 on let's say iOS. It was interesting how things change. >> Yeah. And it is it's interesting. It's like the 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 uh there's this general idea in design that really good design is design you don't notice because it just becomes a seamless part of your day-to-day experience like you can point out bad design easily because those are the things that you notice and that provide friction in your life and Google is like They have a lot of things that just you barely think of them because they're so ingrained in your life which means that you know they do wield a lot of power like you know you've probably had that you know when they decide to change some aspect of Google calendar or change you know a color of something or whatever you know you have like you can your whole day can be completely thrown off. Yeah, and I 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 al also 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 pock there's pockets of innovation, right? AI is still up for grabs. there's a really open battle between uh all all the leading AI companies including Google and it's kind of fun and exciting but there's also the areas that are just one if you start to work on Gmail I mean it's already market leading like what is going to your mandate going to be it's probably going to be I mean you know keep existing users don't let them turn uh or extract more money from them in terms of ads because that's how you make money or or upsell them to something but it'll be mostly like maintenance and and don't mess up or if it's a cash c product like Google search. You know, we we've now seen reports uh 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 and so at some point I and which I I don't think it's a necessarily a bad thing by the way, but at some point this this thing comes where like okay like if you want to work on something that used to be like the old Google, it's probably going to be startup or if you're lucky it'll be a team inside of Google that has a green field project again like like all of those things happen all the time. But but yeah, but for some of the the big areas, it's it's different work to 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 accept us cuz 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 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's 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 everyone uh 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 cushy place called Google is if they just get a little bored and they feel that they could do so much more >> obviously in like there's always innovation uh but just like it just looks different today I think and the scale of it is different because I mean yeah like Google calendar does come out with new fun things fairly often and you know there's new features in Google meets and Google chat and and all these things but it's yeah it's a it's a much smaller scale uh 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, so let's talk about who do you think would be a good fit at Google? Like who are people who could get a lot of out of it in today's Google? Like not not not the ideal Google, but the one that that that we know today who could get a bunch of value out of working there. And when could be a good time assuming you manage to get in because I think we should be clear getting in is is super hard but for for those there what could be good question to ask of like am I in the right place or 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. Like if you're really super into the specific tech stacks and trying new tools and playing around with new frameworks the second they get out, you know, Google is not for you. Basically, you're not going to be able to use or reuse any of your like triedand-true favorite things because you're going to be working at with completely different things at Google. >> So, you're you're you're basically saying like if you're interested in the frameworks in the industry that startups use that that you build up the knowledge that I don't know like the latest React framework or latest ML framework that is out there that makes you in demand for other places. Right. >> Exactly. So if you like keeping up with the industry like keeping up with the tech industry's cutting edge as opposed to internal Google cutting edge that no one knows except for Google but then you might not be able to talk about it because of the NDA and who know >> exactly. Uh 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. >> It's interesting because the the perception outside will be 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're 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 100 to 20% time where you can work on things but it's going to be you know in addition to your normal work but they do also keep they have some like incubator type teams at Google still uh they have one thing called area 120 you know they build completely new very like startupbased completely new apps uh that very quickly like often just transition straight into the killed by Google graveyard. Uh but you know they'll probably like they will reuse some of this technology as well. So like like there is a like killed by Google is definitely true but it's not like all of it's wasted like they have they yeah they've done so many chat apps and so many social network type things where the products didn't survive but the technology got you know it got incorporated into what's Google chat now and Google meets and you know so like if you're into innovation and trying new things Google can be for you but it's not it's probably also not going to look the way that you imagine. it to look like and if you get in love with your idea and you know the whole 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 like there are some other companies that are that you know keep going up and down right now. Open AAI for example is is also very very recognized and of 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 this 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 likely declining since the last 3 years which has never happened before so until then they were growing basically it was easier to get in uh considering 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 taking 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 the interview process even if you have no intention because their interview process is very very similar to the interview process of the companies that are hardest to get into including the scaleups and startups that are super hot. Open AAI 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 may this be open AI, 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 will often just take the shortcut instead of interviewing you know so many people with with with no proven tracker just go go to the source. So that's one. And then there's a network. Uh because if you're someone who is is curious or talks with other people inside Google, you can build up a really good network. Just getting to know people. Uh the ex Google network is very strong. The the fact that there's a Sugler network who as I understand they 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 if you want to do that. Having it behind your back, it it it can it can strengthen your your your resume and your opportunities for for like a decade or even more to come. You can always say you're ex Googler and the thing is not many people will be able to say that globally. So especially as 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 uh 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 uh 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 compensation how are I signing like we just need to go through team matching and sometimes this team matching can take months and sometimes it comes back with I'm sorry no teams were available or or wanted your profile in in this case so that's the other thing it it is it's kind of it's kind of harder to get into than most places and I've heard that recently uh about like six months ago this happened that uh a bunch of people were rejected and and very disappointed that they couldn't get into So, it's it's one one one of these things. Again, it's it's it's it's it can be frustratingly hard to get in when you want to get in. Uh but again, uh it's good to know cuz I hope that we were able to share some details cuz it 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, a one that is very transparent, which means there's a lot of information overload as well. Oh, yeah. I think if 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 while coding, you'll 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 afterwork 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 I recognized like almost no one and the people I knew it's like no they'd already moved or actually like this used to be the case where the London office used to be kind of a holding hub as well like people would be hired and then go to the London office for a year and then they would move to the zur IC office cuz like immigration wise that was easier from a lot of company uh 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 uh yeah and 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 that they're they're leading. They're a frontier lab. They're one of the few companies who build their own model. Microsoft doesn't even do that or if they do, they're they're kind of hiding it. But they're also a company where a lot of people retire from. So, this is the company where it's 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 some sometimes you know they'll go from engineer to sometimes TLM sometimes to PM and back so there's a lot of mobility but it is one of the places together with maybe Microsoft to some extent Amazon where like I do see people probably in larger amounts or larger percentages just stay there and clearly decide either that they're they're very happy there or that they're the happiest they they can be compared to other options and they do it all the way to retirement and because Google pays as well as as it does. Retirement doesn't necessarily come at the around 65 or whatever the legally mandated is. A lot of people will say I'm retired earlier because I have saved off enough together with with Google's perks and pension program and and whatever that I will now have a very comfortable life. And and you see people in their you know like 50s or so say that they are like early retiring after a decade or 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 the valuation brought it up. But again, it's 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 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 in 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 Google? >> About three. >> Yeah. We could probably go on and we we do have you know we have written deep dives to accompany this podcast. But if you want to go in even more detail about some of this stuff, go check out the deep dive articles. We'll have lots of links. And again, because Google is so open, a lot of this re like a lot of this data you'll just be able to find like you can find the papers we've talked about. You can read the books we mentioned. >> And and that's the thing. Uh one one thing that I would just close with is we could go on. We're we're trying to cap it at a at a reasonable length as as reasonable as it got. And we do have more structured notes in the show notes below uh that 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 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 one for that specific team that you might be working in or 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 pe reason re reasons people go to Google for example or leave Google might be their manager. They had an amazing manager at a company and they happen to move to Google and then they they followed them and the other other way around. So you know people come and go between uh companies like like Google, Meta, big tech, startups and scaleups and there are some things that can be generalized but yeah don't forget if if you meet interesting and valuable uh people just you know keep in touch with them because they might 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 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 uh yeah, hopefully we'll do this again with uh other topics in the future. >> Yeah, let let us know your feedback and hopefully we'll see you in the next one. This was our Google podcast episode. If you'd like to get even more details about Google's engine culture, check out our deep dive article in the primatic engineer newsletter linked in the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and see you in the next