Google’s engineering culture

15 Oct 2025 · 2 h 46 min · 70 chapters

Ask about this episode

Ask anything about it. ChatGPT or Claude reads this page and answers with the times it was said.

Connect VO and ask about every podcast you hear, including the moments you saved. Add to ChatGPT · Add to Claude

In short

Google’s engineering culture, focusing on how Alphabet/Google builds custom infrastructure and tools, how engineering teams work and hire, and what it’s like to join and thrive there.

Guests (and backgrounds)

The episode is hosted by Gergay (author of The Pragmatic Engineer). Co-host/researcher Elin (worked at Google as a UX intern in London in 2015; later engineering). The transcript also includes referenced perspectives from Google engineers/managers (e.g., SRE Dave O’Connor describing early SRE/data center scale; Urs Hölzle is mentioned for “tech island” framing; Namandeep Singh is cited for critique of “too many internal tools”; Manu Cornett is cited for migration/deprecation framing). Treas Banzal is quoted from a founder-acquired-by-Google blog post.

Key claims

  • Google’s engineering culture is driven by “custom everything” due to planet-scale needs from the start (custom stack, networking, orchestration, naming, storage, databases).
  • Hiring and development practices shaped industry norms (algorithmic interviews; SRE role).
  • Google’s profitability (ads-heavy revenue) supports top-tier compensation and investment in tooling.
  • Internal tools and monorepo enable speed, but can create “tech island” lock-in and tool sprawl.

Notable examples

  • Internal systems: Borg (cluster OS), Borgmon/Monarch monitoring, ThirdEye-like error monitoring, B4 networking, BNS naming, Google File System/Colossus, Bigtable/Spanner, Piper (VCS), Critique (code review), CodeSearch, Blaze/Bazel (build), CIDR (cloud IDE), Tricorder, Rapid (release), Boganizer/Taskflow, Guts ticketing.
  • Monorepo scale: ~1B files, ~2B lines, ~86TB content, ~40k commits/day (2015-era numbers).
  • Hiring anecdotes: brain teasers early on; language-agnostic coding; senior candidates can get bumped for competing offers.
  • Culture quote: “second passport” badge unlocking offices and network.
  • Reliability story: Gmail incident leading to manual restore via “g-tape.”

Written by AI. May contain mistakes. Listen to the episode to check what was said.

Chapters

Tap a time to open that second in VO

Sponsor Introduction

0:40 to 0:50

Introduction of the episode's sponsor, Statsig.

“Check out the show notes to learn more about them and our other season sponsor.”

Hosts Introduction

0:50 to 1:30

Hosts introduce themselves and set the stage for a deep dive into Google.

“Hi, I'm Gergay, your podcast host and author of The Pragmatic Engineer.”

Inside Google's Size and Scale

1:30 to 3:30

Discussion on Google's employee numbers, engineering workforce, and market dominance.

“those before I worked as an engineer after that.”

Google's Global Presence

3:30 to 6:00

Exploration of Google's global offices and their significance in the engineering field.

“is more than tv viewers and then gmail has 1.8 billion active users and i i'm pretty sure looking at my newsletter, about 70 % of emails are Gmail.”

Compensation and Recruitment Trends

6:00 to 8:00

Insights on Google's compensation strategies and hiring practices in different regions.

“In New York office, also a big one, Seattle.”

Understanding Google’s Unique Work Environment

8:00 to 11:40

Exploration of Google's distinct work culture and how it affects engineers.

“Bangalore and Hyderabad are two massive offices in India.”

Google's Custom Tech Stack

11:40 to 13:20

Discussion on Google's proprietary technology and its implications for engineering.

“Google, there was this note from a founder who got acquired by Google called Treas Banzal.”

Influence on the Tech Industry

13:20 to 14:00

How Google's practices have reshaped hiring standards and engineering roles in the industry.

“And yeah, the badge is really the passport to that, really.”

Google's Impact on Hiring and Internal Tools

14:00 to 16:49

Explore how Google's hiring practices and internal tools have influenced the tech industry.

“own stuff and it works really well for them, which has an interesting outcome.”

Custom Infrastructure and Early Innovations

16:49 to 23:11

Learn about Google's unique infrastructure and the innovations that set them apart.

“is they have completely custom internal infrastructure even today.”
Show all 70 chapters

Google's Advanced Systems and Approaches

23:11 to 28:05

Delve into the advanced systems Google developed for managing massive data operations.

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

Understanding Google's Database Ecosystem

28:05 to 30:05

Explore the various database systems Google employs and their specific use cases.

“Or you want guaranteed that it's distributed.”

Google's Product Evolution and Infrastructure

30:05 to 33:08

Learn how Google expanded beyond search to other products and the infrastructure that supports it.

“There were so many, like 50 plus or even more that people use, and they're all built by actually experienced teams.”

Google's Custom Development Tools

34:30 to 36:54

Dive into the unique tools Google uses for software development and project management.

“It's, again, from a search company, you wouldn't expect anything less.”

The Unique Tech Ecosystem at Google

36:54 to 41:46

Understand how Google's unique tech stack affects onboarding and external collaboration.

“Like most Googlers will not have code locally on their machines and kind of haven't ever.”

Externalizing Google's Technology: GCP and Beyond

41:46 to 42:00

Learn about how Google externalizes its technologies through the Google Cloud Platform.

“And that's actually, so when they started GCP, the Google Cloud platform, you know, a lot of that is what they refer to as externalizing.”

Google's Internal Tools and Challenges

42:00 to 43:35

Learn about Google's extensive internal tools and the challenges they present to engineers.

“So making offers that, you know, can be used by other companies.”

The Unique Culture of Google Offices

43:35 to 45:57

Discover the unique culture and quirky decor of Google offices worldwide.

“You have to go and read the code and you have to fix it yourselves.”

Compensation and Perks at Google

45:57 to 49:48

Explore the generous compensation packages and perks that Google offers to its engineers.

“If you have the chance to go visit a Google office, especially one of the bigger ones, do it.”

On-Call Responsibilities and Management

49:48 to 55:28

Understand how Google manages on-call responsibilities to support its engineers.

“In Munich, it will be somewhere to 190 to 220 ,000 euros.”

Roles and Career Paths at Google

55:28 to 56:00

Learn about the different engineering roles and career paths available at Google.

“If you work at Google, you'll likely be...”

Understanding Google's Engineering Roles

56:00 to 58:00

Learn about the various engineering roles at Google, including their unique structures.

“That's their primary focus is making sure that the team is healthy.”

Tech Lead Manager Role at Google

58:00 to 1:01:00

Explore the unique Tech Lead Manager position and its significance within small teams.

“They'll make sure that, you know, like tech decisions get made.”

Promotion Paths and Levels at Google

1:01:00 to 1:04:40

Discover the different promotion levels at Google and the implications for engineers.

“but it's really hard to be promoted when you're kind of expected to both be in.”

Performance Reviews and the Grad System

1:04:40 to 1:07:20

Understand the performance review process at Google and the transition to the Grad system.

“you need to like ship a kind of a project that shows that you're ready for senior.”

Impact Ratings and Calibration Meetings

1:07:20 to 1:10:01

Learn about the impact ratings and how calibration meetings affect employee evaluations.

“Well, I mean, until a few years, and I'm sure after five, 10 years, people are just probably like, all right, here we go again, especially if you're not wanting to move up.”

The Impact of Performance Management at Google

1:10:01 to 1:11:14

Learn about Google's performance management system and its implications for engineers.

“And now it's back to the usual of like, there is this bucketing.”

Opportunities for Engineers Beyond Coding

1:11:15 to 1:12:42

Discover how Google provides various opportunities for engineers to enhance their careers.

“But as an engineer, not much you can do beyond, you know, document your impact, have a good relationship with your manager and hope that that manager stands up for the people on their team.”

The Code Review Process and Readability

1:12:43 to 1:14:09

Understand the unique code review process at Google, focusing on readability standards.

“especially, I guess this is true for especially the levels like we're talking L3, L4, L5, above that.”

Promotion Committees and Their Role

1:14:10 to 1:16:36

Explore how Google's promotion committee works to eliminate bias in the promotion process.

“You need to like shadow, I think, be signed off, that kind of stuff.”

The Pitfalls of Promotion-Driven Development

1:16:37 to 1:20:25

Learn about the risks of focusing solely on promotion within Google's culture.

“together and they're like, all right, is, you know, Johnny ready for a promotion?”

Google's Innovation Culture and Project Management

1:20:26 to 1:22:49

Examine how Google's culture fosters creativity and innovation, often leading to project discontinuation.

“But also, this is where we should talk a little bit about promotion-driven development.”

Engineering-Driven vs. Design-Driven Cultures

1:22:50 to 1:24:00

Compare Google's engineering-driven focus with other tech companies' approaches.

“And again, because look at it, I guess we can make fun of how Google discontinues Stadia, a gaming console or Google Reader.”

Engineering-Driven Culture at Google

1:24:00 to 1:25:19

Learn about Google's focus on engineering and how it influences project ownership and maintenance.

“If you compare that to, say, Apple, which is much more kind of like the design and user experience driven.”

The Importance of Design Docs

1:25:20 to 1:26:46

Discover how Google emphasizes design documents to ensure project clarity and collaboration.

“Whereas if you're a product person at Google, you'd have to convince engineers and do this whole thing of getting headcounts and stuff.”

Consensus and Googliness

1:26:47 to 1:28:49

Understand the concept of 'Googliness' and its impact on teamwork and organization culture.

“And there's actually, like we've mentioned the SRE book.”

Understanding Software Engineering Teams

1:28:50 to 1:31:09

Explore Google's approach to managing engineering teams and their historical experiments.

“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 Piper and the Monorepo and the critique and all that stuff.”

The 'Killed by Google' Phenomenon

1:31:10 to 1:32:10

Examine the reasons behind Google's many failed products and the freedom engineers have.

“And then you build products that might not make sense.”

The Role of OKRs in Google's Success

1:32:11 to 1:36:18

Learn how OKRs were introduced at Google and their significance in goal setting.

“the other side of the coin yeah one interesting thing that comes up with google outside and but But I want to touch on this.”

Critical Perspective on OKRs

1:36:19 to 1:37:40

Delve into a critical view of OKRs and their perceived impact on Google's success.

“I'm sure it helps, but I think it's a bit overblown.”

Communication Culture at Google

1:37:41 to 1:38:05

Discuss the open communication culture at Google and its historical practices.

TGIF: Google's Weekly All-Hands Meetings

1:38:05 to 1:40:08

Learn about Google's weekly town hall meetings and their cultural significance.

“the monorepo and the fact that everyone has access to everything anyways.”

The Fragmented Organization at Google

1:40:08 to 1:42:08

Explore how Google's organizational structure affects communication and teams.

“And then that, you know, it kind of trickles down in a way because like Google organization is very fragmented.”

The Challenge of Transparency in Large Companies

1:42:08 to 1:44:06

Discuss the pros and cons of transparency in large companies like Google and Uber.

“Like, I don't want to be here, but I need to show up because the SVP is here and whatever.”

Re-Googlers: The Return of Former Employees

1:44:06 to 1:46:02

Discover Google's program aimed at re-hiring former employees and its success.

“because that also used to be a thing where like you can work on something that's like primarily based in the US in Mountain View, but you can be in and based wherever you want.”

Understanding 'Googliness': The Company Culture

1:46:02 to 1:48:09

Unpack the concept of 'googliness' and its significance in Google's work environment.

Ethical Dilemmas in Google's Operations

1:48:09 to 1:51:41

Examine ethical challenges faced by Google and the implications for engineers.

“Google culture and Googliness is more about teamwork and succeeding together.”

User vs. Customer: A Distinct Google Perspective

1:51:41 to 1:52:00

Analyze how Google differentiates between users and customers in their approach.

“Yeah, it's great that they printed it in the book.”

User vs. Customer in Google's Culture

1:52:00 to 1:53:08

Explore how Google differentiates between users and customers in its business model.

“They do say user, but there's no customer.”

The Evolution of Google Cloud Platform

1:53:08 to 1:54:49

Learn about the origins and development of Google Cloud Platform and its initial offerings.

“And then, you know, they had these, you know, they externalized parts of this.”

Customer Experience and Support Issues

1:54:49 to 1:55:41

Hear about the frustrations users face regarding Google’s customer support systems.

“And now they had to worry us about like index rights.”

Competition in Cloud Services

1:55:41 to 1:57:18

Discuss the competitive landscape of cloud services and Google's position in it.

“Most companies will put them at the top, and Google just treats them the same as free users.”

Google's Internal Infrastructure vs. GCP

1:57:18 to 1:58:31

Examine the differences between Google’s internal infrastructure and Google Cloud Platform.

“Yeah, so they've had a few, from my understanding, my research, they have a few, like they've made attempts to move and migrate some stuff over to GCP and there are things that run on GCP.”

Strategic Decisions and Trade-offs at Google

1:58:31 to 2:01:02

Analyze the strategic decisions Google makes regarding its services and the implications.

“But then again, it's like, do they have to win at cloud?”

Internal Mobility and Team Dynamics

2:01:02 to 2:03:09

Discover how internal mobility works at Google and its impact on team dynamics.

“It just might not work as much, especially when you have like all the permission systems that are like built, baked in internally.”

The Concept of Singleton Roles

2:03:09 to 2:06:01

Understand the unique role of singletons in team structures within Google.

“We're now talking about the LLM stack, for example, that might be custom.”

Understanding Singletons and Rewrites at Google

2:06:01 to 2:08:49

Learn about the concept of singletons in teams and Google's approach to continual code rewrites.

“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 the new location, essentially.”

Team Mobility and Migration Challenges

2:08:50 to 2:11:20

Explore the dynamics of team mobility and the challenges of migration within Google's environment.

“So once you've done a migration and you're seeing the next one's coming, you might just move teams.”

Google's Open Source Contributions

2:11:21 to 2:13:54

Discover the significant open source projects and contributions made by Google to the tech industry.

“And I do feel like, and like I was reading through some of their old like tech posts, blog posts as well.”

The Evolution of Google's Internal Culture

2:13:55 to 2:15:24

Learn about the shifting culture within Google, including the impact of the pandemic and internal transparency.

“It was probably some engineers thinking like, ah, it's a cool idea.”

The Changing Landscape of Tech Employment

2:15:25 to 2:20:01

Understand the recent shifts in tech employment, layoffs, and the evolving landscape post-pandemic.

“Also, during the pandemic, you know, they had some big leaks.”

The Changing Landscape of Google

2:20:01 to 2:25:33

Explore how Google's workplace vibe has shifted over the years and the impact on employees.

“And, you know, Google search results are like a lot of them are sponsored.”

Understanding Google's Business Model

2:25:34 to 2:28:45

Learn about the financial dynamics of Google that affect employee roles and responsibilities.

“In 1998, like just an idea to one of the biggest companies in the world.”

Navigating Career Paths at Google

2:28:46 to 2:31:26

Discover what types of professionals thrive at Google and the skills that are valued.

“Search worse to have people see more ads to generate more revenue.”

Innovation vs. Stability at Google

2:31:27 to 2:34:06

Discuss the balance between innovation and stability in Google's work environment.

“But for those there, what could be a good question to ask of like, am I in the right place?”

Google's Innovation and Product Lifecycle

2:34:06 to 2:35:16

Learn about Google's approach to innovation and product management, including the concept of 'killed by Google'.

“But they do also keep, they have some like incubator type teams at Google still.”

The Value of Google's Brand and Hiring Challenges

2:35:17 to 2:37:44

Understand the prestige of working at Google and the challenges of the hiring process amidst a flat workforce.

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

Navigating Team Matching and Work Environment

2:37:45 to 2:39:56

Explore the team matching process at Google and the work environment that comes with it.

“Having it behind your back, it can strengthen your resume and your opportunities for like a decade or even more to come.”

Google's Long-term Employment Culture

2:39:57 to 2:42:16

Discuss Google's retention trends and the culture that encourages long-term employment.

“or if it stresses you out to have to go to a meeting middle of the day while coding, you'll probably hate this place, probably.”

Sharing Insights on Google's Work Dynamics

2:42:17 to 2:45:44

Reflect on the dynamics at Google, including team mobility and the importance of personal connections.

“And they do it all the way to retirement.”
Hear the part that matters, and keep it.Open this episode in VO. Double tap your headphones to save a moment as you listen.
Get VO free

Transcript

Automatic transcript. May contain errors.

0:00Google is the world's most used company by the number of users between products like Google search, YouTube, Chrome, Android, Android, and many more. Well, what's the company like from an engineering point of view? We've spent months researching this topic to bring you the most detailed deep dive to date on Google's engineering culture. We go into Google's unique tech stack and why every tool is custom at the company, how Google works, roles, compensation, performance reviews, on-call, and internal mobility, how Google changed over the decades and advice on how to thrive at the Google of today as a software engineer, and many more topics.

0:31If you ever wanted to work at Google as an engineer or manager, or want to understand how one of the world's most innovative tech companies operates, this episode is for you. This podcast episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsor. So let's get started. Hi, I'm Gergay, your podcast host and author of The Pragmatic Engineer. Hi, I'm Elin, and you may or may not know me as the researcher of The Pragmatic Engineer. You might have seen my byline in some of our deep dives and survey articles.

1:06And today we're going to try out this new format to bring you a deep dive by talking you through everything Google. So I was an intern at Google for a couple of months back in 2015. I was based in the London office, worked as a UX intern, actually. those before I worked as an engineer after that. So I have a little bit of inside vibes, but not that much. Let's start with, everyone knows Google, for sure. You cannot not know it. But what are some interesting stuff we found about them? The numbers, if we're going to go there. 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 but obviously the majority of that is in google we have numbers from 2020 that there were about 50 000 engineers and that's up so like in 2015 which was the first time they came out with a lot of the numbers about the engineering org there were 25 000 engineers i think size wise this makes them similar to microsoft in total employee count for engineers a bit unclear maybe google has more baby microsoft probably similar to amazon but amazon has weird numbers because they kind of mesh the the workers but they're a lot bigger than meta for example like they're they're like i think two three times bigger so they're easily one of the biggest kind of top tech companies in the world if not the biggest i i think the question is with microsoft but i think when it comes to prestige uh compensation uh they're they're easy number one in in this regards uh scale of of work that people work on and speaking of of scale uh you know like again microsoft might have similar number of employees but when it comes to google i think numbers are a bit unclear but around three to four billion people per month use their services between search gmail youtube i mean all of these are marketing services right i think search is more than 1 billion people per day which is kind of one like every i think nine person in the world uses search youtube has 2.5 billion monthly which is more than tv viewers and then gmail has 1.8 billion active users and i i'm pretty sure looking at my newsletter, about 70 % of emails are Gmail.

3:44Yeah, for sure. I've seen the same stats. And if you broaden out the Google Workspace apps, including Drive and Docs and Calendar and stuff, they have over 3 billion users and over 50 % market share. They're so far ahead of Microsoft often office essentially with youtube as well like i can't help i i'm a big youtube user and have been for a long time and i i'm always so fascinated by their general stats uh like there's five billion videos on youtube not all of them are necessarily like up and available like the latest numbers 360 hours of content is uploaded every single minute yeah that's a lot of parallel processing There's 2.6 million videos uploaded every day, almost a billion a year.

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

5:18And in terms of the footprint... Yeah, Google's big, like just globally as well. They have 72 offices in over 50 countries or 50 countries. So they have offices all around the globe. US, Europe, Asia, Sydney, Brazil. Yeah, but what we care mostly about is engineering. So their engineering offices, there's about like, there's more than 25 ones, but the kind of the big ones that we should definitely mention, headquarters, Mountain View and Silicon Valley. The Googleplex. The Googleplex, yeah. really cool office, like really cool kind of perks, Android figures. It was so cool. I was there last year.

5:59Adi Osmani took me around on the Chrome team. In New York office, also a big one, Seattle. And they have a lot of offices in, like smaller ones in the US, LA, Pittsburgh, Boulder, a lot of like specialized ones. Cambridge and Massachusetts is pretty big as well. Yeah, the Seattle office is definitely one of the bigger ones. And you might hear it referred to as Kirkland as well, because Kirkland is the suburb of Seattle where it is. And it's, yeah, lots of cloud is based there. Yeah. And then Europe and the UK have large offices. The biggest one known in Europe is Zurich. It's actually probably Google's European HQ in terms of engineering, if you will.

6:42And a fun fact is that Zurich pays almost as much in compensation as in the US, which is really, really interesting. Interesting. A lot higher than other European offices. London is another huge office. Dublin, a big one. Dublin, I think, might be bigger than Zurich in terms of people, but not necessarily engineering. They have a lot of sales. Yeah, yeah. Makes sense. Oh, you're right. I actually used to have friends, non-technical, who were in Dublin. Yeah, you're right. You're probably big, but I was thinking engineering. Yeah, engineering Zurich is the biggest hub for sure. Munich is a big one for engineering.

7:20as well. In Germany, they have a Berlin one. 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 Budapest, Hungary, they had a very small engineering office. I think they still have it. It's tiny compared to all these other ones. Yeah, there's actually one here. I'm based in Stockholm. So they have an office here as well. That's grown a fair bit. It's like a few hundred people and fairly big on the engineering side, work a lot on video meets and calls and stuff.

7:53And a lot of US tech companies would stop here, but Google obviously being Google, they have engineering offices a lot of other places. Bangalore and Hyderabad are two massive offices in India. They've grown so much as well. Like they're, and growing. Those are like a lot of the open positions are based in India. Yeah, we had an issue with that when I used to work at Uber as an engineering manager, we were hiring in Bangalore. And what we found is we had trouble hiring senior engineers because whenever we'd extend an offer and that person was interviewing at Google, Google would offer 10 % more than whatever we did, always 10 % more.

8:35So after a while, this was back several years ago, but the team kind of backed down and they started to hire less experienced engineers. 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 a senior and above, Google almost always will offer more. They don't care too much about their internal bans. Again, over time, this might have changed. And for more junior positions, this could have changed. But I had a director friend who was in the situation between having a competing offer at Meta and Google, and it was really high already.

9:12And then Google just really wanted this person and they just offered more. So Google, like when you become in demand, this is a really interesting situation. But it's kind of an open secret on the job market. And then they have offices in Tokyo, Japan, Sydney, Australia, and probably every kind of major city. And you'll have like, so Google has so many offices, right? And engineering can pop up anywhere. Yeah, exactly. They have a pretty big one in Brazil as well, in Sao Paulo. They have a lot of search engineers. But it's also, it's funny because one of the stats for Google is like they've always had such good revenue.

9:52So like back in 2024, there was$350 billion in revenue. 75 % of that comes from ads. And I think Google, like they've done good for themselves because they figured out such a good revenue model from day one for themselves. So they've always been able to offer all of these high salaries and pay for so much stuff. I'm going to challenge you a little bit because we know Google is insanely profitable, right? There is no doubt about it. However, when we look a little bit closer at the unit economics, and we're going to quickly move to engineering, but let's talk about where the money comes from. Google's profit margin of on$100, how many dollars of profit is around 30 % or 35%.

10:39So like, you know,$30 or$35 are pure profit. And they're not the most profitable company. Companies like Visa or MasterCard and Adyen, they do about$60 or 60 % profit rate. But those companies don't pay as much as Google does for their engineers. So there's this interesting thing where there have been companies earlier who have found out similarly really lucrative, really good business models. Again, like with MasterCard, you know, you make a transaction, they take a percentage, they built up the global network, boom, profit. but they don't compensate engineers or they don't they don't kind of treat engineers the way google does which we're going to talk a lot about so i think google does 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.

11:38Now, one interesting thing that I wanted to bring up is when you joined Google, there was this note from a founder who got acquired by Google called Treas Banzal. A 10 % startup got acquired several years ago. And on a blog post, this is what he wrote. He wrote, working at Google is like having a second passport. Go to any major city in the world and your badge unlocks beautiful office with great food, great desk and a high speed linked to every person in Google's 200 ,000 person network. And it's like visiting Americans and foreigners. Everything you see inside feels oddly familiar because of its massive export influence.

12:15Yet it's just slightly different. I thought this is fascinating. So like when you join Google, you have suddenly access to all the offices. You can go into any of the offices. I mean, travel budgets permitting, I understand they now have some of those. But yeah, you have access to this and to all of the people. I think this is something that a lot of people don't realize. from the outside of just how it's it is one company but it's also more yeah that actually resonates quite a lot with my experience my brief experience there as well again we'll get into this but yeah I think Google is so special especially if you compare it to the other big tech companies because like in many ways like there's no one Google like it's not one company working on one thing from very early on they worked on so many different things so like 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.

13:38And yeah, the badge is really the passport to that, really. It's a really fascinating place to be. So Google has the most unique tech stack in the world, and we're going to go into a lot more detail, but they have custom built everything. So unlike almost every other startup or company that has some level of standard tech stack that the rest of the industry uses. Google just uses their own stuff and it works really well for them, which has an interesting outcome. 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.

14:16They started with the algorithmic interviews and they kind of, I guess, the perception of how Google having a hiring bar made it go mainstream across the tech industry. And then they also invented roles like the SRE role, which is now kind of pretty widespread across other companies as well. Yeah, exactly. Even though it might be called something slightly different with like, you know, DevOps, reliability, engineering, et cetera, et cetera. One thing that is very unique about Google is how many internal tools that they've built. Borg, Blaze, Piper, Critique, CodeSearch. We'll talk about a lot of them today.

14:49Yeah, 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, A-B testing, feature controls, all of them together seriously. They built advanced tools and made it available to their thousands of engineers and data scientists. This was the approach that enabled the fast-moving bottoms-up approach to product development.

15:21And this practice of having your engineering teams have access to these tools really did become the baseline for standout tech companies. For the last 15 years, pretty much every major tech company has had entire teams of people rebuilding this kind of feature flagging, A-B testing stack of tools internally. But now something interesting is happening with the latest generation of tech giants. Rather than building these tools, companies like OpenAI, Entropic, Figma, Notion, and a bunch of others, they're just using Statsig. Statsig has rebuilt this entire suite of data tools that was available at maybe 10 or 15 giants in such a powerful way until now.

15:58They built experimentation with proper statistical analysis, feature flags for safe deployments, session replace, analytics, and more, all backed by a single set of product data. And one really nice thing about Statsig, it's not just about saving engineering time. It's about getting world-class infrastructure from day one without having to build it yourself. Rather than arguing about metrics definition or troubleshooting broken tools, engineering teams can just focus on building a really great product. The other thing is scale. Since Statsig already processes trillions of events per day, which is enormous data, by the way, they also scale with you.

16:32Plus, you can integrate Statsig 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 statsig.com slash pragmatic. They have a generous free tier, a$50 ,000 starter program, affordable enterprise plans. just tell them the pragmatic engineer sent you. So one thing that is like so unique about Google is they have completely custom internal infrastructure even today. And there's a reason for this. Because when they started, back then they needed to build this knowing how the existing tools didn't work for their scale.

17:06So let's talk through some of the unique tool set that someone will see if they start to work inside Google or if they're working there, they see them. Yeah, exactly. And I think actually it's like why this tech stack looks the way it does is very like it's because it was search. It's like, well, this needs to be global from day one. So we need to have this infrastructure from day one to get the speed and reliability that we want. And so that's why they just jumped straight ahead with like, we'll just build custom stuff from the ground up. So yeah, like they scaled into six digits of machines in the early 2000s.

17:53So like hundreds of thousands of machines? Yeah, in their data centers. Yeah, there was a pragmatic engineer post from an SRE a couple months ago, I want to say, where he talks about, he started at Google doing SRE in 2004, I think it was. And already when he started, there were hundreds of thousands of machines. And this was during a time when large data centers had hundreds or maybe thousands of machines. Yeah, yeah. This is Dave O 'Connor. And he was telling me that I think in Ireland, they visited a data center because they want to see how they worked and they want to see if they could use them.

18:34And 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 you have and i think they have like maybe a thousand or so and they just did manually and then they were telling them like well that wouldn't really work for us because we're applying to have at least 10 000 machines but maybe 30 soon and they were like what are you guys talking about like that's so because of this like the kind of the most advanced solutions in the case of data centers they didn't have the ambitions that google had And that's why, like, even in the early days, like, they knew, like, okay, we cannot do what everyone else is doing.

19:08We need to figure out, build new automation, build new tools. And that's actually how they invented the Site Reliability Engineer role. They actually needed software engineers who now became experts at, like, operating infrastructure, which was unheard of. Because until then, you had the IT guys who knew how to configure, you know, Windows machines or Linux machines and knew how to patch them, how to plug in, how to, you know, make sure, like, do all these things. But they were not software engineers because why would you hire a software engineer to do that? So, like, Google did a bunch of these things.

19:42And that's where, obviously, one of the biggest internal tools, which we mentioned, Borg, comes from, which is orchestration system. And Kubernetes was inspired by this. In fact, Google created Kubernetes based on lessons learned from Borg, and they released it in open source. And internally, they still use Borg. Yeah, exactly. So Borg is basically a cluster operating system. And then, you know what Google's kind of internal version of Datadog is called? Borgmon. Oh, yeah. There's also one called Monarch. I'm not sure which one is which. But yeah, so they have this monitoring, which is like integrated into Borg.

20:19And this is one of the reasons, by the way, people are like, oh, why doesn't Google just move to Kubernetes? And well, I mean, then they would need to replace some of these things. And then they have this thing called ThirdEye, which is pretty much what Sentry is from the outside world. And that's also nicely integrated into all of these systems. It's kind of like you've got all the hooks, got all the APIs. Yeah, like all of the tech stack is custom. Like there's nothing that's not custom in the Google tech stack. So Borg, they call it a cluster operating system. and 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.

21:18Like, because it was like planet scale search from the get go, they never had to think about, you know, like, oh, what's the data center for like the smallest need? Because their need was so huge from the get go. Well, and there was this interesting thing, right? Where until Google, the way to operate servers was to buy these really expensive sun racks, the kind of like, you know, like mainframes pretty much, super powerful machines. And Google also had this innovation where they started to just use plain old PCs. Initially, the issue just took simple PCs that they put together on like the mainframe, the CPU, the hard drive, and they just put it together and put it in data center.

21:58And people were like, what? That's so silly. But they're like, look, we're getting a lot better value for a bug instead of a$2 ,000 machine. We can have 20$100 machines and we can have throughput of three times. And then they started to take this a bit more seriously and started to manufacture their own servers, which cannot be bought by anyone, but that's how their internal data centers are built. Google Cloud these days is built like that as well, but Google's own infrastructure is probably bigger than Google Cloud, interesting enough. But just to your point, they built a larger scale compute than anyone needed at the time.

22:37Yeah, 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, 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 realize 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.

23:32And probably anyone who heard of it was like, what are you doing? Why are you, why would you do that? Well, Jeff Bezos might've heard of it because he was an investor and, you know, like AWS later launched their public cloud, but, but yeah, it's, it was, yeah. And I think it wasn't just, just unheard of it, but I think this goes back to like, Google was seen very kind of weird a little bit, or like almost mythical for how they hired. Cause like the way most tech companies would hire at the time is they would ask you programming questions of like, I don't know, they hired a Java programmer. They would ask you, all right, how does your memory allocation work in Java?

24:07Stuff like that. Or they would ask about design patterns or stuff like that. And Google would ask brain teasers, famously. They would ask, okay, how many golf balls can you fit in a van or something like that? And apparently, the reason they did this initially, and they stopped doing it after 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.

24:46They 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 write code with in a coding exercise oftentimes you you can use any language or sometimes you use sealer code if it's an algorithmic interview this is one of the reasons they love algorithms with all interviews.

25:22No specific language required. Yeah, and I guess that makes sense as well because the Google tech stack is so unique, it won't matter anyway. They need you to have open horizons and be flexible and solve problems because you're going to solve them differently at Google anyway. Going back and speaking of just how custom it is, the fact that when they built out these data centers, They also like they couldn't use or didn't want to use opted away from using normal like networking stacks and switchboards and stuff. They built that from scale as well. Yeah. Why? So they have something called B4, which is like the backbone networking infrastructure that has ridiculous bandwidth.

26:09And that's the thing that they built out so that their data centers and the ridiculous scale of the machines could talk to each other. And that Borg was able to coordinate job allocations. they also chose not to do DNS the standard way because they developed something called Borg naming service so the BNS and that's because obviously like at that point and very often you will you know have a specific IP address and specific ports but Borg from the get-go was very like, well, anything can run anywhere. So they wanted a level of abstraction higher than that. What Borg does is that they allocate resources for jobs and memory and CPUs across machines.

27:05So the actual IP address to the machines, it has to happen fluidly because they don't allocate specific machines. It's broader than that. It's more like cluster level. And a cluster is like racks of machines. So they needed that abstraction. They needed the 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. I was like, we don't like a machine will fail. We don't care.

27:38Well, like another machine will come in and take over. And similarly, they built out the Google file system back in 2003 or well, they talked about it in 2003. which was also necessary because of that so like a huge decentralized file system like in 2003 they had hundreds of terabytes of storage across thousands of disks and machines accessible by hundreds of clients it had this like basically a storage stack where you had disks like actual physical hard drives and then an abstraction called d above that for a disk but like the disk could be either a disk or something else and then you had the like the google file system on top of that which was later preceded by colossus which is what they use now and then on top of that they built out all of these like database like services so things like big table like spanner like there's not just like the one database because it depends obviously on the uses of the database like what are you optimizing for and so internally they have lots of different variables and like kind of database systems as well where they will have some of their data centers are like more specifically for you know better for a certain type of data storage and certain types of database you know big table is more no sql sparse it's distributed it's persistent spanner you have a more sql like interface it's more important for like real consistency across the world yeah so as i guess a trade-off sort of like is it like write intensive is it read intensive what kind of data are you storing like how structured does it need to be how are you wanting to access it right so these are all the differences between the reasons they have and then like as you said the distribution like Like you just want it on one machine and if it dies, it's totally fine.

29:42Or you want guaranteed that it's distributed. Then do you want consistency that immediately as soon as you write is there, but then there's a latency or then you want to minimize that. Or you don't care if it's eventually consistent and then you can write. So like there's a good question of like, why does Google have so many databases? And I guess this goes back to like, why are there so many databases? There's so many databases. Like we just did on the pragmatic engineer survey. There were so many, like 50 plus or even more that people use, and they're all built by actually experienced teams.

30:15That's kind of an interesting side question. Why so many databases? Yeah, 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 they didn't just focus on the one search product. You know, they built out Gmail, which was basically email with built-in spam filters, was like the pitch from early on, as well as a gigabyte of storage, which was also unheard of at the time. And then they branched out into, you know, Google Calendar, Google Docs. They did some really big and smart acquisitions like YouTube, Android.

Read the full transcript

31:02You know, they had the tech infrastructure that they had, and then they started getting all of these new use cases, basically companies operating on top of this stack. And so they were able, like had the needs, had the expertise and had the data centers and the infrastructure to build out all of these different offerings for their own products. I don't know if this is still happening, but they did actually, for a long time at least, and possibly still, they also had backups for all of their data centers on physical tape. Wow. I mean, tape is durable, so. Yeah, there are in the SRE book, which was published in, I want to say 2015, 2016, which is available online.

31:56You 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 % 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 g-tape which was their physical tape and they spent a couple days manually going through the tapes to restore the data to the users there's this article published by google called 10 things we know to be true it's a set of beliefs that they published when the company was just a few years old and what surprised me is how many of these are still true today.

32:49Did you read this article? Yeah. And then the fastest, 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 a number one. It's pretty clear that engineers or even teams that are faster than a competition and are quick to make decisions, they use tools that are also fast in how they manage their work.

33:29And all of this brings us nicely to our seasoned sponsor, Linear. Linear actually dominated the project management responses this survey as a tool that techies love using. In fact, it was the most loved project management tool. It wasn't even close. From the responses, it was clear that the big part of this was due to how fast Linear is to use. Right after we posted a survey result, Linear reached out wanting to work together, and it was a super easy yes. I've since been talking with the Linear team about how OpenAI and Perplexity switched to Linear. And a big reason for these companies to move was how Linear enables velocity in their product workflows.

34:02I'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 Lunar.app. slash pragmatic and then outside of infrastructure like google has so many other custom systems i'll just name a few because 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 use piper something called piper that's their version control system instead of pull requests they they have this thing called cl changelist for their code review tools called critique and it's integrated with so many other tools that have a lot of ai function now built into it it's it's a little bit like github's pull request review code search has been a very kind of infamous tool that that inspires source graph so you can you can search all of google's repositories and again they they do have a monorepo but they have incredible amounts of code and it's rapid.

35:24It's, again, from a search company, you wouldn't expect anything less. But apparently, for a long time, when I talked with Sourcegraph founders, they were saying that code searches, they had parts that were better than Sourcegraph's own offering. I think now Sourcegraph is catching up. But I still remember when I first used Sourcegraph at Uber and it was just so fast. And I was like, wow, this is so, so cool to use. But apparently, that's the norm at Google. And most companies never had this until maybe they tried to build it for themselves, but it wouldn't be worth it building for your own. Yeah.

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

36:35Blaze, which they open sourced a thing called Bazel, which is similar enough, which is also really fast and really good. Yeah. And it's, you know, this distributed build system that, yeah, it's kind of core of how, it's core of how they build. It's very distributed very quickly. It enables the monorepo in the ridiculous scale it's at, but it's also deeply ingrained into how they do the development itself, which is very in the cloud, actually. Like most Googlers will not have code locally on their machines and kind of haven't ever. It's kind of a system called clients in the cloud or CITSI, which is the way they they're programming, which is, yeah, like not on device, but, you know, connect to clients in the cloud.

37:27These days, it seems like they mostly do that through a tool called CIDR, which is actually a fork of VS code. Well, now it is, right? It used to not be. Yeah, it used to be something else. It used to be a web-based tool. Yeah, I used it a little bit when I was interning there. And I think like back then it felt kind of niche. But then I think that's changed a lot. I guess partially since forking VS Code, I bet it's looking much nicer than it did when I was there. I hear a lot more people are using it, so yeah. Again, because everything is custom, everything is also so connected. So CIDR is deeply integrated into Critique that they use for code reviews, which is deeply integrated to their CI test automation program.

38:20They have tools like Tricorder, which runs tests, static analysis, all that stuff. Speaking of Rapid, their release automation tool is called Rapid, or one of them. rather. CodeSearch is integrated into all of that as well. And obviously CodeSearch is, you know, like they had to build that out because the monorepo was so huge. Speaking of like, like working together or how they work, like, you know, when you think of Google's, like what they use for project management, you know, their kind of version of GRS slash linear, and they have Boganizer, again, a custom tool. And they have this tool called Taskflow, which is a UI on top of Boganizer for boards, Kanban, and other kind of management tooling.

39:05And then they have Guts, which is Google Universal Ticketing System. It's more for tech support. When you open a ticket, you can think of it like Zendesk or Jira Tickets or just any ticketing system. But it's so interesting how they even built that for themselves as well. But it's also, it makes sense because I guess when you have the infrastructure so unique, it's like, oh, well, you need to implement this. So where does that come in? And actually, I think Boganizer in particular is also probably the integration with CIDR and Critique. and but like because everything is so custom everything is like made for each other as well so using Baganizer you know you can report but also like fix do small fixes like immediately in the same environment that you're already in because it's 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 think long-time Google engineer or executive Urs Hörze might have said this.

40:17Google is a tech island. There's the rest of the world which is using pretty standardized things. Most startups will be using AWS tooling, or for containers, it'll be Kubernetes, or for front-end framers, it'll be React. And for database, it'll be Postgres or something that is out there. But for Google, everything is separate. And there was this recognition even inside Google that this could be a problem, that they're so unique that they cannot take advantage of other open source projects, for example, developing. But also it's very expensive to onboard. It's just for new joiners, you know, they have to throw away every knowledge.

40:57And 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 next job. But I don't think this has changed. I think Google is like, nah, you know, like they probably talked a little bit about it, but, and maybe it cannot even change that much because it didn't start because Google, it didn't feel, doesn't feel to me that it started because Google said like, no, we need to do something different. Yeah. I think it's more like, like we've been talking about, like they kind of had to do something different from the get-go.

41:27And I think when you end up in a situation where basically you've invented your entire own kind of internet or like way of communicating across computers, like from the ground up, and you build out stuff on top of that. Like, yeah, I don't know, even know if it's possible for them to move over. And that's actually, so when they started GCP, the Google Cloud platform, you know, a lot of that is what they refer to as externalizing. So they're externalizing, They're not open sourcing because it's still like they're on their own tech stack, but they are externalizing. So making offers that, you know, can be used by other companies.

42:12So Kubernetes is the externalized version of Borg. And it's not the same, but it's, you know, heavily inspired by it. Like slightly different architecture, slightly different feature set because it doesn't have to cater to just Google. And the same for, you know, Bigtable, Spanner. Yeah, basically everything in the Google Cloud platform. And actually also to mention gRPC. gRPC, which is a way of communicating across services, that is something that is also externalized. Internally, it's called stubby. And that is the way that they communicate across services. and it's yeah it's the internalized um dRPC they use protobuf as like the messages for how to communicate across services and then dRPC is the way they do that yeah all all this internal tooling I think like for a feedback I often hear from people going to Google is how they're just really surprised at how it is and of course people who've been there for long enough they gotten used to it when they go outside they're often really kind of taking aback by how little other companies have it for example if you spend most of your career at google and move to any other company like often googlers will look for the equivalent of like whatever google tool had at this company which might or might not not not exist but there was uh this uh a person that need code as his name is Namandeep Singh who well he creates one of the most popular coding solutions he worked at Google for I think about a year and he said he did a video about the one of the worst things about Google and he said how it's too many internal tools and what he said is I'm coding him Google has this problem that they have an internal tool for literally everything so and sometimes all the internal tools don't have massive teams supporting them sometimes it's just one guy working on an internal tool, trying to get promoted, then maybe they get promoted and then they stop maintaining that tool and now you're used to forced to use it.

44:18And then nobody knows how to fix a bug. You have to go and read the code and you have to fix it yourselves. And that's not fun. No one enjoys that. And then he said, I would rather not have this internal tool in the first place because at least I can just solve the problem from scratch. But now that it is there, I need to use this internal tool. So I think it can get out of hand. It sounds like a ghoul. sometimes gets out of hand. And he was specifically saying his problem is not with the big tools like Borg that are really well-maintained, really well-written, but it's just everywhere. And because of this, as I understand, Google has so many migrations going on all the time, especially promotions come into play, which we're going to talk about shortly.

45:00But let me show you this image. When it comes to Google, there's two things to choose. there's the the main thing that's deprecated don't even think about it and the new thing that is under construction and this is by by Manu uh Cornett 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 EV and his engineers it's a it's about the perks, right? Like they're just so known for the perks, especially if you visit a friend at Google, I mean, it's a thing that stands out, right?

45:43I think the micro kitchens. Yeah. I mean, the Google offices in general are, I mean, I've been to other big tech offices as well. And like, I mean, the kind of playfulness and quirkiness is definitely not unique to Google, but it's also unique to Google. It's unique to Google. If you have the chance to go visit a Google office, especially one of the bigger ones, do it. It's a fun time. Yeah, people can bring in visitors. You get like free lunch or breakfast or whatever dinner probably as well. And I mean, the decor is unique. Like, you know, like I've been to many offices, right? Like obviously what worked at Uber, but went to Meta, Spotify, etc.

46:25Like, and they all have like cool decor at places. But Google is everywhere. like the thing that reminds me the most of google is the old facebook office back in menlo park back when it was like still very very like heavily invested there was like such cool cool things that was the only thing that came close and i'm pretty sure they kind of modeled it partially after google to wanting to hire you know like similar people but yeah like like really unique decor at every office like i think in amsterdam there's a van in the middle of the of the office which is a meeting room which apparently people don't use because it's too hot but it looks really cool and 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 just like often just like a a nice little like chill break room where you can socialize and hang out with people.

47:25Yeah, there's just so much personality to them. And in the Zurich office, they have one with a one of those like secret bookcase doors. So like, you'll be in this micro kitchen that looks like a library, basically with these huge books, bookcases, and one of them opens up to like a secret room in the back. When I was in the London office back in 2015, they had, you know, the London phone boxes. They had tons of those across the offices, where it's like, you know, you can go in and like do a quick call or like a one person meeting room. They had London buses, you know, just a London bus just in the office that you could go in and hang out in.

48:06They're really fun, very colorful. I mean, Google has always been colorful, given that they chose like the bold colors in the logo from early on and yeah you can just you can tell like those little caps with the propellers on the noogler hats which i did have but it broke and i have lost it somewhere and then like i think the per the list of perks is really long i mean it keeps changing per location but they'll be like you know from the usual kind of in the u.s the 4k one matching which is kind of a given but still generous from like all sorts of allowances that you can spend on like a lot of like typically you can expense a bunch of things the travel that that you can travel usually you don't need a budget i mean it's changing over time and again this is what i mean by location and then there used to be like more historic perks that i don't i don't think exist but there used to be like on-site massages where you can get like like uh like you know like like Like masseuse would come in and like you could just get it in the office, which was very famous in the in the like 2000s or so.

49:11So like the napping pods to some of these things. But these keep changing. But I think one thing that hasn't changed is, which is kind of like the biggest perk of all, is the compensation package, which is just like, wow. Like, you know, there's this tri-modal model of like the local companies that compete locally and companies that like try to pay the top of the local market and companies that pay the top of the regional market. That's the top tier. Google is a very top tier company, which means that they can pay anywhere from two to four times the compensation. So the total compensation that other similar companies will pay, let's say, for a senior software engineer.

49:46and like what this means in terms of numbers is in silicon valley uh california a senior software engineer could make around four five hundred thousand dollars per year in total compensation which means and this is where like it gets interesting there's a base salary there's a stock that vests per year that you can sell because it's liquid stock and then there's a cash bonus and then this will be something for a senior software engineer in the u.s like 220 000 in california base salary maybe 200 000 per year in stock and maybe 35 000 in target bonus and these last two they can change based on your performance so you could get more you could get less but for for london this whole total composition package which is not all salary so salary is only one part of it it will be for senior software engineer will be something like 200 to 250 ,000 pounds.

50:41In Munich, it will be somewhere to 190 to 220 ,000 euros. And in Zurich, it will be 300 to 330 ,000 euros, which is like a big jump. Again, differences in taxes and areas. And again, for every other location in India and in Sydney, et cetera, they will just typically pay more than anyone can offer. So typically the best paying opportunities, they will shoot a little bit above. And in the case that someone pays more and Google really wants you, they will sometimes shoot more and offer you more if they really want. In many ways, Google feels like this amazing, like you get everything, you get to work on the largest scale things with smart people, these amazing perks, and you've been paid a bunch.

51:29Because a company that does pay you pretty well, not this well, but they pay you pretty well, is Amazon. They give you a very respectable total compensation with pretty good stock and cash and all that. But then you get nothing. Like there's no perks. There's no nothing. They're like, you know, you want to go out for a team dinner, pay for yourself. Whereas at Google, like this is not even a question. Like, you know, like there will be team events and of course you're not going to pay for it. No, exactly. Like they take good care of their engineers and have done, again, like from day one, basically.

52:00And speaking of good care, so like one thing that really kind of struck me as really, really unique is on-call. Almost every company is like, let's be real, like engineers are paid really well at Google and similarly well at Amazon, Meta, Microsoft. At all the other companies, you are expected to, when you're on a team, you share the on-call on your team. Now, in the case of Google, on-call is not nearly as enforced or as stressful as at every other company. At every other company, you join like a six-person team, you probably have a rotation of every six weeks. It might be a bad rotation, it might be a good rotation.

52:38If it's a bad rotation, well, I mean, you know, your nights will be disrupted, sorry, until your team gets this stuff together. So Google has a few things. First of all, they have an SRE organization, which works really hard to make on-call less painful for teams. They build tooling that helps with this. They monitor the load of the teams. And they have this thing called toil SLOs, toil serviceable objectives, where they want to make sure that teams whose SLOs are breached, they stop production work and fix the underlying issue. So they basically provide time for teams to become healthy again and not get woken up all the time at night by systems that break, which happens a lot, actually, at some of these other places that, again, have high expectations similar to Google.

53:28And then another interesting thing that Google has is a thing called on-call tiers. So at most companies, even at big tech, every team just makes sure their systems are up. Google assigns tiers to their services. Tier one means that a page that comes, it needs to be acknowledged in five minutes, tier two in 30 minutes, and tier three is best ever. So you can imagine tier three is internal services, tier one is important services, but then they pay for the on-call accordingly. So they say if your team owns a tier one service and you're on call, you get 66 % of your normal salary. Like if you would have been on call for the whole month, which you're not going to be on call, you can either choose vacation or pay like 40 minutes of your time for every hour.

54:13So anyway, they do a bunch of compensation. They pay really well for being on call. and then they limit time spent on call at the same time you cannot go for on call for more than two weeks per quarter which is going to loft less than other companies so it just like it's like mind-blowing like google all does all these things they pay engineers like best in the industry or close to best in the industry they give all these perks and then they relieve them from on call so it's almost like it's it's amazing to be and then not just relieve but they actively help and mandate teams to make their systems better.

54:46So this is like paradise for an engineer. Like so far, like you would almost think that Google is paying us to like advertise them, but they're not. No, they make it easy. But I guess... Where's the catch? I mean, given what we've been talking about, though, in terms of like Google being this tech island, I guess like this is the positive side of it. Because like you can't actually fix everything yourself because everything is custom. So like you can't put the expectation that everyone can go and fix their Kubernetes pods or whatever. 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.

55:25And because they invested this much in it. Exactly. If you work at Google, you'll likely be... an SWE software engineer that's the big role that Google has but Google also has tons of like there are a lot of other types of roles and niche roles as well like sre is obviously one of the bigger niche ones run that they have but there's also quite a lot of other smaller ladders that and roles that they have depending on you know like some roles are more prevalent in some parts of the organization and with some product products or product areas so you'll have stuff like debrel they have ux engineers which are kind of like more front-end engineers working more with design implementation and that there's like a scale there that goes from more like front-end engineer to prototyper which is a separate career ladder they have research scientists they have within the sre org there's also like more specific type of roles and working with the infrastructure they have tons of other roles but the big one and the most on paper apparently all of these different ladders are supposed to have you know like same compensation same prestige same everything but it seems like in reality the SWE role SWE role is good kind of a bit like higher class essentially and part of that is because when you're in SW like because it's kind of the default go-to role that's the one where you have the most internal mobility you can work on like any team like it's much easier to like move somewhere else because that's the default that engineering managers will look for and hire for and speaking of managers they have engineering managers that That are, you know, EMs, they take care of teams.

57:26That's their primary focus is making sure that the team is healthy. They also have two roles. That is the tech lead role and then the tech lead management role. Tech lead manager. Which is unique to Google. So it's basically, you can think of them as like a spectrum where you have EMs on one side. Where it's, you know, the person, like, you know, they have direct reports. They take care of the team. They do all the EM things. And then on the other side, you have an IC individual contributor who's a tech lead. So tech leads are in charge of, you know, overall architecture, tech aspects of projects, of products.

58:07They'll make sure that, you know, like tech decisions get made. They have the top say. They get appointed by EMs. But then there's this sliding scale in between where you can have tech leads who also have direct reports. And here we talk about tech lead managers, which is this unique to Google. Yeah, but so my understanding of this role, because we introduced it at Uber and it was influenced by Google. I think we had a Google SVP come over and then it was introduced. My understanding of the idea of this role originally was, well, first let's talk about levels. And then we'll get to why this role is kind of important.

58:44So 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. L9, distinguished. And L10, partner. Fellow. Or fellow, yes. Google fellow. Google calls it fellow. I think Microsoft calls it partner. And around like at the senior software engineer and the staff engineer level at L6, another path starts, which is the manager path, which is where injury manager. There's sometimes an L5 injury manager that's more of an entry level, but I think they'll use it internally.

59:33And then L7 will be senior injury manager, which is the same as the senior staff. L8 is director, which is now principal engineer. So the same level, the same compensation, and it goes to L9 senior director, L10 VP, and then there's an L11 on the manager track for senior VP, which does not exist on the IC track. So at Google, we have this level from IC L3 to L10, and then manager from L6 to L11. And at every level, it starts to become harder and harder to go up the path. And around L6, people need to decide, Are they going to be on the IC ladder, try to make their way to L7, L8, and so on, or switch the manager ladder?

1:00:17But 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 are people with really long tenures, like, you know, 10 years, 20 years, even more. And they're very comfortable there. And so you have these individual contributors who are really good at their work. Like they're the tech lead de facto, and they could manage their team, that small team. Like typically these are small projects, but they don't really want to be on the manager ladder because they want to stay ICs and they don't really want to be promoted.

1:00:48So this tech lead manager role is kind of created for those people. And this is really important context because some other companies took over this role. So the Duber, for example, and what they found is people who went into this thought that they would be promoted to the next level. but it's really hard to be promoted when you're kind of expected to both be in. And as an engineer, you're not doing as much work as before or a little bit less. And as a manager, you're managing a team so people can get frustrated. But for Google, it worked, as I understand. So the tech lead managers are typically, they're not like looking to go to that next level.

1:01:17It'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, usually like more of like the research type things of like, hey, let's try to build something out and see if it works. where the team also wants to like move a bit more quickly and it might not be around forever so it doesn't necessarily make sense to both have an em and a tech lead because it's more kind of grassroots than that and so then you'll also have these people who will sometimes manage the whole team but like but it's like you know a couple people rather than you know a full established team that has like way more cadence and way more kind of em type work there yeah and i think there's a limit of like four or five maximum reports so and usually it's stable teams usually it's not ones and also if you're on a team of like four or five people there's gonna be not as many promotions and and so on and also a fun fact about a level so entry level software engineers start at l3 those are new grads and by the way the whole l thing as i understand it is to do there there There might be L1 and L2 within Google is just not for engineering because there are salary levels as well.

1:02:46PhDs, if you have a PhD, you start at L4 minimum. So there's one. Some other companies do the same thing, by the way, who hire PhD students. But that was an interesting thing for me to know. At Uber, when I was hiring interns, we hired a PhD and then HR told me that that person needs to be at the next level. I was like, OK, sure, like fine. But I guess it's one of the reasons that you see like, OK, having a PhD pays off. But again, we asked the same question from the PhDs as we did from the new grads. So they still needed to do algorithmic coding interviews. So there you go. Yeah, I do think the like L1 and L2 might be used in like very rare occasions for like kind of interns straight out of university or like they find someone who didn't actually go to university, but like very, very entry level.

1:03:34but like obviously the there's expectations also on like all the low l levels which is you know across the company or industry that if you're in a very low l like you're supposed to kind of progress to a higher level within like x years well yeah so this used to be the case but it's kind of changed so like google has this had this thing well they still have it called terminal level. Terminal level used to be L5 Senior. And I'm not sure if this was Google, but there used to be an expectation that, as you said, in certain years, you would get from L3 to L5. Later, Uber copied this. And at Uber, we had five years of expectation to go from L3 to L5.

1:04:18And in the case of Google, and then if it didn't happen, there will be questions asked and some pressure. And And eventually they might actually just fire the person saying, hey, like why did it not grow to what we expected? And once you read the terminal level, there's no pressure. And what has happened at Google is they've changed the terminal level to L4 because over time it's now to get promoted to L5, you need to like ship a kind of a project that shows that you're ready for senior. And the bigger the company is, sometimes there's not a 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 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 if people famously complain about but they actually did a big rehaul in i think 2022 where they moved to a new system called grad which stands for googler googler review and development if you ever worked at a big tech company it's a pretty similar performance you process people need to fill in as i understand their their self-reviews you get peer reviews managers look at it they give you feedback and there's a timeline for this so like this is google it runs once a year it starts in november and the bonus numbers will be managers look through it in december there's bonus meetings behind the scenes in january they get finalized and then they get paid out in march and so basically like for the input that you put in november and december you're gonna get like a final like output in february and you will get the bonuses is a margin 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.

1:06:44But if you end up with a, yeah, like it'll depend on your manager, it seems like. Yeah. And so Google used to be known and I think they still kind of are, they're trying to be pretty fair in how they do performance reviews and promotions. and we'll see that with promotions. I mean, the manager still has a big say, but they're trying to focus on outcomes, outputs, et cetera. They're doing more. There's a lot of training for managers going on, anti-bias training, all of these things. And the process is really well documented. And it is more heavyweight than most big tech companies and people take it seriously.

1:07:22Well, I mean, until a few years, and I'm sure after five, 10 years, people are just probably like, all right, here we go again, especially if you're not wanting to move up. And there are performance scores or feedback scores in terms of like, you know, if you're meeting or if you're exceeding, if you're above. But there is this interesting thing called the perf score resetting when you change teams. So this is, as I understand, this is kind of an open secret that if you change teams during a perf season, so basically like right after the perf season has, on your first perf season on your team, you will always get meets, meets expectations, no matter if you're, how much you're overdoing it.

1:08:12I mean, if you're doing terrible work, you might get below, but you're typically not going to do terrible work. But you will not get exceeds no matter how hard you work. so this is leading to like some pretty strategic considerations on when to change teams because getting an exceeds rating means you're going to get higher bonus but you know that when you're changing teams it's going to be meets you're going to get your target bonus no matter what it was actually with perf that that they used to use so yeah meets expectations exceeds expectations and then like very much exceeds expectations basically but actually with grad they've updated the kind of terminology so now it may they map to impact instead so you have not enough impact moderate impact significant impact which are like the that's the high end of like meets expectations exceeds expectations and then there's also outstanding impact which like maybe eight percent of people get is what i heard so like you're doing amazing essentially uh there's also transformational impact which is like the top top which is yeah you're gonna ship a really big deal project in order to get transformational impact yeah and usually behind the scenes these will be tied to budgets meaning that at the director level of like let's say a group of like 100 l5s only three would have, I'm just saying something, it might be five, but a certain number can get transformational impact.

1:09:47And so on the calibration meeting, where all the managers get together and they all, you know, submit their ratings, there will be calibration where it needs to not fit the curve, but it needs to fit the buckets. So there oftentimes needs to be certain number on the lowest buckets and maximum, minimum certain number in the lowest buckets of the, you know the the ones who do not meet the the impact and only a certain number in the in the top buckets and it depends on how much these are enforced it depends on the performance season it depends on the organization but there's always going to be a distribution a force because what most companies learn including google is if they don't force it a lot of managers will just like shy away from having the hard conversations or reward either rewarding their their their best performers as they should be or being a bit more critical with the people who are not pulling their weight as much and this is irrespective of this happens at every large company after a while and even when it doesn't for a few years it can start happening after a few years like we've seen a lot of companies have like absolutely relaxed performance management in 2021-2022 like the job market was really hot they there was a time where they gave everyone exceeds i think Google did that once as well to fight attrition.

1:11:04And now it's back to the usual of like, there is this bucketing. And we have a longer deep dive on how calibrations work behind the scenes from the manager's point of view, which is actually really interesting slash eye opening. But as an engineer, not much you can do beyond, you know, document your impact, have a good relationship with your manager and hope that that manager stands up for the people on their team. Yeah. And I guess, I mean, there's some aspects of like you know the type of you know work that you do and kind of extra extracurricular activities if you will that will feed into and like look good on these performance reviews and google does have a lot of opportunities to do that kind of stuff so 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.

1:12:01So again, because Google is so unique, there has to be a lot of onboarding and kind of knowledge spreading internally to teach people how to work at Google, essentially. So that opens up for a lot of opportunities for people to help up with that kind of stuff. If you like working with that kind of stuff, like kind of tech writing and like tech learning, Google has a lot of opportunities for that. Yeah, probably a lot more than most of their companies. It sounds like they actually appreciate it as well. So, I mean, obviously you need to do good work. I don't write sloppy code and like it's full of bugs all the time and then do all the extra things.

1:12:42But when you want to show that you're ready, especially, I guess this is true for especially the levels like we're talking L3, L4, L5, above that. I mean, it's kind of 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, hmm, or you're not helping other things. So it's not going to help you from there because it's kind of baseline from there on. Yeah, there's actually, that reminds me that one of the things that is built into the critique system and their code review process is something called readability, which is essentially, again, it's a monorepo.

1:13:19So like anyone can see and review anyone's code, but the code review process is built up. So like every change list, every CL needs to get reviewed by three different. It can be the same person, but like three different roles. One of them is 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 they have this way of earning readability in a language that, you know, has to like, there's a whole process for it.

1:14:09Yeah, we talked about it with Irina on the podcast. She was ex-Google. So yeah, you have a process. It's pretty straightforward. You need to like shadow, I think, be signed off, that kind of stuff. Yeah, exactly. And like do a certain 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 people in that org in order to like. That's a good trick to know about. Yeah, you can just focus on readability, just look at open CLs across the...

1:14:48It's so unique to Google, isn't it? I don't know any other company that does this. At Uber and other large companies, you do mandate code reviews of a code owner, but nothing to do with readability. Yeah, and I think it could be that that's probably an artifact of the monorepo again as well. The monorepo doesn't necessarily, like, they still do a lot of, like, microservice architecture for, like, within the monorepo. Like, it's not necessarily, like, either it's monolithic or it's microservices. Even if they do have, you know, microservices and, like, the tech in the teams or different products will be, you know, separate, maybe have different architecture, maybe, like, software patterns-ish, like, compared across.

1:15:35but like the again like the tech is the same the readability is the same so you could almost think of it i think as like several different companies that just happen to have the exact same engineering culture rather than you know trying to compare this type of stuff with how they do stuff at maybe meta or amazon it's more one company one tech stack so it's like then you're kind of more stuck in your silo, so to say, versus here where, you know, someone with reliability can help someone working on a completely different thing. It's an interesting approach. So outside of performance reviews, the other one is promotions.

1:16:20And 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.

1:16:55And so this group who's kind of, you know, like kind of know your work. They all like decide collectively in the end, or they get feedback why you're ready, why you're not ready. And the good thing about this is that they all know the context of your work, roughly. The bad thing is it can be pretty biased or it might be pretty ignorant. Like there might be some managers who would veto you because like, well, I didn't hear about this person or I had this one bad incident. One of my teammates said, I don't know how they got into a fight with you, et cetera. So there can be some biases there. And what Google has done for a long time is they said, all right, let's just make this whole process unbiased.

1:17:30Let's have a promotion committee where no one knows you. Like, it's not your managers, but it's like this group of like senior or staff plus engineers and other engineering managers at a different part of the org. And they just get a written packet, a little bit like their hiring committee that we're going to talk about. They decide your promotion based on that. And what this means, they don't know anything about you. They don't know who you are. I mean, they will understand the context, but they haven't worked with you. They have no bias for or against you. And so the decision should be a lot more like objective, right?

1:17:59So they will decide on your impact. They will look at the framework that's there and the impact. Because again, with the manager group, there's the other risk that if you have a really strong manager, it's really influential, they're just going to push everyone through. And then you'll have some teams where people are promoted who are clearly not ready or not doing as great work, but they have a strong manager or a good manager from their perspective. There is a very interesting kind of downside of this promotions committee. There's a famous article called Why I Quit Google to Work for Myself by Michael Lynch, who was an L4 software engineer at Google for four years.

1:18:37And he was stuck on that level for four straight years, trying to get promoted four years, one after the other. And he wrote this blog post and he failed every single time. So he started to understand how the system works. And by the time he understood that it was a bit too late. First promotion, he, you know, submitted his, he was doing a bunch of maintenance work. And then the promotion committee said that he had not proved that he could handle technical complexity and they didn't see the impact. Again, Google is big on impact. So they said to be promoted to L5 senior, he needs to have an impact on Google.

1:19:14Then he went back and then he was like okay i need to have a project that can have that impact so he now looked for a project to get to get to promotion and he got that project but then the project got cancelled and then the next year i think he moved teams or he had to move teams because his team got cancelled and so so he had this like series of bad lucks where and then and then and i think year four uh he wrote in this article i'm quoting him my quality bar of for code dropped from will we be able to main this this thing for the next five years to can this last until I'm promoted. I didn't file or fix any bugs unless they risked my project's launch.

1:19:52I wriggled out of all responsibilities for maintenance work. I stopped volunteering for campus recruiting events. I went from conducting one or two interviews per week to zero because he just really wanted to get that freaking promotion. And in the end, he quit Google. But this whole story showed how it's super easy to fall into Google into the promotion trap, which is I need this project to get me promoted. And that's it. And he actually explained. And in the end, I think he said, like, what am I doing here? Like, why am I doing this? And he's a smart guy. He built a really good business afterwards.

1:20:24But it felt to me he just got unlucky of how his teams changed. But also, this is where we should talk a little bit about promotion-driven development. That is very real inside Google because all the incentives are there for it. And, you know, there's this joke that goes around of why Google has so many chat products. products. I think, you know, they had Google, like they had Google Wave, GChat, and they keep changing the names and also the product, also Google's payments promotion. It was Google Wallet, then GPay, then Google Pay, then it's now Google Wallet again. But you see sometimes a lot of things where Google has a product, like with their chat product, which is still not, they don't have a Slack competitor.

1:21:08Like they have Google Chat or maybe called Google Workspace. I'm never sure. They have certain products that are pretty niche and they're launching and they get a bunch of attention and press from Google. And they're often on just one platform. For example, they had a chat product just for Android. And if you look closer, the incentives are that Google really incentivizes you can get promoted for having a successful launch for showing traction. A lot of projects at Google, you know, like people start a new project, they get traction, they get promoted. And there's this thing where if you move teams, your performance scores are reset.

1:21:41You will definitely meet a meet. so if you hit a bit of an obstacle the launch goes up but now it kind of flat lines i mean you can stay on that team and get a meets review or you could move to a new team and get a meets review anyway so often teams will move to a new team and either start a new project or 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 the gist of it, my understanding.

1:22:13And, you know, this goes back to Google has this thing called Killed by Google, a website that collects these like 300-ish Google products that have been launched, but they have been killed. Yeah. I mean, technically not run by Google, but... No, it's not run by Google. It's just external. That one was not a Google project, but... That would be funny if someone internal at Google was like, here's all the things we're bad at. No, but it's interesting because on one end, Google is very heavily criticized because they are the biggest tech company which seemingly wastefully launches and then kills projects publicly.

1:22:44But at the same point, I still wonder if this is kind of part of how Google operates where they do want to see people launching stuff. And again, because look at it, I guess we can make fun of how Google discontinues Stadia, a gaming console or Google Reader. but show me another tech company that has as capable of LLMs as Google has, big tech, their own models, or self-driving cars in San Francisco. And maybe you cannot do one thing without the other. I don't know. The way I think of it is that Google has had a really good culture of just creativity and innovation and just allowing people to try things out and see what happens.

1:23:31like famously the 20 % time 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 it would be nice to have something like this and you build it for yourself and because it's Google it's automatically available for everyone and then all of a sudden you have built a tool that people use and then you move team and now no one's maintaining it and so I think part of it is that but Google allows you to be creative and innovative and try new things and just like yeah launch see what happens but I think another part of it as well is I think of Google as being a very kind of engineering first and engineering driven organization.

1:24:34If you compare that to, say, Apple, which is much more kind of like the design and user experience driven. And if you have it versus, say, a meta or something like that, they're much more like product driven. It's like if you're a product person, that's how you drive. I think at Google it seems to just be kind of just engineering first and maybe one of the main ones that do that where it's it's like it's the engineers or like you have much more ability to decide what to work on and like choose the path for yourself if you're an engineer like it's much easier to get product traction and essentially it's because if you're an engineer you can also build it.

1:25:20Whereas if you're a product person at Google, you'd have to convince engineers and do this whole thing of getting headcounts and stuff. Whereas if you're an engineer, you can just either do it yourself because you have so much available to you, again, through code search and the MonoRepo. You don't have to start from scratch every time. And then one more interesting thing of how Google works, and I don't know if this is like engineering driven but maybe it's connected their their their design docs culture is just really really kind of famous to the point of apparently whenever you start a project you you're expected to write a design doc which is a google doc which has like certain sections and you know these are kind of like loosely handled but it's things like context and scope goals non-goals and overview you might have your architecture diagrams how it impacts other systems the structure of your changes, maybe rollout plans, life cycle, and many alternatives considered.

1:26:21Some other companies have actually started to use similar approaches or maybe just naturally spread. It's often called RFC, request for comment. But at Google, so every project will be rejected, even smaller ones, if they don't have a design doc. And it's expected that you write this and you send it around, you gather comments, and then you start coding, which is really interesting because you would think that as an engineering different driven culture one thing that us engineers love to do is code and what we don't like to do is write docs and yet google settled on again it is very engineering driven uh 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 and probably the biggest like engineering culture of this quality yeah i mean i think uh i mean it might be something like you know they introduced the 20 time or like they just had a maybe even before that was formalized like there was a culture of people just trying things out and maybe realizing that like oh we're like redoing the same things or building something that like oh had you talked with any other people you had realized that like that was either like not needed or not a good idea or like it has a use case of one like you're building something for yourself so that could be a part of it but I also think in terms of just like the google culture itself and googliness which we haven't touched on but googliness is basically this idea of like people who fit at google should be googly and it's kind of a vibe thing and part of being googly is that like it's it's less of this whole like a bit less of the rock star mentality that you know you're the rock star engineer who just like goes off and does his own thing it's very much more like collaborative teamwork team spirit enable everyone to do great things and so it probably like i would assume it comes from that as well like part of being able to keep the Googliness is to just be very open.

1:28:32And there's actually, like we've mentioned the SRE book. There's also an SVE book, the Software Engineering at Google. Yeah, I have it here on my desk, Software Engineering at Google. It's also, it's available for free online. Google made it available. Like it's officially free. It's not like one of these pirated books, but yeah, it's pretty big. Yeah, and 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 Piper and the Monorepo and the critique and all that stuff. But it also has, you know, a big section of like, you know, why are we doing this in the first place?

1:29:09And there are some beliefs that, you know, software engineering is a team effort. And 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. They famously run an experiment where they removed all managers and they figured out what's going to happen. They didn't know. They thought the teams would maybe work better without managers, just engineers, and it 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.

1:29:47And like they've done a lot of research and they have published a lot of these things. But, you know, at a lot of companies, I think as a developer, you get really frustrated for because it's oftentimes the business, you know, CEO or someone pushing developers like do this or that. And they're asking, why is it taking so slow? Why are you guys, I don't know, 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 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 non-technical ceo would not understand like why would i need to do this like we just we have our engineers like they can i don't know use open source tools or whatever and even when you use the open source tools or for your ci cd system you still need someone to maintain it at the google like it's probably the one of the best places where yeah everyone gets it because they've been doing this but the people up there are software engineers the founders are are i mean they were phd students but they are software engineers even though the founders are are are no longer uh there but everyone all the way to the top understands and breeds software and i think they understand that the software is a series of trade-offs it is it's not just code so even when it comes to like ai uh they're they're not going to be like falling for what everyone else is saying that i don't know like 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.

1:31:42And 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 uh 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 But I want to touch on this.

1:32:26It's not really software engineering, but it kind of impacts OKRs, objective key results. Now, if you're a software engineer, you probably like and you worked at a midsize or larger company, this probably came up like what are your OKRs? What are your team's OKRs, the objectives, the key results and the goals? And apparently Google made this super popular, this framework, right? Yeah, exactly. So technically they didn't invent it. They were actually introduced in the 70s at Intel. which is so long ago but there's this guy john dore 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 so yeah like objectives and key results.

1:33:25Objectives is like, you know, a kind of more high level goal of like, this is what we want to build. And then the key results are specific, measurable things that you can measure in order to know that you're moving towards the goal. Some examples of when they introduced OKRs in the beginning, back in 99, like their first objective was build a great search engine. And then they came up with their key results. Serve at least 10 million queries every day. Achieve sub 0.5 second response time for searches. Improve accuracy of search results based on user feedback. And the last one, hire a world-cross engineering team.

1:34:09And 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'm gonna 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 will publish in 2018 and from there on it's really blown up and i think everyone's like using okrs because it like there's this narrative that okrs make google successful but i'm kind of thinking like is this a little bit saying that i i don't know like using jira made whatever company successful spacex successful i'm not sure they've used jira but like whatever ticket is custom they use that that make them successful because i'm like the smell that i have is i have a sense google would have been successful whatever they use because you know like it started with page rank they did something that everyone wanted and i i wonder if if okrs is is something that i mean it's it's probably it works but it could have been anything else because whenever i used okrs at least and you know we we tried to use Like having a clear goal and a team that was focused on building something was always way more important than having whatever OKRs.

1:35:40Because 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 2010 or 2012, the organizations were all focused on their goals and they only cared about their metrics. And it was terrible. We couldn't do stuff that Google did. For example, like my team, we couldn't agree to add our codecs into the new Internet Explorer called Edge while Google Chrome had it bundled because the two orgs had different goals and they cared about download size and not what we cared about.

1:36:16So anyway, it's good to know that Google uses them, but I'm still kind of like, I wonder if that really makes all that much of a difference for them. I'm sure it helps, but I think it's a bit overblown. Yeah, I mean, it might have helped in the early days, 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, end of the day, OKRs is a tool, right? This is a way of framing and communicating priorities and what needs to happen with each other. It's like if you use it in a good way, then you figure out all of like, oh, actually, we would need to do something else or we need to do something additionally.

1:37:02So I think if you use it as a tool, like you can use tools in very bad ways and you can use tools to great success. I'm sure Google Apps had plenty of OKRs that are not even remotely close to what they did. you know, in these early years. But like, yeah, maybe it helped. Like, since they've been around since 99, like, probably they know, like, you know, it's helpful. But yeah, I do think that the tendency of like, oh, they use this, so therefore we should use it and then we'll be Google is, yeah, that's not how it works. Speaking of OKRs as a tool for communication, communication in general at Google is is and at least has been very open and very transparent so historically like this has changed a little bit now we'll we'll get into this but like culture is shifting across the industry including Google in late years but historically it's been incredibly open and transparent again like maybe it's like part of it's being the the the monorepo and the fact that everyone has access to everything anyways.

1:38:15But, you know, since pretty early days, Google used to have the, or still has them, these weekly company-wide town hall, all hands meeting, check-in type thing. It's called TGIF. So thank Google, it's Friday. That was the original. And then, like, with the engineering team being a company, really, because this is for the company, not just engineers. It is global. So it's actually, it's on Fridays in one time zone, but not in the other. I don't remember. But so it's more like TGIT now. So think Google, it's Thursday. Yeah. But basically, like it used to be more like Sergey and Larry on stage talking about stuff, doing open Q &As.

1:39:05You'd have different teams come in and like present what they're working on or what they've built. And I think it's one of those kind of cultural cornerstones, it seems, where like I remember when I was interning, you know, it was on Fridays and like there's the all hands itself, that's TGIT or TGIF. But then, you know, there would be an event at the office where, you know, there would be free food and drinks and sometimes some like event 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 but 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.

1:40:02Exactly. It's a fun event, but it's tied to one of like the kind of cornerstones of communication across the company. And then that, you know, it kind of trickles down in a way because like Google organization is very fragmented. Like, again, because Google is basically many different companies in one. so like you'll have they're called product areas like the big sort of completely separate companies so youtube is one product area cloud is one product area search is one product area advertisement is one product area that are like the big ones there's another one that i can't think of right now but you'll have those and then internally they you know you'll have you know different departments and different teams organized in some way.

1:40:52But it's like, it depends. There's reorgs very, very frequently. So you mentioned like teams can just evaporate and cease existing, which is because of reorgs, because of, you know, projects being sunset, moving around. So like there's probably never been in like an org chart that's lasted more than a quarter inside of Google. But then like within all of these different organizational kind of factions you'll have you know kind of all hands meetings and town hall meetings yeah so you're saying it kind of like goes down right so like there's a company one every week but then you're gonna have your i don't know your wider org and your your like you know like the bigger org and then your your team lead you'll have a weekly team lead for sure so like every week you'll have the tgif or they'll just call it as in your team meeting and then every other week or every fourth week you would have some of the other orgs and they can just stack up exactly and then there's the like functional orgs as well that comes into it which i don't know if it's as much of a thing with engineers but like you know they have the srv org and the design org okay so a bit of a culture shock if you come from like a 10 startup exactly and like the dev rel org and then like each of those like discipline based groups they'll have different like there are different ones in different PAs and like so it's it's so much like it very very much depends on where you are in what org in what discipline you're trying to say this is a downside of transparency right because it's cheering me out so at uber we had something similar it was a little bit ridiculous and like on the kind of the org wide all hands which it didn't really concern most people people were just coding on their lap because they were expected to show up and on the meeting room people will be coding on their laptops.

1:42:42Like, I don't want to be here, but I need to show up because the SVP is here and whatever. But like, what's the alternative, right? Because if you're saying we are transparent and we want everyone to know, you know, like we want everyone in Google to know what the CEO thinks, like with every engineer to know what the CTO thinks, you want to know what your director thinks and da, da, da, da, da, da, da. And just like what's going on, what people are working on. Well, then there's a lot of meetings or you can be what Apple does or like a more secretive thing where like look you're in your team you are not allowed to talk with anyone unless you have special clearance and you don't unless you're you know so you have your team meeting every week that's it don't worry about it oh why are they like you know drilling off the wall and like this assembly next to you that's not your problem like but i feel those are the two extremes and like there's differences 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 well know it's just like there's all these oh you've not been in that meeting they actually told us there like oh no sorry i was trying to get some work done yeah and and just like it can probably be pretty overwhelming yeah um but i mean they are good also because again maybe because google is so global i think they are pretty good at you know recording like i know i've heard especially since the working from home like pandemic situation like after that they have even better kind of processes in place for this kind of stuff so like cross cross-Atlantic meetings for instance like they're these days apparently like they do some all-hands and stuff twice so they'll do one for a time zone that makes sense for Europe one that makes sense for U.S.

1:44:26because that also used to be a thing where like you can work on something that's like primarily based in the US in Mountain View, but you can be in and based wherever you want. But you will have to wake up in the middle of the night to go to meetings if you want to know what's going on. So let's talk about some things. There's so many things, but some things that make Google special. And one of the things that came to my mind that I didn't really hear before, a term called re-Googlers. And, you know, Google has this like fun terms for like new Googlers, Noogler, ex-Googler, ex-Googler. Re-Googlers is apparently a program where Google Talent Acquisition reaches out to former Googlers saying, hey, you left Google a few years ago, want to rejoin?

1:45:11And apparently it's really successful. A bunch of people come back. That's the part that is not really common at a lot of companies. And it's a program, it's working, people like it. And yeah, people are rejoining as well. Oh, interesting. I didn't know there was a program for it. I know plenty of people who've left and rejoined, but... I heard that there's an outreach program. Uber started to do something similar, but I think it was just in one of the offices. But someone told me that it seems to be happening. And I don't know if the program is official, but yeah, the term re-Googler, it's a fun term.

1:45:45Yeah, I mean, I love all the names for the different Googlers. I have a few, yeah, it's like Nooglers. When you're a new Googler, you get the Noogler hats, the famous ones like you know the little caps with a little propeller on it i actually i have this uh i got this little android friend when i was interning there uh that's a collectible now today yeah exactly it did have it so this is a little nuclear hat it used to have the propeller but i broke it wow and like it has a little google backpack you can even open it wow it's just so cool but i think this i mean this is part of like the googliness of it all you know like we've we've talked a bit about the the playfulness and how it's it's just part of the culture it's uh like the offices things like this but but 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 all 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 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.

1:48:15I 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 a ways of sending like an hour of massage to someone they think did a great job. And then there's the peer bonuses that that are more proper, like monetary. Not huge bonuses, but a bit. And those really incentivize doing things for others, recognizing things for others. So there's probably a few hundred dollars or something like that. I think so. Yeah, I can look it up, but something like that. Yeah, but I don't think many companies have this.

1:49:01Some do have that you can send thanks and they're public and everyone's like, oh, that's nice. But usually there's not a monetary something. attached to it. That sounds pretty unique. Yeah. And then the last Googly thing, at least on the list, is just the right thing, which I think is maybe ambiguous a bit. I mean, Google used to have the motto, don't be evil, which they kind of phased out. And I think it was like 2018, but that was one of the tenets from very early on to just, I think it goes 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 could be lost along the way but also it could be like when you're big enough size like it goes back to like when you start to be doing government contracts and then the government does something that is just either ethically wrong or a group of people disagree with it or a large group of people disagree with it, do you stop working with the government?

1:50:09And if so, you're now giving up that space for your competitors. And then, you know, it now goes into the territory of like, what about other governments when you're a global company? If your software is used in every single country, what if one country attacks the other? Are you now also the evil country or if two countries attack each other, you know, like both sides will think. So all I'm saying is there could be a point where by being involved, you can be a part of it. So that might also be one part, because that's also one thing that Google is being attacked on for. For example, not just Google, but all companies of, you know, like providing software for, I think maybe it's the U.S.

1:50:50defense ministry because they're now using it for something. And all the big companies now provide software there. And, you know, the alternative is like pull out and give up on the market. And also, I guess this goes back to like do the right thing. It's in this book. I just read it. But the right thing for who, right? Because as a software engineer, what is doing the right thing for service mean? Does it mean that we will have a great on-call experience and we will invest a lot of time maintaining the system? Or do we do the right thing by shipping features quickly? So are the business stays ahead?

1:51:24or do we do the right thing that when customers complain, the tickets come to developers immediately and we wake up in the middle of the night? Like the right thing for who, right? So there's a little bit of a boogie there. Yeah. But to be fair, like it's in the book here, actually. Yeah, it's great that they printed it in the book. Do the right thing says, has a strong sense of ethics about everything they do, willing to make difficult or inconvenient decisions to protect the integrity of the team and the product. It's interesting. So customer is not mentioned here, nor is user. And there's no customer anywhere.

1:52:00They do say user, but there's no customer. That's one thing I noticed with Google. They never talk about customers. And about 70, they only say users. And I think that's an interesting thing because about 70 % of Google's revenue comes from ads. So they need users, but not to say customers. And this is one frustration, by the way, that I personally have with Google. You can never get customer support. You're paying for the product, but you cannot get through to a person. And this is very different to Amazon, where Amazon does give you first-class customer support, but they do burn engineers into pushing to make sure that the systems work, they're repaired.

1:52:41Interesting trade-offs. It makes sense in a way where, like, obviously Google Cloud Platform, I mean, I guess the earliest like kind of precursor to that, I think, is when they opened up App Engine back in 2008. Google App Engine. Yep. That was an early user of it. Yeah, because like, again, like the Google infrastructure was primarily built for Google. It was never meant to be built for customers. And then, you know, they had these, you know, they externalized parts of this. And that, you know, grew to become the Google Cloud platform. They obviously made design decisions and choices, I'm assuming, while externalizing some of these things, like building Basel coming from Blaze, Kubernetes from Borg.

1:53:34You know, they must have built in, you know, parts of it. That's like, OK, so how do we make this work for other companies, other use cases? But yeah, it's an interesting difference between GCP and other cloud providers, like where it started from, so to say. Yeah, yeah, that is really new to Google. So I think Google Cloud in general, it did start from App Engine, which so unlike a lot of Google services, it was not served from internally and externalized, but it was built as an app. I was an early user of App Engine. App Engine was so darn cheap. Everyone used it because of it. It was a lot cheaper than using AWS and running your own AC2 instance, and you didn't have to worry about scaling.

1:54:19It auto-scaled. And then what happened in 2010 or 2009, because I was a user of it, I built a side project on it that had a few hundred thousand users and I was paying pennies for it. And there was like some big reorg inside Google and they shut down a lot of projects. I assumed that they were not profitable. And overnight, Google App Engine changed their billing to be like 5x as expensive. And suddenly before they said like, all right, like you can deploy your code and we will auto scale. You don't need to worry about it. And now they had to worry us about like index rights. and like they exposed us to our infrastructure and everything became a lot more expensive.

1:54:57People revolted and they gave us 30 days of notice, which was like really, really short. So it felt to me that it was a do or die moment in the sense that either that org proves that it can be profitable or generate revenue or they're shut down. But it was my first time with Google where I felt really burnt. I used to think of Google as like this amazing place that will not trick their users. And I felt just tricked and I was really like miffed. And I wrote a really nasty letter on the customer support form because, of course, the only support form was a Google groups or Google forum or whatever that was.

1:55:32That's where the official engineering team worked with us. You can see that Google is terrible dealing with paying customers. It's almost like they don't care. It's almost like they despised them a little bit. Not always, but in a weird way. Most companies will put them at the top, and Google just treats them the same as free users. or at least that was my sense. But yes, that's how Google Cloud started. And there's this really, really weird thing or unique thing with Google where everything that Google builds, every major product or that they invest in massively is number one. YouTube, Gmail, Google Maps, you could argue, but it's probably the most used map solution.

1:56:12Android, Chrome. And then you have Google Cloud, which is the number three cloud service provider across a bunch of different measurements. They're way behind AWS. They're behind Azure. And they're not really seeming to catch up. They seem to be stuck in this perpetual third place. The strange thing about it to me is, I would assume if it's Google, it's very easy how to make it. You know, number one is like Google started using their own cloud service. And I mean, that gives the confidence of everyone. Well, if Google is built on GCP, you know, like this is what, like you can trust it. And AWS did this over a long, long set of time.

1:56:48they have moved over almost everything. Amazon.com runs on AWS, as I understand. It took a long time, but now it all runs on it. When I was at Microsoft, they just bought Skype and I was in the Skype org. They forced us to move over to Azure and we hated it. It was not ready. There's a lot of things, but we had to move it. And a good part of Microsoft runs on Azure. Not all of it, like Bing, I understand has their own infra, but Google doesn't really run on GCP or maybe some small parts of it do. Yeah, so they've had a few, from my understanding, my research, they have a few, like they've made attempts to move and migrate some stuff over to GCP and there are things that run on GCP.

1:57:35I don't know what, but some things do. The way that 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 yeah and that is not most use cases it is very specific and they've made a lot of engineering decisions that you know like with again 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 it 'a score!

1:58:37But 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 think the question is if they want to win. But I got this, because I have been asking a few Googlers or GCP people about this, because I still remember inside Microsoft, people were not having music to Azure, and it was just done. By the way, the guy who did it was Satya, Satya Nadella. He was pushing people to do it. He was not the CEO back then, but he is now. But Microsoft clearly could be number two with Azure because internally they're pushing it just as much as externally.

1:59:13So they're going to keep improving it. But someone at Google, an engineer, told us how, like I have heard a lot of Googlers say that their internal infra is superior. And this engineer told us that superior is an interesting term here. It's not like feature-to-feature Google internal is better than GCP, but the level of vertical integration across the entire development process from like, you know, like doing the plan or doing your docs, code reviews, all that is unmatched because every part of the workflow has been thought of and it's got these like nice hooks. And as a developer, it just works so much better.

1:59:51So 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 important that they grow their business as opposed to just growing the cloud the cloud or configure it out and being and maybe being number three in one of the biggest businesses in the world in the case of cloud is acceptable just the same way as google is number two on on mobile in a lot of regions with Android.

2:00:40They're not number one. They're number one in some part of the world. They're number two in some other parts of the world. So you're right. Maybe Google is way bigger than this. And maybe this is not a, they don't need to win at everything, right? Like only in the important search with self-driving, they're seeming to be investing heavily. LLMs, maybe those are the things that they really want to win in. I mean, speaking of trade-offs in general, I think, like, if you really think about it, and if Google were to move everything to GCP, like, if that also, I guess, like, because they built out, you know, their build system, their monorepo, all their developer tooling on top of the same infrastructure, it's different.

2:01:26It just might not work as much, especially when you have like all the permission systems that are like built, baked in internally. Who knows? I think it's tradeoffs, right? Yeah. It's probably a good reminder that like you don't need to like, there's no one solution. And also history of a company is, I think, pretty relevant to understand why they are where they are right now. Yeah, exactly. That's one of the big takeaways for me doing this research. maybe I mentioned it earlier as well like I think one of the reasons why they can be so open about the stuff they're open about is that it's like it just like it happened this way because it was so early and you know they made some fairly early acquisitions and strategic pivots into you know like we're not just building one thing we're building completely different things like the org is set up based on that the workflow developer tooling like everything is just so interconnected with google which is why i think it's so it's been so interesting to uh learn about it and and 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 this of some of the other ai startups or maybe you know nvidia's growth this is speeding up, although they're more in the hardware business or for social media, Snap or even Meta.

2:02:53Well, they were earlier a little bit, but let's say for OpenAI, they are now, you know, they're building other things custom. We're not talking about they're using cloud. Like they're not going to, I mean, OpenAI seems like they're investing in their own data center, but it's going to be whatever everyone else is doing. We're now talking about the LLM stack, for example, that might be custom. So like they're just taking whatever is there. They're not reinventing that part because why would you? Snap is a social media company. 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.

2:03:33And even Uber has moved over to a mix of Oracle and Google Cloud from their own data centers. So it probably held Google that they were early in the internet, right? Like there were just no good search engines back then. they were the ones who built this one thing i have to mention internal mobility there's there's just so much internal mobility inside google and there for large companies there is usually some level of internal mobility but as i understand inside google is just really easy to move teams if you you're not on 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 if they've been there for like 10 plus years if they've not worked on several teams and and something and sometimes changing teams like a few years in a row like almost like and you know knowing how big google is like these are like thousands of teams tens of thousands of teams actually and yeah you can just go between them Obviously, for smaller offices, it's a bit harder because there's not as many around you.

2:04:43But still. Yeah, I think there's a slight thing. So just to mention during the pandemic, obviously, Google started working from home. Just as the rest of us. And my understanding is, especially then, the internal mobility kind of like from and maybe a bit after that kind of spiked a bit as well. Again, like most of us, you realize that it's possible to do this without being in offices. And so I know of folks who were able to start working remotely for teams in new locations. Oh, so they're able to do internal mobility. Previously, you need to be in the same location. Now they could remotely join that team for a while, at least.

2:05:32Exactly. Yeah, but I'm pretty sure that's going to go back to where it was before, slowly but surely. Yeah, because it has done that. I mean, Google now is, I think, almost everyone's on a hybrid schedule where they expect you to be in the office at least two, three, four times a week. Probably depends on where you are. And I know there are some exceptions. And probably your manager, yeah. Yeah, and how important you are to Google, probably. Speaking of exceptions, there is this concept of singleton. Yeah, so a singleton is basically a person who is on a team, but like it's the single person from that team working in the new location, essentially.

2:06:15So if there's a team, say Waymo, for instance, but they have like this one person who really wanted to move somewhere else or refuses to work there unless they can work from that particular location. it's like okay then you're a singleton so you might still work at a nearby google office but you'll be the only person like from that team working in that office yeah and i guess it only makes sense these are senior people people with like key skills maybe if there was a reorg they were left there like you need to be in demand typically for your knowledge or at your expertise it's not super common and uh it's definitely an exception rather than a rule but uh like it does One more thing that is very unique about Google is the nonstop rewrite.

2:07:03Like everything is being, not everything, almost everything is being written every few years. And this does happen to some extent at most large companies, but with a lot slower pace. I don't know if it's the engineering enablement, the fact that there's a lot of new technologies invented by Google as well, right? Like they created the Goal programming language, for example, GRPC protocol. So many open source contributions or that the business is changing that frequently. But because of this, I mean, this is a good and a bad thing. Like if you work at Google, you're going to be really good at rewrites and migrations because with a rewrite there, it's usually migration as well and deprecation.

2:07:42And 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's that thing. When you build a new thing, how are you going to get the customers over there? Yeah, but I think it's like on two sides there. Because they have the monorepo, they have direct access. So like they can actually make, they do have a tool called ROSI, which is a tool for doing like large scale 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.

2:08:18And then there's a data migration, which is going to be the tougher one and the more error prone one and the one that you want to get right. And by the way, that's a really useful skill to learn because like usually most engineers don't need to do migrations all the time. But when you do, you better know how to do it properly and with the right steps and with the right safety and planning. But once you've done it a few times and you burnt yourself, you'll be unstoppable. Yeah, either Google can be the worst place for it because you do it all the time or it's the best pace because they do it all the time.

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

2:09:18Another 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 if you've been at another company and done internal migrations or move teams, also worth keeping in mind that moving teams at Google might be a much bigger shift. But then again, it's probably a shift in like the tech stack is obviously the same like you it's not moving companies in the way where you have to learn a completely new tech stack and like how they use their tools and all the different quirks of like yeah you've done kubernetes before but like how do they do kubernetes at this new place rather the the thing that you're gonna run into is probably more on the how do you prioritize what are the communication like all the like softer things might be very different moving from team to team.

2:10:15And I guess one thing about Google that is kind of special, although a lot of other companies do it these days, but just how much they contributed to open source and the industry, the broader industry, like some of the biggest project that they have built or open 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, I think it's gaining popularity again and google is very heavy user of this front-end framework tensorflow for machine learning it's so widely used i mean we cannot not mention the llms uh with the that was not the technology but the paper that that kick-started all of this with attention is all you need the go programming language chromium as the the browser engine and just just so so so many other things.

2:11:08I think, you know, Meta has a bunch of strong contributions in Microsoft's in certain areas, but I feel Google has a really wide range from like back-end frameworks, machine learning, front-end frameworks, protocols. My sense is that overall, they might be the single most kind of contributor to like the kind of broader open source ecosystem, especially when you take the papers into account that that kicked off even more projects or software businesses yeah and inspired people as well and like looking through some of the papers even from early on but even later papers that i look at like they're also very open with 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?

2:11:59And I do feel like, and like I was reading through some of their old like tech posts, blog posts as well. Uh, like they have, like they had a tech blog for, or maybe just a blog for like Gmail. So like the Gmail team had a blog that they wrote from like 2007 to 16, where they just talked about the time that Gmail went down and they had to go in and recover data from all their tapes. It seems like they haven't ever, or like they don't think of sharing this information as some kind of, you know, moat or something they need to be secretive about because like what would happen if other companies copy us?

2:12:38I really like that about Google actually. I mean, I think it used to be like that. I feel that might be slowing or maybe there are just not many blogs. I don't remember like any major engineering teams sharing, oh, here's like cool learning. So I think that might've been the earlier years. Yeah, it could have been. and i think now it might be a bit more controlled and there is no like one google engineering blog or i don't even know of like some other teams but still for the open source for sure and for the paper so that the research and the open source is there and i mean to be fair on conferences google speakers do show up and they do share they do talk it might be a little bit changing because now google does sell to developers they have some developer tools like 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 those area they're kind of a lot more active of sharing like all right here's how to use it how to build it etc but 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 lessons, some boring that others can use.

2:13:53And I think where we got to is that they probably did it because, well, first of all, now looking back, it was good for their, very good for the cloud business to have a technology where it's very easy to move from, let's say, containers on AWS or Azure to GCP. also by knowing this there's not much harm it wasn't too much investment for them to do it but it now helps the recognition of the brand it helps with recruitment and it and they're also now pretty much steering the technology that is the winner kubernetes they have a huge say in it like yes it's an 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 maybe it's a mix of these things, but it never felt to me that it was like some sort of business decision.

2:14:43It was probably some engineers thinking like, ah, it's a cool idea. Why not? And then you can justify the business for it. So like, I wonder if a lot of Google is like this, like engineers are like, oh, here's an idea. I'm like, okay, let's see if we can justify some business numbers. One of the things, again, like we're doing this research from the outside looking in, right? Like we're able to get to the stuff we can get to and we've talked to people. So and one of the things that has come up is definitely like the culture is shifting. Like there's like, you know, the winds of change in Google following, you know, partially just like the vibes of the industry as a whole, but partially very much internally.

2:15:27Also, during the pandemic, you know, they had some big leaks. So, like, they stopped some internal transparency in the all hands and the full access to, like, everything going on. Like, I know that's been restricted. Yeah. So, let's talk a bit more about this because I feel this is like the Google of today. Basically, we've kind of arrived from, like, where Google started, how they built, like, all these cool things. to what is Google like today from all that we've gathered? And I guess maybe we should just reflect a little bit on how the whole industry has gone through a massive change, which was, I mean, there was a couple of left and right things.

2:16:11First, there was a pandemic, which the whole world thought would be a disaster, and then it turned out to be a blessing for tech because everyone started to hire like crazy, and interest rates were still down. There was close to zero interest rates in the U.S. and worldwide on borrowing money for more than a decade. And this was just interest rates were just about to go up before COVID. And then because of COVID, every country cut it down to like zero for another two years. So tech had this thing where there were still like zero interest rates, meaning investors couldn't really put their money anywhere.

2:16:40But like tech stocks or startup investment, tech had a big boom. Everyone started to hire. So this was a great time. And this was 2020 and 2021. I had so many friends and former colleagues who like got 30 40 50 percent compensation increases like just by going to a company that did similar things but they just raised money it was a great time and a really hard time to hire or to retain people kept leaving left and right I heard of hiring managers a hiring manager who had a engineer sign and ready to join but they didn't didn't show up on the first day and i was like oh called them up and like oh yeah i got like a 20 higher offer sorry i'm working somewhere else now and then this was great for like a year or probably a bit more than a year and in 2022 just as lockdowns ended and the world recovered tech started to crash down there was like mass layoffs across companies 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.

2:17:44And then a bunch of other startups, including like Stripe and some other, almost every kind of large company did layoffs. And this turned out later that as we look back, it had to do with interest rates rising. And when interest rates went up, this meant that companies and investors looked for profitability. So everyone suddenly focused on that. And there was a bunch of overhiring in the previous year. So suddenly we had this like dual shock effect of going from everyone in tech is in demand and people could not hire enough bootcamp graduates because there were not enough university graduates to just lay off shocks happening as well.

2:18:21A 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 haven't really had any layoffs. And Google used to be known as the place with like great job security, work-life balance, almost impossible to get fired if you do a minimum good enough job. And then they did like 6 % layoffs, just cutting people with like, including people with 10, 15, 20 years of experience, just sending an email to them at night.

2:19:05And I think this really changed the mood at Google. This was 2023. And then in 2024, there were some more layoffs coming in, not as many as before, but it now seems like that kind of period of Google was perfect in so many ways. Perks, money, work-life balance, clubs, investing in everything. It was just impossible to hire away from Google pretty much. Now there's a bit of a sense of there is some level up being cutthroat not as much as their competitors like meta or amazon where it's a lot more tougher but but still it's it's like you know it's a company at some point you might get fired and you'll get a good severance but they'll tell you that it's it's game over and maybe it's not your fault either but 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 side and at least startups have a chance at least they can point to one thing google does not do perfectly yeah i mean it'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 so in terms of like you know YouTube was and is in many ways the new TV like it is dominant but then TikTok comes along and TikTok is you know much more focused on the users and grabbing your attention and getting you pulled in um whereas like youtube has definitely done that as well but like not to the same extent in terms of the shorts but then all of a sudden like now youtube has has and kind of has to push for shorts because then 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.

2:21:33And, you know, Google search results are like a lot of them are sponsored. This doesn't feel great. So I think there's a bit of a shift as well in terms of just, you know, like they don't, yeah, they cut the don't be evil, but like maybe they leaned into it as well. Who knows? Well, but I think this is the part where, so I saw Manu Kornet, who writes all these comics. He was there for 12 years at Google. He then quit Google and joined Twitter. And then, lucky for him, he joined right as Elon Musk bought Twitter. but he joined he told me that he they love google because he over the 12 years i think from 2010 to like 2022 towards the end he started to become disillusioned of google because he joined with you know he believed like what they said that don't be evil that make the world a better place whatever uh and you know build cool stuff and then he started to see how a lot of his comics started to become more reflective of how he's thinking of just how like he had a comic of google's naming of the throwing darts, how it's all chaotic.

2:22:38It was starting to criticize a company where clearly there's a lot to criticize about Google. But my, and some of the, sometimes profits start to come up on some of his comics on how Google is prioritizing profits. And so here's the thing, like when you're going up, including 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 a staff engineer and the managers 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?

2:23:37And how can Google keep paying top of the market? And it's to do with their profits just keep increasing. It's ridiculous. If you look at the chart, every year Google grows about like 15 to 20 % in revenue, which is bonkers because they're now so big. They're making like 300 and something billion dollars per year. But as long as that happens, things will be good, right? There's not going to be large layoffs, there will be large bonuses, all the perks, new offices built, etc. As soon as that slows or it goes to zero, bad things will happen because there will be layoffs. And Google is doing everything to not make that happen.

2:24:16But eventually that reality will creep in, which is at some point your job might involve helping Google make more money so that they can hit this thing. or if it's not making more money, then help investors believe that next year they will make more money, which has to do with all of the things why Google is going all in on AI or if that doesn't help them, then tell them how you're going to cut costs faster. So I think at some point, both in the life of a company, but also in your seniority, you cannot ignore the business and then you cannot ignore like how they make money, how they will make money.

2:24:52Will 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 will include things that are controversial, right? Like, again, like, will it get into military contracts? And the easy answer will be no. But now when you need to increase your revenue by 20 % and by saying no to them, you cannot do that, then there's all these things that trickle down as a result of that. Yeah, it's growing up in an industry and in an economy that only goes up. Well, then Google has, it went from being a startup in a garage, not even 30 years ago.

2:25:33Wow. In 1998, like just an idea to one of the biggest companies in the world. I think fourth biggest company right now by market cap. And you know, like how much more that can you grow? Like, I'm sure you can grow, right? But where is it? Like, okay, they can now, you know, they can aim to overtake. Right now it's NVIDIA and Apple and Microsoft ahead of them. But then what? And will growth always continue? I mean, this is more of a philosophical question, but I think all of big tech will eventually have to reckon with this question. Because we went from tech companies being kind of underdogs, you know, like there's people who still remember Facebook just being an idea or like being used by teenagers.

2:26:11Same thing with, you know, older listeners or viewers when Google did not exist to like, yeah, they won. And now the question is, how do they keep winning? and eventually winning is innovating. But at some point, it might be trying to lock out other competitors, which, you know, Google is being sued right now by the 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, let's say, iOS. It's interesting how things change. Yeah, and it's interesting. It's like the amount of power these companies have as well.

2:26:51I personally couldn't imagine life without Google because like, you know, it's my calendar. It's my email. It's like, so yeah, I have a background in design and there's this general idea in design that really good design is design you don't notice because it just becomes a seamless part of your day-to-day experience. Like you can point out bad design easily because those are the things that you notice and that provide friction in your life. and google is like they have a lot of things that just you barely think of them because they're so ingrained in your life which means that you know they do wield a lot of power like you 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?

2:27:46Yeah, and I think there's a good question, because I think so far, a lot of what we talked about Google and what makes Google really unique is how they started. There was a startup. It innovated so much. They had 20 % time. They kind of got rid of it in 2013, so about 10 years ago. The vibe is also changing. But the reality is that anyone who joins Google today, it's a very different company than it would have been even 10 years ago, because there's a phase of growing and innovating. And there's now pockets of innovation, right? AI is still up for grabs there's a really open battle between all the leading ai companies including google 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 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 don't mess up.

2:28:40Or if it's a cash cow product like Google Search, you know, we've now seen reports that some of the executives knowingly kind of made Google Search worse to have people see more ads to generate more revenue. But the point is like working on a product that has been built, it's been proven, it's been innovated. There's now very small innovations compared to what it used to be like. And so at some point, which I don't think it's a necessarily bad thing, by the way, but at some point this thing comes where like, okay, like if you want to work on something that used to be like the old Google, it's probably going to be a startup.

2:29:18Or if you're lucky, it'll be a team inside of Google that has a Greenfield project. Again, like all of those things happen all the time. But yeah, but for some of the big areas, it's different work to work there. And this is, by the way, how this is one of the few ways we used to be able to, when I was working at Uber and we were a lot smaller than Google, how we used to be able to get people with Google offers with stronger overall compensation numbers, except us. Because we would tell them like, look, you can totally go to Google, like get paid really well and all that. And, you know, you can be a cog there.

2:29:52Like, you know, like do your little small little thing, you know, like tweak a few things and just be unsatisfied with your work. Or you can come here. you can get less cash, but like here's all this stock, which, you know, it's the same we promised. Well, I mean, we couldn't promise, but 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 you're like everyone, and we're building something new and you'll have freedom. And that was the thing that made a lot of people do it. In fact, I think that's the reason that people will leave this really cushy place called Google is if they just get a little bored and they feel that they could do so much more.

2:30:32Obviously, there's always innovation. But it just looks different today, I think. And the scale of it is different. Because, I mean, Google Calendar does come out with new fun things fairly often. And there's new features in Google Meets and Google Chat and all these things. But, yeah, it's a much smaller scale. so i think it's like you can definitely still be like do fun innovation 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 we know today who could get a bunch of value out of working there?

2:31:23And when could be a good time, assuming you managed to get in? Because I think we should be clear, getting in is super hard. But for those there, what could be a good question to ask of like, am I in the right place? Or should I use this privilege that I'm working at Google? Because once you're at Google, it's so much easier to go anywhere and maybe explore some other avenues. There are some of the things that we've been sort of talking about the whole episode, if you're really super into the specific tech stacks and trying new tools and playing around with new frameworks, the second they get out, you know, Google is not for you.

2:32:02Basically, you're not going to be able to use or reuse any of your like tried and true favorite things because you're going to be working with completely different things at Google. So you're basically saying like if you're interested in the frameworks in the industry that startups use, that you build up the knowledge that, I don't know, like the latest React framework or the 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 knows?

2:32:43Exactly. Exactly. So that's one part of it. Another part, like if you're someone who like who is not into reorgs or like things changing all the time, like the Google thing of being into ambiguity, like if you like things being somewhat like stable and yeah, then Google is probably not for you. interesting because the perception outside will be that google is stable as a whole i mean maybe teams change but you're saying you know things change so just get used to like you might get new managers or several a year yeah exactly like reorgs are a staple yeah i actually i think i talked with someone i think it was google who said like i had like you know like seven managers and 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 more faced out it more became like 120 % time where you can work on things, but it's going to be, you know, in addition to your normal work.

2:34:07But they do also keep, they have some like incubator type teams at Google still. They have one thing called Area 120. You know, they build completely new, very like startup based, completely new apps that very quickly, like often just transition straight into the killed by Google graveyard uh but you know they'll probably like they will reuse some of this technology as well so like like there is the like killed by google is definitely true but it's not like all of it's wasted like they have 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.

2:34:54And, you know, so like if you're into innovation and trying new things, Google can be for you. But it's not, it's probably also not going to look the way that you imagine it to look like. And if you get in love with your idea and, you know, the whole like kill your darlings thing. If you're not good at killing your darlings, then probably just do startups instead of Google. 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.

2:35:30Like there are some other companies that are, that, you know, keep going up and down right now. OpenAI, for example, is also very, very recognized. And of course, you know, Meta. But Google has been like this for almost 30 years, almost since the beginning, and it continues to be. And part of it is the bar of getting in is just very high. So there's this thing, I think this is, it's kind of funny that we're saying 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 three years, which has never happened before.

2:36:07So until then, they were growing. Basically, it was easier to get in, considering assuming the same number of candidates applying every year. so it is kind of getting harder to to get into google so it's not saying for granted so like my suggestion would be is if there's a reach out from a company like google it can be a challenge to just go through an interview process even if you have no intention because your interview process is very very similar to the interview process of the companies that are hardest to get into including the scale-ups and startups they're super hot open ai and traffic they will hire very similarly than how they hire from Google.

2:36:45And then there's this other interesting thing. If you look at where the hottest startups of today hire from, you know, may this be OpenAI, Entropic, as I mentioned, RAM, Stripe, so many of them will be from Google. Like Google has a lot of people who are underutilized, but they're very smart and very capable. And the companies that can pay more than Google or can match it or can have a bigger promise with equity will often just take the shortcut instead of interviewing so many people with no proven tracker, just go to the source. So that's one. And then there's a network. Because if you're someone who is curious or talks with other people, inside Google, you can build up a really good network.

2:37:29Just getting to know people, the ex-Google network is very strong. The fact that there's a Ziegler network who, as I understand, they help each other. There's like investment and networks and all these things. So if you have the opportunity to potentially get into Google, see if you can, and then decide if you want to do that. Having it behind your back, it can strengthen your resume and your opportunities for like a decade or even more to come. You can always say you're ex-Googler. And the thing is, not many people will be able to say that globally, especially as a software engineer. So yes, one more thing to keep in mind.

2:38:05I know it's changed, but like there is one thing of like interviewing with Google, like it is a bit of a funnel. So like there are some of the interview process that's just like, you know, get 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're used to. Like talk to a few different teams, like see the vibes before you like jump on fully. Yep. And Google that has this interesting thing called team matching, which is for software engineering positions, typically they don't interview for a specific team, but they interview in general.

2:38:49And once they decide like, all right, you're good, you meet our bar, then a team needs to claim you. So you need to kind of go through a team matching process, which can be really frustrating, by the way. The recruiter might tell you like, congratulations, we want to hire you. And you're like, great, where can I, like how much is the compensation? How are I signing? Like, we just need to go through team matching. And sometimes this team matching can take months and sometimes it comes back with, I'm sorry, no teams were available or wanted your profile in this case. So that's the other thing. It's kind of harder to get into than most places.

2:39:24And I've heard that recently, about like six months ago, this happened that a bunch of people were rejected and very disappointed that they couldn't get into so it's one of these things again it's it's it can be frustratingly hard to get in when you want to get in but again it's good to know because i hope that we were able to share some details because this environment really is not for a lot of people and you do need to put up with a lot of a lot of things that come with with large companies and in this case the one that is very transparent which means there's a lot of information overload as well.

2:39:57Oh yeah, I think if you're not good at multitasking or if it stresses you out to have to go to a meeting middle of the day while coding, you'll probably hate this place, probably. Yeah, again, 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 my last reflection on who would fit at Google. It is a big company. It is so big. There's so many people. again like I was there for like not even four months and in that time I I met so many people and like yeah if you go to an after work and meet someone it's like yeah you're talking to someone who might as well be at a completely different company and also like when I left and then after like after a couple months I happened to be in London again and I like went to the office and visited and like in just like four or five months like I recognized like almost no one and the people I knew it's like no they'd already moved or actually like this used to be the case where the London office used to be kind of a holding hub as well like people would be hired and then go to the London office for a year and then they would move to the Zurich office because like immigration wise that was easier from a lot of companies 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 leading.

2:41:46They're a frontier lab. They're one of the few companies who built their own model. Microsoft doesn't even do that. Or if they do, they're kind of hiding it. But they're also a company where a lot of people retire from. So this is the company where it's not unusual to see people with 20 plus years of having worked there. And when you look closer, it'll be different teams. They will switch teams every now and then positions. Sometimes, 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 very happy there, or that they're the happiest they can be compared to other options.

2:42:32And they do it all the way to retirement. And because Google pays as well as it does, retirement doesn't necessarily come at the around 65 or whatever the legally mandated is a lot of people will say i'm retired earlier because i have saved up enough together with google's perks and pension program and and whatever that i will now have a very comfortable life 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.

2:43:11But again, it's rare to see companies like this. So that's just kind of an interesting positive. And, you know, maybe similar to banks used to be places like this, where like in tech divisions, when I worked at JP Morgan, it was pretty common for people to retire from there because it was stable, it was predictable, and there were some lifers, as we called them. But I mean, I think it just shows the tech industry is changing. You know, now there are stable companies, the startups that turn into stable companies that are still innovating, but they kind of won their market. So Google is definitely one of them in some of parts and in some pockets, very exciting and doing a bunch of interesting stuff.

2:43:48We've just spent how many hours talking about Google? About three. Yeah, we could probably go on. And we do have, you know, we have written deep dives to accompany this podcast. So if you want to go in even more detail about some of this stuff, go check out the deep dive articles. will have lots of links. And again, because Google is so open, a lot of this data you'll just be able to find. Like you can find the papers we've talked about. You can read the books we mentioned. And that's the thing. One thing that I would just close with is we could go on. We're trying to cap it at a reasonable length, as reasonable as it got.

2:44:29And we do have more structured notes in the show notes below that we're linking in the Pragmatic Engineer deep dives as well in previous deep dives. But don't forget that for every company that is a large company, it's not just one place. There's so many different teams. And everything that we might have said or covered about how things generically work, it might be absolutely false for that specific team that you might be working in or that your friend is working in. So don't forget, I think personal relationships really do matter. And what I have seen, the reasons people go to Google, for example, or leave Google might be their manager.

2:45:04They had an amazing manager at a company and they happened to move to Google and then they followed them and the other way around. So, you know, people come and go between companies like Google, Meta, Big Tech, startups and scale ups. And there are some things that can be generalized. But yeah, don't forget, if you meet interesting and valuable people, just, you know, keep in touch with them because they might end up in interesting places that might or might not be like these. And I hope that these details were interesting and probably collected for the first time in this format. This was an experiment for us as well.

2:45:42So let us know what you think of it. Yeah, it's been a lot of fun, a lot of information. But yeah, hopefully we'll do this again with other topics in the future. Yeah, let us know your feedback and hopefully we'll see you in the next one. This was our Google Podcasts episode. If you'd like to get even more details about Google's engineering culture, check out our deep dive article in the Pragmatic Engineering 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.

2:46:18Thanks, and see you in the next one.

From the publisher

Brought to You By:

•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Something interesting is happening with the latest generation of tech giants. Rather than building advanced experimentation tools themselves, companies like Anthropic, Figma, Notion and a bunch of others… are just using Statsig. Statsig has rebuilt this entire suite of data tools that was available at maybe 10 or 15 giants until now. Check out Statsig.

•⁠ Linear – The system for modern product development. Linear is just so fast to use – and it enables velocity in product workflows. Companies like Perplexity and OpenAI have already switched over, because simplicity scales. Go ahead and check out Linear and see why it feels like a breeze to use.

—

What is it really like to be an engineer at Google?

In this special deep dive episode, we unpack how engineering at Google actually works. We spent months researching the engineering culture of the search giant, and talked with 20+ current and former Googlers to bring you this deepdive with Elin Nilsson, tech industry researcher for The Pragmatic Engineer and a former Google intern.

Google has always been an engineering-driven organization. We talk about its custom stack and tools, the design-doc culture, and the performance and promotion systems that define career growth. We also explore the culture that feels built for engineers: generous perks, a surprisingly light on-call setup often considered the best in the industry, and a deep focus on solving technical problems at scale.

If you are thinking about applying to Google or are curious about how the company’s engineering culture has evolved, this episode takes a clear look at what it was like to work at Google in the past versus today, and who is a good fit for today’s Google.

Jump to interesting parts:

(13:50) Tech stack

(1:05:08) Performance reviews (GRAD)

(2:07:03) The culture of continuously rewriting things

—

Timestamps

(00:00) Intro

(01:44) Stats about Google

(11:41) The shared culture across Google

(13:50) Tech stack

(34:33) Internal developer tools and monorepo

(43:17) The downsides of having so many internal tools at Google

(45:29) Perks

(55:37) Engineering roles

(1:02:32) Levels at Google 

(1:05:08) Performance reviews (GRAD)

(1:13:05) Readability

(1:16:18) Promotions

(1:25:46) Design docs

(1:32:30) OKRs

(1:44:43) Googlers, Nooglers, ReGooglers

(1:57:27) Google Cloud

(2:03:49) Internal transfers

(2:07:03) Rewrites

(2:10:19) Open source

(2:14:57) Culture shift

(2:31:10) Making the most of Google, as an engineer

(2:39:25) Landing a job at Google

—

The Pragmatic Engineer deepdives relevant for this episode:

•⁠ Inside Google’s engineering culture

•⁠ Oncall at Google

•⁠ Performance calibrations at tech companies

•⁠ Promotions and tooling at Google

•⁠ How Kubernetes is built

•⁠ The man behind the Big Tech comics: Google cartoonist Manu Cornet

—

Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email podcast@pragmaticengineer.com.



Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

More from The Pragmatic Engineer

All 45 episodes
Google’s engineering cultureThe Pragmatic Engineer · 2 h 46 min
Listen in VO