Google’s engineering culture

Google is the world's most used company

by the number of users between products

like Google search, YouTube, Chrome,

Android, and many more. But what's the

company like from an engineing point of

view? We've spent months researching

this topic to bring you the most

detailed deep dive to date on Google's

engineing culture. We go into Google's

unique tech stack and why every tool is

custom at the company. How Google works,

roles compensation performance

reviews, on call and internal mobility.

How Google changed over the decades and

advice on how to thrive at the Google of

today as a software engineer and many

more topics. If you ever wanted to work

at Google as an engineer or manager or

want to understand how one of the

world's most innovative tech companies

operates, this episode is for you. This

podcast episode is presented by Statsig,

the unified platform for flags,

analytics, experiments, and more. Check

out the show notes to learn more about

them and our other season sponsor. So,

let's get started. Hi, I'm Gerge, your

podcast host and author of The Pragmatic

Engineer. Hi, I'm Alen and you may or

may not know me as the researcher uh of

the pragmatic engineer. You might have

seen my by line in some of our deep

dives and survey articles.

Uh, and today we're going to try out

this new format to bring you a deep dive

by talking you through uh, everything

Google. So, I I was an intern at Google

for a couple months back in 2015. I was

based in the London office. Uh, worked

as an a UX intern actually. Um, that was

before I uh, worked as an engineer after

that. Uh so I have a little bit of of

like inside vibes but

not that much.

>> Let's start with everyone knows Google

for sure. You you cannot not know it but

what are some interesting stat stuff we

found about them?

>> The numbers if we're going to go there

like it is easy to forget how big Google

is sometimes. So yeah, the the latest

numbers there's 182,000 employees across

all of Alphabet. Uh but obviously the

majority of that is in Google. We have

numbers from 2020 that there were about

50,000 engineers and that's up. So like

in 2015, which was the first time they

came out with a lot of the numbers about

the engineering work, there were 25,000

engineers. I think size-wise this makes

them similar to Microsoft in total

employee count for engineers. A bit

unclear. Maybe Google has more maybe

Microsoft. Probably similar to Amazon,

but Amazon has weird numbers cuz they

kind of mesh the the workers, but

they're they're a lot bigger than Meta,

for example. Like they're they're like I

think two, three times bigger. So

they're easily one of the biggest kind

of top tech companies in the world, if

not the biggest. I I I think the

question is with Microsoft, but I think

when it come to prestige uh

compensation, uh they're they're easily

number one in in this regards. Uh scale

of of of work that that people work on.

And speaking of of scale, uh you know,

like again Microsoft might have similar

number of employees, but when it comes

to Google, I think numbers are a bit

unclear, but around 3 to 4 billion

people per month use their services

between search, Gmail, YouTube. I mean

all of these are marketing services

right I think search is more than 1

billion people per day which is kind of

one like every I think nine person in

the world uses search uh YouTube has 2.5

billion monthly which is more than TV

viewers and then Gmail has 1.8 8 billion

active users and I I'm pretty sure

looking at my my newsletter about 70 or

60 70% of emails are are Gmail.

>> Yeah, for sure. I' I've seen the same

stats and like if you broaden out the

Google Workspace apps like including

Drive and Docs and Calendar and stuff,

they have over three billion users and

like over 50% market share. like they're

so far ahead of of Microsoft and Office

essentially with YouTube as well. Like I

can't help I I'm a big YouTube user and

have been for a long time and I I'm

always so fascinated by their general

stats. Uh like there's 5 billion videos

on YouTube. Not all of them are

necessarily like up and available. like

the latest numbers 360

hours of content is uploaded every

single minute.

>> Yeah, that that's a lot of parallel

processing.

>> There's 2.6 million videos uploaded

every day. Almost a billion a year and a

billion hours of video is consumed every

day.

>> Yeah, those are just just large numbers.

And I think like you know this is the

thing with Google, right? Technically

it's not even called Google.

Technically, it's Alphabet, which the

biggest part is is uh Google that that

still owns things that like Chrome, the

leading uh web browser, Android, which

is still the the leading smartphone

platform globally by a lot by about 70%.

In the US, uh iOS is now getting bigger.

So, that can be a bit bit misleading.

But then there's things like

self-driving. you know if it's

self-driving it's the only the

commercial leading one is is Whimo which

is which is not part of Google but part

of Alphabet and in terms of the

footprint

>> yeah Google's big like just globally as

well they have 72 offices in over 50

countries or 50 countries so they have

offices all around the globe US Europe

Asia Sydney Brazil

>> yeah but what we care mostly about is is

engineering so they're engineering

offices there's about like there's more

than 25 ones, but the kind of the the

big ones that we we should definitely

mention, headquarters, Mountain View in

Silicon Valley,

>> the Google Plex.

>> The Google Plex. Yeah. Really cool

office. Like really cool u kind of

perks. Android figures. It was so cool.

I I was there last year. Addiosmani uh

took me around on on the Chrome team in

New York office also big one. Seattle

and they have a lot of offices in

smaller ones in in the US. LA,

Pittsburgh, Boulder, a lot of like

specialized ones.

>> Cambridge and Massachusetts is pretty

big as well. Yeah, the the Seattle uh

Seattle office is definitely one of the

bigger one. And uh you might hear it

referred to as Kirkland as well because

Kirkland is the suburb of Seattle where

it is and it's um yeah, lots of cloud is

based there.

>> Yeah. And then Europe and the UK have

large offices. The biggest one known in

Europe is Turk. It's actually probably

Google's European HQ in terms of

engineering if if you will. And a fun

fact is that Turk pays almost as much in

compensation as in the US which is

really really interesting. A lot higher

than their Europe other European

offices. London is another huge office.

Dublin a big one. Dublin I think might

be bigger than Zurich in terms of people

but not necessarily engineering.

>> Ah

>> like they have a lot of sales.

>> Yeah. Yeah. Makes sense. Makes sense.

>> Oh, you're right. I actually used to

have friends uh nontechnical uh who who

were in Dublin that Yeah, that was

You're right. You're probably the big

but I was thinking engineering.

>> Engineering is the biggest hub for sure.

>> Munich is a big one for engineering as

well in in Germany. They have a Berlin

one. I I understand that it's a bit

smaller. And in Paris is a research

office as I understand. There's a bunch

of smaller ones. Like the thing with

Google is they do have like some smaller

bits. For example, even in Budapash,

Hungary, they had a very small

engineering office. I think they still

have, but it's it's tiny compared

compared to all these other ones.

>> Yeah, there's actually one here. I'm

based in Stockholm. So, they have an

office here as well that's uh grown a

fair bit. It's like a few hundred

people. Fairly big on the engineering

side. work a lot on uh video meets and

calls and stuff

>> and a lot of US tech companies would

stop here but Google obviously being

Google they they have engineering

offices uh a lot of other places

Bangalore and Hydrobot are two massive

offices in in India

>> they've grown so much as well like

they're and growing like those are like

a lot of the open positions are based in

India

>> yeah we we had an issue with that when I

when I used to work at uh Uber as an

injury manager. Uh we were hiring in

Bangalore and what we found is we had

trouble hiring senior engineers because

whenever we'd extend an offer and that

person was interviewing at Google,

Google would offer 10% more than

whatever we did. Always 10% more. So

after a while back, this was back

several years ago, but the team kind of

backed down and they started to hire

like less experienced engineer. It this

was a big kind of hiring fight. But

there is this thing about Google, by the

way. If you have a competing offer,

Google and they want you and then you're

like senior and above, Google almost

always will offer more. They don't care

too much about their internal bands.

Again, over time, this might have

changed and for more junior positions,

this could have changed. But I had a

director of friend who was in the

situation uh between uh having a

competing offer at uh Meta and Google

and and and it was really high already

and then Google just really wanted this

person and they just offered more.

Google like when you become in demand

this is a really interesting situation

but it's it's kind of an open secret on

on the job market and then they have

offices Tokyo, Japan, Sydney, Australia

and probably every kind of major city

and and you'll have like so Google has

so many offices right and engineering

can pop up anywhere.

>> Yeah, exactly. They they have a pretty

big one in u Brazil as well in Sa Paulo.

They have a lot of search engineers. But

it's also it's funny um because one of

the stats for Google is like they've

always had such good revenue. So like

back in in 2024 there was $350 billion

in revenue. 75% of that comes from ads.

And I think Google like they've done

good for themselves because they figured

out such a good revenue model from day

one for themselves. So they've always

been able to offer all of these high

salaries and pay for so much stuff.

>> I'm going to challenge you a little bit

because I so like we know like Google is

insanely profitable, right? Like there

is no doubt about it. However, when we

look a little bit closer at the unit

economics and you we're going to we're

going to quickly move to engineering,

but let's talk about the kind of where

the money comes from. Google's like

profit margin of like you know on $100,

how many dollars is profit is is around

like 30 or 35%. So like you know $30 or

$35 are pure profit and they're not the

most profitable company. Companies like

Visa or Mastercard and Aen they do about

$60 or 60% profit rate but those

companies don't pay as much as Google

does for their engineers. So there's

this interesting thing where there have

been companies earlier who have found

out similarly really lucrative really

good business models again like with

Mastercard you know you you make a

transaction they take a percentage they

built out the global network boom profit

but they don't compensate engineers or

they don't they don't kind of treat

engineers the way Google does which

we're going to talk a lot about. So, I

think Google did something interesting

where like by the end of this episode,

we're going to have a better idea of

what actually happened. But there's two

things, right? Either they they created

this new thing where they became so

profitable because they treated

engineers so well. Or despite being so

profitable, they're treating engineers

really well and maybe they're becoming

even more profitable and now a lot

bigger than Mastercard or or Visa or

other companies. Now one interesting

thing that I I wanted to bring up is is

when you joined Google there was this uh

note from a founder who got acquired uh

by Google called Treyas Banzal uh

10erson startup got acquired several

years ago and on a blog post uh this is

what he wrote uh he wrote working at

Google is like having a second passport

go to animate your city in the world and

you badge your badge unlocks beautiful

office with with great food great desk

and a high-speed link to every person in

Google's 200 100,000 person network and

it's like visiting America as a

foreigner. Everything you see inside

feels oddly familiar because of his

massive export influence yet is just

slightly slightly different. I thought

this is fascinating. So like you when

you join Google you have suddenly access

to all the offices you you you can go

into any of the offices. I mean travel

budgets permitting. I understand they

now have some of those but yeah you have

access to this and and to all of the the

people. I think this is something that a

lot of people don't realize from the

outside of just how it's it is one

company but it's also more.

>> Yeah, that actually resonates quite a

lot with my exper my brief experience

there as well. Again, we'll get into

this but yeah, I think Google is so

special especially if you compare it to

the other big tech companies because

like in many ways like there's no one

Google like it's not one company working

on one thing from very early on they

worked on. so many different things. So

like you can reminisce my memories of

Google is like like it feels more like

you can talk to other Googlers and it

feels like they would be at like working

at a completely different company but

you you're in this like alternate

reality bubble where when you're in the

bubble you know so many things so that

you can only talk about with other

Googlers which yeah are like so it's

more like they're in the same alternate

universe bubble as you rather than at

the same company as you. And yeah, the

badge is really the the passport to that

really. It's a it's a really fascinating

place to be.

>> So Google has the most unique tech stack

in the world and and we're going to go

into a lot more detail, but they have

customuilt everything. So unlike almost

every other startup or company that has

some level of standard tech stack that

the rest of the industry uses, Google

just uses their own stuff and it works

really well for them. uh which which has

an interesting outcome.

>> Yeah. Yeah. We'll get into a lot more

detail.

>> They also influence if not even kind of

indirectly created how hiring is done

today with these lead code style

interviews. They started with the

algorithical interviews and they kind of

I guess the perception of of how Google

having a hiring bar made it go

mainstream across the tech industry and

then they also invented roles like the

SR role which is now kind of pretty

widespread across other companies as

well.

>> Yeah, exactly. Even though it might be

called something slightly different with

like you know DevOps, reliability

engineering etc etc. One thing that is

very unique about Google is how many

internal tools that they've built. Borg,

blaze, piper, critique, code search.

We'll talk about a lot of them today.

>> Yeah, we're going to get to them. In

many ways, Google was one of the first

modern software companies and how we

think about them today. Not just all the

perks that they provide, but building

best-in-class internal tools. They also

pioneered something that we take for

granted today. Great data tools for

product and engineering teams. Google

was one of the first companies to take

analytics, dashboards, AB testing,

feature controls, all of them together

seriously. They built advanced tools and

made it available to their thousands of

engineers and data scientists. This was

the approach that enabled a fastmoving

bottoms of approach to product

development.

>> And this practice of having your

engineering teams have access to these

tools really did become the baseline for

standout tech companies. Um, for the

last 15 years, pretty much every major

tech company has had entire teams of

people rebuilding this kind of feature

flagging AB testing stack of tools

internally.

>> But now something interesting is

happening with the latest generation of

tech giants. Rather than building these

tools, companies like OpenAI, Antrophic,

Figma, Notion, and a bunch of others,

they're just using Statsig. Static has

rebuilt this entire suite of data tools

that was available at maybe 10 or 15

giants in a such a powerful way until

now. They built experimentation with

proper statistical analysis, feature

flags for save deployments, session

replace analytics, and more. All backed

by a single set of product data.

>> And one really nice thing about Statig,

it's it's not just about saving

engineering time. It's about getting

worldclass infrastructure from day one

without having to build it yourself.

Rather than arguing about metrics

definition or troubleshooting broken

tools, engineering teams can just focus

on building a really great product.

>> The other thing is scale. Since already

processes trillions of events per day,

which is enormous data, by the way, they

also scale with you. Plus, you can

integrate Staxig into your existing

product data easily as well. If you're

interested in giving your product team

an access to incredible data tools, go

to stats.com/pragmatic.

They have a generous free tier, a

$50,000 starter program, affordable

enterprise plans. Just tell them the

pragmatic engineers sent you. So one

thing that is like so unique about

Google is they have completely custom

internal infrastructure even today and

there's a reason for this because when

they started back then they needed to

build this knowing how uh the existing

tools didn't work for their scale. So

maybe let's let's talk through some of

the unique uh tools tool set that

someone would see if they start to work

inside Google or or if they're they're

working there, they they see them.

>> Yeah, exactly. And I think actually it's

like why this tech stack looks the way

it does is very like it it's because

like because it was search. It's like

well this needs to be global from day

one. So we need to have this in

infrastructure from day one to get the

speed and re and reliability that we

want. And so that's why they just jumped

straight ahead with like we'll just

build custom stuff from the ground up.

So yeah, like they scaled into six

digits of machines in the early 2000s.

>> So like hundreds of thousands of

machines.

>> Yeah. In their data centers. Yeah. There

was a pragmatic engineer post from an SR

a couple months ago I want to say where

he talks about he started at Google uh

doing S sur in 2004 I think it was and

already when he started there were

hundreds of thousands of machines and

this was during a time when

large data centers had hundreds or maybe

thousands of machines.

>> Yeah. Yeah. This this this is Dave O

Connor and he was telling me that I

think in Ireland they they visited a a

data center cuz they they wanted to see

how they worked and they wanted to see

if they could use them and in the end

they figured out they couldn't but they

asked like okay how do you manage your

your machines and they were like oh we

just do manual updates and like they're

like how many machines do you have and I

think they had like maybe a thousand or

so and they just did manually and then

they were telling them like well that

wouldn't really work for us cuz we we're

planning to have at least 10,000

machines but maybe 30 soon And they were

like what are you guys talking about

like that's so because of this like the

kind of the most advanced solutions in

the case of data centers they didn't

have the ambitions that Google had and

that's why like even in the early days

like they knew like okay we cannot do

what everyone else is doing we we need

to figure out build new automation build

new tools and that's actually how they

invented the site reliability engineer

role they they actually needed software

or software engineers who now became

experts at like operating infrastructure

which was unheard of Because until then

you had the IT guys uh who who knew how

to configure, you know, Windows machines

or Linux machines and and knew how to

patch them, how to plug in, how to, you

know, make sure like do all these

things, but they were not software

engineers cuz why would you hire a

software engineer to do to do that? So

like Google did a bunch of these things

and and that's where obviously one of

their biggest uh internal tools which we

mentioned bore comes from uh which is

orchestration system and and Kubernetes

uh was inspired by this. In fact, Google

created Kubernetes based on lessons

learned from Borg and they released it

in open source and internally they still

use Borg.

>> Yeah, exactly. So, yeah. So, Borg is

basically it's a it's a cluster

operating system

>> and then you know do you know what uh

Google's kind of internal version of

data log is called? Borgmon. Oh, yeah.

There's also one called Monarch. I I I'm

not sure which one is which, but yeah.

So, they have a so they have this

monitoring which is like integrated into

Borg. And this is one of the reasons by

the way Google people are like oh why

doesn't Google just move to Kubernetes

and well I mean then they would need to

replace some of these things. Oh and

then they have this thing called uh

third eye uh which is their which is

pretty much what Sentry is from the

outside world and that's also nicely

integrated into all of these systems.

It's kind of like got all the hooks got

all the APIs.

>> Yeah. Like all of the tech stack is

custom. Like there's nothing that's not

custom in the Google tech stack. So,

Borg uh they call it a cluster operating

system and it's yeah like one of the

first things they built is like

realizing okay we need huge data centers

we need so many more machines than

anyone's ever had. What do we need in

order to operate this in a way that is

automated and not manual because that's

not going to scale. The Google data

centers are are and always were built

kind of like from the ground up by

Google and designed in ways that would

fit their scale. Like because it was

like planet scale search from the get-

go, they never had to think about, you

know, like, oh, what's the data center

for like the smallest need because their

need was so huge from the get-go. Well,

well, and and there was this interesting

thing, right, where until Google, the

way to operate servers was to buy these

really expensive sun racks, the the kind

of like, you know, like mainframes

pretty much, super powerful machines.

And Google also had this innovation

where they started to just use plain old

PCs initially literally just took simple

PCs that they put together on like the

the main frame, the CPU, the the hard

drive, and they just put it together and

put it in data center. And people were

like, "What? That's that's so silly."

But they're like, "Look, we're getting a

lot better value for a buck instead of a

$2,000 machine. We can have 20 $100

machines and we can have throughput of

three times." And then they started to

take this a bit more seriously and I

started to manufacture their own

servers, which cannot be bought by

anyone, but but that's how their

internal data centers are built. Google

Cloud these days is built like that as

well, but Google's own infrastructure is

probably bigger than Google Cloud,

interesting enough. But you know, but as

as you just just to your point like they

they they they built a larger scale

compute than anyone needed at the time.

>> Yeah. Exactly. And like with their

ambitions and knowing how big they

wanted to be and the kind of support

they wanted to provide, it's like well

this is what we need to do. I think

maybe also because of the SRV approach

to building out all of this stuff and

because that was so anchored in

software, uh they they did a thing quite

early on where they decided to rather

than going for like let's build the

perfect machines that will never fail,

they realized like at our scale, they're

going to fail anyway. So yeah, let's

just go with the cheap stuff that's easy

to replace and just build amazing

tooling on top of it that makes it nice

and easy for us to operate on. So like

yeah, today it's obviously like cloud

computing is it's the status quo. It's

what everyone's doing. But at the time

again like they did this in 2003 2004

this was unheard of and probably anyone

who heard of it was like what are you

doing? Why are you why would you do

that? Well, Jeff Bases might have heard

of it because he was an investor and you

know, like AWS later launched their

their public cloud, but but yeah, it's

it it was Yeah. Yeah. And I think it it

wasn't just just unheard of it, but I

think this goes back to like Google was

seen very kind of weird a little bit or

like almost mythical for how they hired

cuz like the the way most tech companies

would hire at the time is they would ask

you programming questions of like I

don't know they hired a Java programmer

they would ask you all right how does

you know the memory allocation work in

Java or stuff like that or like if you

know they would ask about design

patterns or stuff like that and Google

like would ask brain teasers they they

would famously they would ask like okay

how many golf balls can you fit in a I

don't know like a van or something like

that and apparently the reason they did

this initially and they stopped doing it

after like several years but they wanted

people who can think outside the box

because they knew that they didn't want

to do what everyone else was doing they

didn't want to copy what Yahoo was doing

or what MySpace or any they wanted to

get the people who rejected you know the

conventional thinking and they were

still smart and brain teasers were seen

as a way to do this. Uh they they

stopped this several years later because

once this kind of went mainstream, you

know, people started to optimize for it

and it turned out that they also

rejected people who were smart but they

were just not good at brain teasers.

Most companies hire for the programming

language that they were using made up

maybe that was like cold fusion back in

the day or like again Java or Python or

whatever. And Google to this day doesn't

care about what language like you're

using. They just want you to use and and

write code with in in um a coding

exercise oftentimes you you can use any

language or sometimes you use code if

it's an algorithmical interview. This

was one of the reasons they love

algorithmical interviews. No no language

no specific language required.

>> Yeah. And I guess that makes sense as

well because the Google tech stack is so

unique. It doesn't like it won't matter

anyway. like they need you to have open

horizons simply flexible and solve

problems because you're going to solve

them differently at Google anyway. Going

back and speaking of just how custom it

is, the fact that like when they built

out these data centers, they also like

they couldn't use or didn't want to use

opted away from using normal like

networking stacks and switchboards and

stuff. They built that from scale as

well. Yeah. Why?

>> Uh so they have something called B4 uh

which is like the backbone networking

infrastructure that has ridiculous

bandwidth and that's the thing that

their like they built out so that their

data centers and the ridiculous scale of

of the machines could talk to each other

and uh that Borg was able to coordinate

uh you know job allocations. They also

chose not to do DNS the standard way

because uh they developed something

called Borg naming service. So the BNS

um and that's because obviously like at

that point and very often you will you

know have a specific IP address and

specific ports.

>> Yeah.

>> Um but Borg from the get-go was very

like well any anything can run anywhere.

So they wanted a level high of

abstraction higher than that. What Borg

does is that they allocate resources for

like jobs and memory and CPUs like

across machines. So the actual IP

address to the machines like it has to

happen fluidly because they don't

allocate specific machines. It's broader

than that. It's more like cluster level

and a cluster is like racks of machines.

>> Mhm. So they they needed that that

abstraction. They need a next level

outside of like you know what's a rack,

what's a cluster, that kind of stuff.

>> Exactly. Because it's like well we have

so many machines that it doesn't matter

and the machines again like because they

were especially in the beginning kind of

like cheap and easy. It's like we don't

like a machine will fail. We don't care.

We'll like another machine will come in

and take over. And similarly they built

out the Google file system back in 2003

or well they talked about it in 2003 um

which was also necessary because of

that. So like a a huge decentralized

uh file system like in 2003 they had

hundreds of terabytes of storage across

thousands of discs and machines

accessible by hundreds of clients. It

had this like basically a storage stack

where you had discs like actual physical

hard drives and then an abstraction

called D above that for a disk but like

the disc could be either a disk or

something else. Uh and then you had the

like the Google file system on top of

that which was later preceded by

Colossus which is what they use now. And

then on top of that they built out all

of these like database like services. So

things like big table, like spanner,

like there's not just like the one

database because it depends obviously on

the uses of the database like what are

you optimizing for? And so internally

they have lots of different variables

and like kind of database systems as

well where they will have some of their

data centers u are like more

specifically for you know better for

certain type of data storage and certain

types of of database you know big table

is more nosql it's sparse it's

distributed it's persistent spanner you

have a more SQL like interface case it's

more important for like real consistency

across the world.

>> Yeah. So I guess the trade-offs are like

is it like write intensive, is it read

intensive, what kind of data are you

storing, like how structured does it

need to be, how are you wanting to

access it, right? So these are all the

differences between the the reasons they

they have and then like as you said the

distribution like like do you just want

it on one machine and if it dies totally

fine or you want guaranteed uh that it's

distributed then then do you want

consistency that immediately as soon as

you write is there but then there's a

latency or then you want to minimize

that or you don't care if it's

eventually consistent and then you can

write. So like there's a good question

of like why does Google have so many

databases and I guess this go back to

like why are there so many databases?

There's so many databases like we just

did on the pragmatic engineer survey.

There were so many like 50 plus or or

even more that people use and they're

all like built by like actually

experienced teams. That that's kind of

an interesting interesting side

question. Why so many databases?

>> Yeah, like databases optimize for

different things and so there's

different use cases for them. But one of

the things with Google from again fairly

early on, Google branched out and like

they didn't just focus on the one search

product, you know, they built out Gmail

which was basically email with built-in

spam filters was like the pitch from

early on as well as a gigabyte of

storage which was also unheard of at the

time. Uh and then they branched out into

you know Google calendar, Google Docs.

Um they did some really big and smart

acquisitions like YouTube, uh Android,

you know, they they had the the in tech

infrastructure that they had. Um and

then they started h getting all of these

new use cases, uh basically companies

operating on top of this stack. And so

they were able like had the needs, had

the expertise and had the data centers

and the infrastructure to build out all

of these different offerings uh for

their own products. I don't know if this

is still happening, but they did

actually for a long time at least and

possibly still they also had backups for

all of their data service uh data

centers on physical tape.

>> Wow. I mean ta t t t t t t t t t t t t t

t t t t t t t t t t t t t t t t t t t t

t t t t t t t durable. So

>> yeah, there are uh in the SRV book which

was published in I want to say 2015 2016

which is available online. You can read

it online. They have some amazing

stories of some like huge outages in

2011 and 2012 from Gmail and the Gmail

one in particular, there was a bug and

they lost like 0.2% 2% of users logged

in and like there was nothing in their

inbox because they lost all their data.

And they wrote like an incident report

saying like this is what was going on

and they talked about how they were able

to restore the data and they went into

what they called Gtape

>> which was their physical tape gape

>> and they spent a couple days manually

going through the tapes to restore the

data to the users. There's this article

published by Google called 10 things we

know to be true. It's a set of beliefs

that they published when the company was

just a few years old. And what surprised

me is how many of these are still true

today. Did you read this article?

>> Yeah. And then the fast is better than

slow which was a defining part of the

culture and one of the core tenants for

their product which was search at the

time.

>> Yeah. And if anything, that obsession

with speed, it's become even more

critical today given how competitive the

market feels right now.

>> Yeah, for sure. Actually, when we worked

on the what's in your tech stack survey

that we worked on a few months ago, one

of the most mentioned words that

engineers used when talking about

tooling that they dislike was slow.

>> Yeah, that was the number one. It's

pretty clear that that engineers or or

even teams that are faster than their

competition and are quick to make

decisions, they use tools that are also

fast in how they manage their work. And

all of this brings us nicely to our

season sponsor, Linear. Linear actually

dominated the project management

responses. This survey as a tool that

techies love using it. In fact, it was

the most loved project management tool.

It wasn't even close. From the

responses, it was clear that the big

part of this was due to how fast Linear

is to use. Right after we posted a

survey results, Linear reached out

wanting to work together, and it was a

super easy ACS. I've since been talking

with the Linear team about how OpenAI

and Perplexity switched to Linear. And a

big reason for these companies to move

was how Linear enables velocity in their

product workflows. I'll actually link

the OpenAI story in the show notes below

because it's such an interesting read.

And yeah, I guess it goes back to a

thing that Google understood very early

on that when you focus and prioritize

speed in terms of how you operate, every

piece of your stack needs to support

that.

>> Totally. I'm going to be spending more

time with the Lunar team over the coming

months and I'm excited to share more

about the product and the story behind

the company. If you're curious to get a

feel for the product yourself, head over

to linear.app/pragmatic.

And then outside of just infrastructure,

like Google has so many other

custom systems. I I'll just name a few

cuz I I think like it's we could take

forever in going into them, but instead

of instead of GitHub, you know, for

source control, they they use Piper,

something called Piper. That's their

version control system. instead of pull

requests they they have this thing

called DL change list uh for their code

review tools called critique uh and it's

integrated with so many other tools that

they have a lot of AI function now built

into it it's it's a little bit like

GitHub's poll request review uh code

search has been a very kind of famous

tool that that inspires source graph uh

so you can you can search all of

Google's repositories and again they

they they do have a monor repo but they

have incredible amounts of of code and

it it's it's rapid. It's again it's from

a search company you wouldn't expect

anything less but apparently for a long

time when I talk with source graph

founders they were saying that code

search is was they had parts that were

better than source graph's own offering

I think now source graph is is catching

up but I still remember when I first

used source graph at Uber and it was

just so fast and I was like wow this is

so so cool to use but apparently that

that's the norm at Google and most

companies never had this until you know

maybe maybe they tried to build it for

themselves but it it wouldn't be worth

it building for for your own. Yeah. And

a lot of that actually comes from the

fact that they have this monor repo. So

the monor repo, they talked about it

publicly first in like 2015. They

started publishing numbers on it. Back

in 2015, there were already a billion

files in the monor repo. Two billion

lines of source code. It was 86

terabytes of content with 40,000 commits

every single day. It's interesting

because one of the reasons why they were

able to build the monor repo and operate

it the way they did was also because

they built it on the Google

infrastructure that they already have.

So the data centers and networking they

built out their um no build tool blaze

>> blaze which which they open source a

thing called basil which is similar

enough which is also really really fast

and really good.

>> Yeah. And it's you know this distributed

build system that yeah it's kind of core

of how like it's core of how they build

u it's very distributed very quickly. It

enables the monor repo in in the

ridiculous scale it's at, but it's also

deeply ingrained into how they do the

development itself, which is very in the

cloud actually. like most Googlers will

not have code locally on their machines

and kind of haven't uh ever it's kind of

a system uh called clients in the cloud

or sitsy uh which is the way they

they're programming which is yeah like

not on device but you know connect to

clients in the cloud these days it seems

like they they mostly do that through a

tool called cider which is actually a a

fork of VS Code

>> well now now it is right. It used to not

be

>> it used Yeah, it used to be something

else.

>> It used to be a web- based tool.

>> Yeah, I I I used it a little bit when I

was interning there and uh I think like

back then it felt kind of niche, but

then I think that's uh changed a lot. I

guess partially since forking VS Code,

I'm I bet it's it's looking much nicer

than it did when I was there.

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

So, yeah. again like because everything

is custom everything is also so

connected. So like cider is deeply

integrated into critique that they use

for code reviews which is deeply

integrated to their CI tap uh test

automation

uh program. They have tools like try

quarter which runs tests static analysis

all that stuff. They actually speaking

of rapid they actually have uh their

release automation tool is called rapid

or one of them rather code search is

integrated into all of that as well and

obviously code search is you know like

they had to build that out because the

monor repo was so huge

>> speaking of like like working together

or how they work like you know when you

think of Google's like what they use for

project management you know their kind

of version of grs linear they have

buganized

again a custom tool and they have this

tool called task flow which is a UI on

top of buganizer for boards cambban and

other kind of management tooling and

then they have guts which is Google

universal ticketing system it's was more

for for tech related tech support when

you open like a ticket you know you can

think of it like zenesk or like juro

tickets or or or just any ticketing

system but it's so interesting how they

even built that for themselves as well

>> but it's also it makes sense because I I

guess when you have the infrastructure

so unique it's like well you need to

implement this so where does that goes

come in and actually I think buganizer

in particular is also probably the

integration with cider and critique and

but like because everything is so custom

everything is like made for each other

as well. So using buganizer, you know,

you can report but also like fix do

small fixes like immediately in

the same environment that you're already

in because it's it's using the same

infrastructure.

>> Yeah. Now, one interesting thing about

Google that I I hear is this kind of

tech island. I I I think longtime Google

engineer or executive Ursera might have

said this. Google is is a tech island

like there's the rest of the world which

is using you know pretty standardized

things like most startups will be using

like you know like a AWS tooling or for

containers it'll be kubernetes or for

front-end frameworks with like react or

uh and and like for database it'll be

postgress or or something that is out

there but for Google everything is uh

separate and there was this recognition

even inside Google that this could be a

problem that they're so unique that they

cannot take advantage of other open-

source projects for example developing

but but also it's it's a very expensive

to on board it's just for new joiners

you know they have to throw away every

knowledge and at some point it might

also be maybe just not as tempting to go

work at Google if you know that whatever

you use there it's not going to be

useful for you know your your next job

but I I don't think this has changed I

think Google is like nah you know like

they probably talked a little bit about

it but and maybe it cannot even change

that much because it it didn't start

because Google it didn't feel doesn't

feel to me that it started because

Google said like no we need to do

something different.

>> Yeah. I think it's more like like we've

been talking about like they kind of had

to do something different from the

get-go. And I think when you end up in a

situation where basically you've

invented your entire own kind of

internet or like way of communicating

across computers like from the ground up

and you build out stuff on top of that

like yeah I I don't know even know if

it's possible for them to move over and

that's actually so when they started GCP

the Google cloud platform you know uh a

lot of that is what they refer to as

external izing. So they're

externalizing. They're not open sourcing

because it's still like they're on their

own tech stack, but they are

externalizing. So making offers that,

you know, can be used by other

companies. So Kubernetes is the

externalized version of Borg and it's

not the same, but it's, you know,

heavily inspired by it. Like slightly

different architecture, slightly

different feature set because it's it

doesn't have to cater to to just Google.

And the same for you know big table

spanner

yeah basically everything in the in the

Google cloud platform and act actually

also to mention gRPC gRPC which is a way

of communicating across services that is

something that is also externalized uh

internally it's called stubby and that

is the way that they communicate across

services and it's yeah it's the

internalized

um gRPC

they use protobuff as like the messages

for how to communicate across services

and then gRPC is the way they do that.

>> Yeah. All all this internal tooling I I

think like for a feedback I I often hear

from people going to Google is how

they're just really surprised at how it

is. And of course people who've been

there for long enough they gotten used

to it when they go outside they're often

really kind of taken aback by how little

other companies have it. For example, if

you spend most of your career at Google

and move to any other other company,

like often Googlers will look for the

equivalent of like whatever Google tool

had at this company which might or might

not not not exist. But there was uh this

uh person neat code as his name is

Namadiv Singh who uh well he he creates

uh one of the most popular coding

solutions. He worked at Google for I

think about a year and he said he did a

video about the one of the worst things

about Google and he he said how it's too

many internal tools and what he said is

I'm quoting him. Google has this problem

that they have an internal tool for

literally everything. So and sometimes

all those internal tools don't have

massive teams supporting them. Sometimes

it's just one guy working on an internal

tool trying to get promoted that maybe

they get promoted and then they stop

maintaining that tool and now you're

used to forced to use it and then nobody

knows how to fix a bug. You have to go

and read the code and you have to fix it

yourselves and that's not fun. No one

enjoys that. And then he said I would

rather not have this internal tool in

the first place because at least I can

just solve the problem from scratch but

now that is there I need to use this

internal tool. So I think it can get out

of hand and sounds like a Google

sometimes gets out of hand and he was

specifically saying his problem is not

with the big tools like Borg that are

really wellmaintained really well

written but there's it's just

everywhere. So it's and because of this

uh as I understand you know Google has

so many migrations going on all the time

especially you know pro promotions come

into play which we're going to talk

about shortly but let me show you this

image when it comes to Google they there

there's this like two two things to

choose there's the the main thing that's

deprecated don't even think about it the

new thing that is under construction and

this is by by Manu uh Cornet who worked

there for I think 12 years and he was

saying that by the way this is true for

a lot of tech companies but especially

Google. So let's talk about how Google

works. Now the first thing I kind of

think about like when I you know people

think like oh what do you know about

Google even as engineers it's it's about

the perks right like they're they're

just so known for for the perks

especially if you visit a friend at

Google I mean it's the thing that stands

out right I think the the micro kitchens

>> yeah I mean the Google offices in

general are I mean I've been to other

big tech offices as well and like I mean

the the kind of playfulness and

quirkiness is definitely not unique to

Google, but it's also unique to Google.

Um,

>> it's unique to Google.

>> If if you have the chance to go visit a

Google office, especially one of the

bigger ones, do it. It's It's a fun

time.

>> Yeah, they people can bring in visitors.

You you get like free lunch or breakfast

or or whatever dinner probably as well.

And I mean, the decor is unique like you

know like I I've been to many offices,

right? Like obviously what worked at

Uber but went to Meta, Spotify,

etc. like and they all have like cool

decor at places, but Google is

everywhere. Like the thing that reminds

me the most of of Google is the old

Facebook office back in in Menlo Park

back when it was like still very very

like heavily invested. There was like

such cool cool things. That was the only

thing that came close and I'm pretty

sure they kind of modeled it partially

after Google to wanting to hire, you

know, like similar people. But yeah,

like like really unique decor every

office like I think in Amsterdam there's

a van in the middle of the of the office

which is a meeting room which apparently

people don't use because it's too hot

but it looks really cool and and that's

just many one of the many decors.

>> Yeah. And and those are very they're

quirky. They're location based. They're

kind of theme based. So yeah, the micro

kitchens, a micro kitchen is basically

like a space in the office where you can

get free snacks and coffee and tea and

and and just like often just like a a

nice little like chill break room where

you can socialize and hang out with

people. Yeah, there's just so much

personality to them. In in the Zurich

office, they have one with a one of

those like secret bookcase doors. So,

like you'll be in this micro kitchen

that looks like a a library basically

with these huge book uh bookcases and

one of them opens up to like a secret

room in the back. When I was in the

London office back in 2015, they had you

know the London phone boxes.

They had tons of those across the the

offices whereas like you you know you

can go in and like do a quick call or

like a oneperson meeting room. They had

uh London buses,

you know, just a London bus just in the

office that you could go in and hang out

in. They're really fun, very colorful. I

mean, Google has always been colorful

given that they choy chose like the bold

colors in the logo from early on. And

yeah, you can just you can tell like

those little caps with the propellers on

the Nler hats, which I did have, but it

broke and I have lost it somewhere. And

then like I think the perk the list of

perks is really long. I mean it keeps

changing per per location but there'll

be like you know from the usual kind of

in the US the 40k on matching which is

kind of a given but still generous from

like all sorts of allowances that you

can spend on like a lot of like

typically you can expense a bunch of

things the travel that that you can

travel usually don't need a budget. I

mean it's it's changing over time and

again this is what I mean by by

location. And then there used to be like

more historic perks that I don't I don't

think exists, but there used to be like

on-site massages where you can get like

like uh like you know like like mass

would come in and like you could just

get it in the office which was very

famous in the in the like 2000s or or so

to like the napping pots to some of

these things. But these keep changing.

But I think one thing that hasn't

changed is which is kind of like the

biggest perk of all is the compensation

package which is just like wow. like you

know there's this trrimodal model of of

like the the local companies that that

that compete locally and companies that

like try to pay the top of the local

market and companies that pay the top of

the regional market that's a top tier

Google is is a very top tier company

which means that they can pay anywhere

from two to four times the compensation

so the total compensation that other

similar companies would pay let's say

for a senior software engineer and like

what this means in terms of numbers is

in Silicon Alley uh of California, a

senior software engineer could make

around $4500,000

per year in total composation, which

means, and this is where like it gets

interesting, there's a base salary,

there's a stock that vests per year that

you can sell because it's liquid stock,

and then there's a cash bonus. And then

this will be something for a senior

software engineer in the US like 220,000

uh in in California base salary maybe

200,000 per year in stock and maybe

$35,000 in target bonus and these last

two they can change based on your

performance you could get more you could

get less but for for London this whole

total compensation package which is not

all salary so salary is only one part of

it it will be for senior software

engineer will be something like 200 to

250,000

pounds. In in Munich, uh it will be

somewhere to€190 to€ 220,000

and in in Turk it will be 300 to€330,000

which is like a big jump again

differences in taxes and areas and and

again for every other location in in

India and in in Sydney etc they will

just typically pay more than anyone can

offer. So typically the best paying

opportunities they will shoot a little

bit above and in the case that someone

pays more and Google really wants you,

they will sometimes shoot more and and

offer you more if they really want you.

In many ways, Google feels like this

amazing like you get everything. You get

to work on the largest scale things with

smart people, these amazing perks, and

you've been paid a bunch because a

company that does pay you pretty well,

not this well, but they pay you pretty

well is Amazon. They give you a very

respectable total compensation with

pretty good stock and cash and all that,

but then you get nothing. Like there

there's no perks. There's no nothing.

They're like, you know, you you want to

go out for a team dinner, pay for

yourself. Whereas at Google, like this

is not even a question. Like, you know,

like there will be team events and and

of course you're not going to pay for

it.

>> No, exactly. Like they they take good

care of their engineers and have done

again like from day one basically. And

and speaking of good care, so like one

thing that really kind of struck me as

really really unique is on call almost

every company is like let's be real like

engineers are paid really well at at

Google and similarly well at Amazon,

Meta, Microsoft at all the other

companies you are expected to when

you're on a team you share the on call

on your team. Now, in the case of

Google, on call is not nearly as

enforced or as stressful as at every

other company. At every other company,

you join like a six person team. You'll

probably have a rotation of of every six

weeks. Uh it might be a bad rotation. It

might be a good rotation. If it's a bad

rotation, well, I mean, you know, your

nights will be disrupted. Sorry. Until

your team gets this stuff together. So,

Google has a a few things. First of all,

they have an SRE organization which

works really hard to make on call less

painful for teams. They build tooling

that helps with this. Uh they monitor

the the load of the teams and they have

this thing called toil SLOs's toil

service level objectives where they want

to make sure that that teams whose

SLOs's are are breached, they stop

production work and fix the underlying

issues. So they basically provide time

for teams to become healthy again and

you know not get woken up all the time

at night by systems that break which

which happens a lot actually at some of

these other places that again have high

expectations similar to Google. And then

another interesting thing that Google

has this thing called on call tiers. So

at most companies even at big tech every

team just makes sure their systems are

up. Google assigns tiers to their

services. Uh tier one means that a page

that comes it needs to be acknowledged

in 5 minutes, tier 2 in 30 minutes and

tier three is best effort. So you can

imagine tier three is internal services,

tier one is important services, but then

they pay for the on call accordingly. So

they say if your if your team owns a

tier one service and you're on call, you

get 66% of your normal salary. like if

if you would have been on call for the

whole month which you're not going to be

on call you you can either choose

vacation or pay like 40 minutes of your

time for every hour. So anyway they they

do a bunch of composite they pay really

well for being on call and then they

limit time spent on call at the same

time. You cannot go for on call for more

than two weeks per quarter which is

going to less than other companies. So

it just like it it like mind-b blown

like Google all does all these things.

They pay engineers like best in the

industry or close to best in the

industry. They give all these perks and

then they relieve them from on call. So

it's almost like it's it's it's amazing

to to be and then not just relieve but

they actively help and mandate teams to

make their systems better. So this is

like paradise for an engineer. Like so

far like you would almost think that

Google's paying us to like advertise

them, but they're they're not.

>> No, they make it easy. But I guess

>> where's the catch? I mean, given what

we've been talking about though in terms

of like Google being this tech island, I

guess like this is the positive side of

it because like you can't actually fix

everything yourself because everything

is custom. So like you can't put the

expectation that everyone can go and fix

their Kubernetes pots or whatever. Like

this is kind of the trade-off. So it's

like you get this because you work with

the unique tech stack that is not

transferable outside of Google

>> and because they invested this much in

it. Exactly. If you work at Google, uh

you'll likely be

an SWE, the software engineer. That's

the big role that Google has. Um but

Google also has tons of like there are a

lot of other types of roles and niche

roles as well. Like S is obviously one

of the bigger niche ones run that they

have. Uh but there's also quite a lot of

other smaller ladders that and and roles

that they have depending on you know

like some roles are more prevalent in

some parts of the organization and with

some products or product areas. So

you'll have stuff like Debrell, they

have UX engineers which are kind of like

more front-end engineers working more

with design implementation and that that

there's like a scale there that goes

from more like front-end engineer to

prototyper which is a separate career

ladder. They have research scientists,

they have within the sur there's also

like more specific type of roles and

working with the infrastructure.

They have tons of other roles, but the

big one and the most on paper apparently

all of these different ladders are

supposed to have, you know, like same

compensation, same prestige, same

everything. But it seems like in reality

the SW role is good, kind of a bit like

higher class essentially. Uh, and part

of that is because when you're in SW,

like because it's kind of the default

go-to role, that's the one where you

have the most internal mobility, you can

work on like any team, you like it's

much easier to like move somewhere else

because that's the default that

engineering managers will look for and

hire for. And speaking of managers, they

have engineering managers that are, you

know, EM, they take care of teams.

that's their primary focus is making

sure that the team is healthy. uh they

also have two roles that is the tech

lead role and then the tech lead

management role

>> tech lead manager

>> which is unique to Google where uh so

it's basically you can think of them as

like uh a spectrum where you have EM on

one side where it's you know the person

like you know they have direct reports

they take care of the team they do all

the EM things and then on the other side

they you have an a IC individual

contributor who's a tech lead uh so tech

leads are in charge of uh you know

overall architecture tech aspects of

projects of products they'll make sure

that you know like tech decisions get

made they have the top say they get

appointed by EM but then there's this

slide in scale in between where you can

have tech leads who also have direct

reports and here we talk about tech lead

managers

which is this unique to Google

>> yeah but so my understanding of this

role because We introduced it at Uber

and it was influenced by Google. I think

we had a Google uh SVP come over and

then it was introduced. My understanding

of the the idea of this role originally

was well first let's talk about levels

and then well we we'll get to why this

role is kind of important. So the the

levels start from L3

which is L3 is the entry level software

engineer. L4 is mid-level software

engineer and Google has different names

for it, but that's kind of what it is.

L5 is senior software engineer, L6 is

staff. L7 senior staff and L8 principal.

Uh L9 distinguished and L10 partner.

>> So like or fellow, yes,

>> Google fellow.

>> Google calls it fellow. Uh I think

Microsoft calls it partner. And around

like at the senior software engineer at

the staff engineer level at L6 another

path starts which is the manager path

which is

>> which is where injury manager u there's

sometimes an L5 injury manager that's

more of an entry level but I think

they'll use it internally and then L L7

will be uh senior engine manager uh

which is this the same as the kind of

this the senior staff uh L8 is director

which is now principal engineer so the

same level the same compensation and it

goes to L9 senior director, L10 VP and

then there's an L11 on the manager track

uh for senior VP which does not exist on

on the IC track. So at Google, we have

this level from like I see L3 to L10 and

then manager from L6 to L11. And at

every level, it starts to become harder

and harder to to go go up the path. And

around like L6, people need to decide

are they going to be on the IC ladder,

try to make their way to L7, L8, and so

on, or switch to manager ladder. But at

some point, you kind of like get stuck,

but maybe not necessarily an

uncomfortable way. So like when people

get to like L7 or L8, you know, you're

not really going to go higher. And at

Google there there are are people with

really long tenurs like you know 10

years 20 years even more and they're

very comfortable there. And so you have

these individual contributors who are

really good at their work. They're

they're the tech lead de facto and they

could manage their team that small team

like and typically these are small

projects but they don't really want to

be on the manager ladder cuz they want

to stay IC's and they don't really want

to be promoted. So this tech lead

manager role is kind of created for

those people. And this is really

important context because some other

companies took over this uh role. So the

duber for example and what they found is

people who went into this thought that

they would be promoted to the next

level. But it's really hard to be

promoted when you're kind of expected to

both be an as an engineer you're not

doing as much work as before a little

bit less and as a manager you're

managing a team. So people can get

frustrated but for Google it worked as I

understand. So the technic managers are

typically they're they're not like

looking to go to that next level. It's

just more recognizing that hey, they're

doing both of these pieces of work. When

you're judging their performance, don't

compare an L8 tech lead manager to an L8

IC who will be pushing out a lot more

code.

>> Yeah. My understanding also is that this

role is especially

like you kind of mentioned as well like

in like small teams uh usually like more

of like the research type things of like

hey let's try to build something out and

see if it works where the team also

wants to like move a bit more quickly

and it might not be around forever. So

it doesn't necessarily make sense to

both have an EM and a tech lead because

it's more kind of grassroots than that.

And so then you'll also have these

people who will sometimes manage the

whole team but like but but it's like

you know a couple people rather than you

know a full established team that has

what like way more cadence and way more

kind of em type work there.

>> Yeah. And I think there's a limit of

like four or five maximum reports. So,

and and usually it's stable teams.

Usually, it's not ones. And also, if if

you're on a team of like four or five

people, there's going to be not as many

promotions and and so on. And also, fun

fact about the levels. So, entry- level

software engineers start at L3. Those

are new grads. And by the way, the whole

L thing, as I understand it, it's to do

their there might be L1 and L2 within

Google. It's just not for engineering

because they're also salary levels uh as

well. uh PhDs uh if you have a PhD you

you start at L4 minimum. So there's one

uh some other companies do the same

thing by the way who hire PhD students

but that was an interesting thing for

me. Uh, no. Uh, at Uber when I was

hiring interns, we hired a PhD and then

HR told me that that person needs to be

at the next level. And I was like, okay,

sure. Like, fine. But I I guess it's

it's one of the reasons you see like,

okay, having a PhD pays off. But again,

we asked the same questions from the

PhDs as we did from from the new grat.

So, they still needed to algorithm the

coding interviews. So, there you go.

Yeah, I do think the like L1 and L2

might be used in like very rare

occasions for like kind of interns

straight out of university or like they

find someone who uh didn't actually go

to university but like very very entry

level. Uh but like obviously the there's

expectations also on like all the low L

levels which is you know across the comp

uh our industry that if you're in a very

low L like you're supposed to kind of

progress to a higher level within like X

years.

>> Well yeah so so this used to be the case

but it's kind of changed. So like Google

has this had this thing well they still

have it called terminal level. terminal

level used to be L5 senior and I'm not

sure if this was Google but there used

to be an expectation that as you said in

certain years you would get from L3 to

L5 later Uber copied this and at Uber we

had uh we had five years of expectation

to go from L3 to L5 and in the case of

Google and and then if it didn't happen

uh there will be questions asked and

some pressure and eventually they might

actually just fire the person saying hey

like why did they not to what we

expected and once you reach a terminal

level there's no pressure and what has

happened at Google is I they've changed

the terminal level to L4 because over

time it's now to get promoted to L5 you

need to like ship a kind of a pro a

project that shows that you're ready for

senior and the bigger the company is

sometimes there's not enough projects

like that especially in smaller offices

so it's now like you just need to get to

L4 and I'm not sure there's a limit even

but Google has become a lot bigger than

before and this happens with every

company as as they grow.

>> But uh I think this leads into nicely

into the performance reviews and

promotions at Google. The performance

process it used to be called Perf and it

used to be kind of you know one of those

things that is like people famously

complain about. But they actually did a

big rehaul in I think 2022 where they

moved to a new system called Grad, which

stands for Google

review and development.

>> If you ever worked at a a big tech

company, it's a pretty similar

performance review process. People will

need to fill in, as I understand, their

their self- reviews. You get peer

reviews. Managers look at it. They give

you feedback. And there's a timeline for

this. So like this is Google runs once a

year. It starts in November and the

bonus numbers will be managers look

through it in in December. There's bonus

meetings behind the scenes. In January,

they get finalized and then they get

paid out in March. And so basically like

for the input that you put in November

and December, you're going to get like a

final like output in February and you

will get the bonuses in March and either

you'll be happy or you'll be unhappy.

>> Yeah. And I I think one of the

differences like I think the Perf

process was like way more heavy on you

as an individual doing all the heavy

lifting uh where you had to spend

yourself a lot of time uh you know

putting together reports and like paper

trails essentially about all the things

that you do. And with grad supposedly

it's been pushed more to the managers I

believe which if you have a good manager

is probably an amazing thing because you

know you'll have a lot less work. Uh but

if you end up with a Yeah. like it it'll

depend on your manager it seems like.

>> Yeah. And so Google used to be known and

I think they still kind of are. They're

trying to be pretty fair in in how they

do performance reviews and and

promotions and and we'll see that with

with with promotions. I mean, the

manager still has as has a big say, but

they're trying to focus on uh outcomes,

outputs, etc. Like they're they're doing

more there there's a lot of training for

managers going on antibbias training all

of these things and the the process is

really well documented and it is more

heavyweight than most big tech companies

and people take it seriously. Well, I

mean, after until a few years, and I'm

sure after a few like after like, you

know, 5 10 years, people are just

probably like, "All right, here we go

again, especially if you're not wanting

to move up and and there are performance

scores or or feedback scores uh in terms

of like, you know, if if you're meeting

or if you're exceeding if if you're

above. But there is this interesting

thing called the Perf score resetting

when you change teams." So, this is

>> Oh, yeah. As I understand, this is kind

of a open secret that if you change

teams

during a perf season, so basically like

right after the perf season has on your

first perf season on your team, you will

always get meats meets expectations no

matter if you're how much you're

overdoing it. I mean, if you're doing

terrible work, you might get below, but

you're you're typically not going to do

terrible work, but you will not get

exceeds no matter how hard you work. So

this is leading to like some pretty

strategic considerations on when to

change teams because getting an exceeds

rating means you're going to get higher

bonus but you know that when you're

changing teams it's going to be meets

you're going to get your target bonus no

matter what.

>> It was actually with Perf that uh that

they used to use. So yeah meets

expectations exceeds expectations and

then like very much exceeds expectations

basically. But actually with grad

they've updated the kind of terminology.

So now it mean they map to uh impact

instead. Uh so you have uh not enough

impact, moderate impact, significant

impact which are like the that's the

high end of like meets expectations,

exceeds expectations and then there's

also outstanding impact which like maybe

8% of people get is what I heard. So

like you're doing amazing essentially.

Uh there's also transformational impact

which is like the top top which is yeah

you're going to ship a really big deal

project in order to get transformational

impact.

>> Yeah. And usually behind the scenes

these will be tied to budgets meaning

that at the director level of like let's

say a group of like a 100 L5s only three

would have I'm just saying something. It

might be five but a certain number can

get transformational impact. And so on

the calibration meeting where all the

managers get together and they they all

you know submit their ratings there will

be a calibration where it needs to not

fit the curve but it needs to fit the

buckets. So there there often times

needs to be certain number on the lowest

buckets and maximum minimum certain

number in the lower the lowest buckets

of the you know the the ones who do do

not meet the the impact and only a

certain number in the in the top buckets

and it depends on how much these are

enforced. uh it depends on the

performances and depends on the

organization but there's always going to

be a distribution a force because uh

what most companies learn including

Google is if they don't force it a lot

of managers will just like shy away from

having the hard conversations or reward

either rewarding their their their their

best performers as they should be or

being a bit more critical with the

people who are not pulling their weight

as much and this is irrespective of this

happens at every large company after a

while and even when it doesn't for a few

years it can start happening after a few

years like we've seen a lot of companies

have like after relaxed uh performance

management in 2021 2022 like the when

the job market was really hot they there

was a time where they gave everyone

exceeds I think Google did that once as

well to fight uh attrition and now it's

back to the usual of like there there is

this bucketing and we have a longer deep

dive on how calibrations work behind the

scenes from a manager's point of you

which is actually really interesting

slash eye opening but as an engineer not

much you can do beyond you know document

your impact have have a have a good

relationship with your manager and hope

that that manager stands up for the

people on their team.

>> Yeah and I guess I mean there is some

aspects of like you know the type of you

know work that you do and kind of extra

extracurricular activities if you will

that will feed into and like look good

on these performance reviews. Uh, and

Google does have a lot of opportunities

to do that kind of stuff. So, like

there's lots of mentorship programs and

not tech support but like uh helping out

with onboarding, helping out with coming

up with what they called code labs. Um

so because again because Google is so

unique like there has to be a lot of

onboarding and kind of knowledge

spreading internally to on to teach

people how to work at Google

essentially. So that opens up for a lot

of opportunities for people to help out

with that kind of stuff. If you like

working with that kind of stuff, like

kind of tech writing and like tech

learning, uh, Google has a lot of

opportunities for that.

>> Yeah, probably a lot more than than most

other companies. It sounds like they

actually appreciate it as well. So I

mean obviously you need to do like do do

good work like don't write sloppy code

and like it's full of bugs all the time

and then do all the extracurricular

things but when you want to show that

you're ready especially I guess this is

true for especially the the levels of

like we're talking L3 L4 L5 above that I

mean it's kind of a given that you do

all these things on the side in fact

they might hold it against you if you're

like an L6 and you're not mentoring

anyone they'll be like or or you're not

helping other things. So it's not going

to help you from there because it's kind

of baseline from there on.

>> Yeah. There there's actually that

reminds me that one of the things that

is built into the critique system and

their uh code review process is

something called readability.

Uh which is essentially again it's a

monor repo so like anyone can see and

review anyone's code. Uh but the code

review process is built up. So like

every every change list every CL uh

needs to get reviewed by three different

not it can be the same person but like

three different roles. One of them is uh

the code owner and like it has to be

another engineer like you can't review

your own code but then one person also

is just someone who needs to have

readability in the language you're

working in. And so readability there is

someone who knows about you know all the

best practices and conventions and

styles and all that kind of stuff. And

so the they have this way of earning

readability in a language that you know

has to like there's a whole process for

it.

>> Yeah. We we we we talked about it with

with Arena on the podcast. She was ex

Google. So yeah, she also went you have

a process is pretty straightforward. You

need to like shadow I think be signed

off that kind of stuff.

>> Yeah. Exactly. and like do a certain

number of things and then eventually

you'll get readability. It's easier to

get these types of mentorship kind of

mentorship opportunities through

readability across the company without

necessarily like moving teams or

>> like knowing people like you have to

know the person people in that org in

order to like

>> that's a good trick to know about. Yeah,

you can just like focus on readability

like just look at open open CLS across

the

>> It's so so unique to Google, isn't it?

Like I I don't know any other company

that does this like at at Ruber and

other large companies like Yeah. like

you do mandate code reviews of like a

code owner but nothing to do with

readability.

>> Yeah. And I think it could be that

that's probably an artifact of the monor

repo again as well. The monorreo doesn't

necessarily like they still do a lot of

like micros service architecture for

like within the monorreo like it's not

necessarily like either it's monolithic

or it's microservices even if they do

have you know microservices and like the

tech in the teams or different products

will be you know separate maybe have

different architecture maybe like

software patterns

like compared across But like the again

like the tech is the same, the

readability is the same. So you could

almost think of it I think as like

several different companies that just

happen to have the exact same

engineering culture rather than, you

know, trying to compare this type of

stuff with how they do stuff at maybe

Meta or Amazon. It's more one company,

one tech stack. So it's like then you're

kind of more stuck in your silo so to

say versus here where you know someone

with reliability can help someone

working on a completely different thing.

>> It's it's an interesting approach. So uh

outside of performance reviews the other

one is promotions. That's and promotions

are different at Google because there is

this thing called a promotion committee.

So, my understanding is that Google has

been really big about trying to not be

biased in promotions, the way promotions

work at most companies is when you're up

for promotion, the group of your manager

and their your manager's peers all get

together and they're like, "All right,

is you know, Johnny ready for a

promotion?" And they all kind of talk

about why, you know, and your manager

says why they think they are. And then

their peers say like, "Yeah, we agree or

we don't or what about Jane?" And then

and so on. And so this group who's kind

of, you know, like kind of know your

work, they all like decide collectively

in the end or they get feedback why

you're ready, why you're not ready. And

the good thing about this is that they

all know the context of your work

roughly. The bad thing is it can be

pretty biased or or it might be pretty

ignorant. Like there might be some

managers who would veto you cuz like

well I didn't hear about this person or

I had this one bad incident one of my

teammates said I don't know how they got

into a fight with you etc. So there can

be some biases there and what Google has

done for a long time is they they said

all right let's just make this whole

process unbiased let's have a promotion

committee where no one knows you like

it's it's not your managers but it's

like this group of like senior or staff

plus engineers and other engineering

managers at a different part of the org

and they just get a written packet a

little bit like their hiring committee

that we're going to talk about they

decide your promotion based on that and

what this means they don't know anything

about you they don't know who you are I

mean they will understand the context

But they haven't to work with you. They

have no bias for or against you. And so

the decision should be a lot more like

objective, right? So they will decide on

your impact on they will look at the

framework that's that's there and and

the impact because again with the

manager uh group there's the other risk

that if you have a really strong manager

who's really influential, they're just

going to push everyone through. And then

you'll have some teams where people are

promoted who are clearly not ready or

not doing as great work but they have a

strong manager or or good man well good

manager from their perspective. There is

a very interesting kind of downside of

this promotion committee. Uh there's a

famous article called why I quit Google

to work for myself by Michael Lynch who

was an L4 software engineer at Google

for four years. uh and he was stuck on

that level for four straight years

trying to get promoted for years one

after the other and he wrote this blog

post and he he failed every single time.

So he started to understand how the

system works and by the time he

understood it it was a bit too late.

first promotion uh he uh you know

submitted his he was doing a bunch of

maintenance work h and then the

promotion committee said that he had not

proved that he could handle technical

complexity and they didn't see the

impact again Google's big on impact so

they said to be promoted to L5 senior he

needs to have an impact on Google then

he went back uh and then he was like

okay I need to have a project that can

have that impact so he now looked for a

project to get to get to promotion and

he got that project but then the project

got cancelled and then the the next year

I think he moved teams or he had to move

teams because his team got cancelled and

so so he had this like series of bad

lucks where and then and and then in in

I think year four he wrote in this

article I'm quoting him my quality bar

of for code drop from will we be able to

main this this thing for the next 5

years to can this last until I'm

promoted I didn't file or fix any bugs

unless they risk my project launched. I

wriggled out of all responsibilities for

maintenance work. I stopped volunteer

for campus recruiting events. I went

from conducting one or two interviews

per week to zero because he just really

wanted to get that freaking promotion.

And and in the end, he quit Google. But

this whole story showed how it's super

easy to fall into Google into the

promotion trap, which is I need this

project to get me promoted and that's

it. And he actually explained and in the

end I think he said like what am I doing

here? Like why am I doing this? and he's

a smart a smart guy. He built a really

good business afterwards. But it felt to

me he just got unlucky of of of how his

teams changed. But also this is where we

should talk a little bit about

promotion-driven development that is

very real inside Google because all the

incentives are there for it. And and you

know there's there's this joke uh that

goes around uh of why Google has so many

chat products. I think you know they had

Google like they had Google wave

ghat uh and and they keep changing the

names and also the product also pay

Google's payments promotion it was

Google wallet then G pay then Google pay

then it's now Google wallet again but

you see sometimes a lot of things where

Google has a product like with their

chat product which is still not they

don't have a Slack competitor like they

have Google chat or maybe called Google

Workspace I'm never sure they have

certain products that are pretty niche

and they're they're they're launching

and they get a bunch of attention and

press from Google and they're often on

just one platform. For example, they had

a chat product just for Android. And if

you look closer, the incentives are that

Google really incentivizes you can get

promoted for having a successful launch

for showing traction. A lot of projects

at Google, you know, like people start a

new project, they get traction, they get

promoted, and there's this thing where

if you move teams, your performance

scores are reset. You will definitely

meet a meets. So if you hit a bit of an

obstacle, the launch goes up, but now it

kind of flatlines. I mean, you can stay

on that team and get a meat's review, or

you could move to a new team and get a

meets review anyway. So often teams will

move to a new team and either start a

new project or or join in. There's just

not much incentive to stick around on a

project that's not doing great for the

for even a year to kind of hang it out

and get it back to growth. There's just

more incentive to start a new one

because you're not going to get promoted

for maintenance. That's that's that's

the gist of it. my my understanding and

and you know this goes back to Google

has this thing called killed by Google a

website that collects these like 300ish

Google products that have been launched

but they have been killed

>> yeah I mean technically not run by

Google but uh

>> oh it's not it's not run by Google it's

just external external that one is not a

Google project but

>> that would be funny if someone internal

Google is like here's all the things

we're bad at

>> no but it's interesting because on one

end it's Google is very heavily

criticized because they are the biggest

tech company which seemingly wastefully

launched which is then kills projects

publicly. But at the same point, I I I

still wonder if this is kind of part of

how Google operates where they they do

want to see people launching stuff. And

again cuz cuz look at it like yes we can

make fun of how Google like you know

like discontinues Stadia a gaming

console or or or Google reader but show

me another tech company that that has as

capable of LLMs as Google has big tech

their own models or self-driving cars in

San Francisco and may maybe you cannot

do one thing without the other. I don't

know

>> the way I think of it is that Google has

had like a really good culture of just

creativity and innovation and just

allowing people to try things out and

see what happens. uh like famously the

20% time uh which it's not really around

the same way it used to be but there was

this yeah again kind of open secret that

any Googler could spend up to 20% of

their time on some other project like

some idea they have a pet project a lot

of I think the the internal tools you

talked about earlier comes from that

kind of things where you just have the

ability to like oh I I It would be nice

to have something like this and you

build it for yourself and because it's

Google it's automatically available for

everyone and then all of a sudden you

have built a tool that people use and

then you move team and now no one's

maintaining it. And so I think part of

it is that that Google

allows you to be creative and innovative

and try new things and just like yeah

launch see what happens. But I think

another part of it as well is I think of

Google as being a very kind of

engineering first and engineering driven

organization.

If you compare that to say Apple which

is much more kind of like the design and

user experience driven and if you have

it versus say a meta or something like

that they're much more like product

driven. It's like if you're a product

person that's how you drive. I I think

at Google it seems to just be kind of

just engineering first and maybe one of

the

main ones that do that where it's it's

like it's the engineers or like you have

much more ability to decide what to work

on and like choose the path for yourself

if you're an engineer. like it's much

easier to get product traction and

essentially it's because if you're an

engineer you can also build it whereas

like if you're a a product person at

Google you'd have to you know convince

engineers and like do this whole thing

of like getting headc counts and stuff

whereas if you're an engineer like you

can just either do it yourself because

you have so much available to you again

through code search and the mon repo

like you don't have to start from

scratch every time.

>> And then one more interesting thing of

how Google works and I don't know if

this is like engineering driven but

maybe it's connected their their their

design docs culture is just really

really kind of famous to to the point of

apparently whenever you start a project

you you're expected to write a design

doc which is a Google doc which has like

certain sections and you know these are

kind of like loosely handled but it's

things like context and scope goals non-

goals an overview you might have your

architecture diagrams how it impacts

other systems, the structure of your

changes, maybe roll out plans, life

cycle, and many alternatives considered.

Some other companies have actually

started to to use similar approaches or

maybe just naturally spread. It's often

called RFC, request for comment. But at

Google, so every like project will be

rejected, even smaller ones if they

don't have a design dock. And it's

expected that you write this and you

send it around. You gather comments and

then you start coding which is really

interesting because you would think that

as an engineering driven culture one

things that us engineers love to do is

code and what we don't like to do is

write docs and yet Google settled on

again it is very engineering driven. Uh

why why do you think this might be? They

just realize that consensus is is

important because they're they're also

big right? They're the biggest probably

the biggest like engineer culture of

this quality.

>> Yeah. Yeah, I mean I think uh I mean it

might be something like you know they

introduced the 20% time or like they

just had a maybe even before that was

formalized like there was a culture of

people just trying things out and maybe

realizing that like oh we're like

redoing the same things or building

something that like oh had you talked

with any other people you had realized

that like that was either like not

needed or not a good idea or like it has

use case of one like you're building

something for yourself. So that could be

a part of it. But I also think in terms

of just like the Google culture itself

and googliness, which we haven't touched

on, but googliness is basically this

idea of like people who fit at Google

should be googly. And it's it's kind of

a vibe thing. Um, and part of being

googly is that like it's it's less of

this whole like a bit less of the

rockstar mentality that you know you're

the rockstar engineer who just like goes

off and does his own thing. It's very

much more like collaborative teamwork,

team spirit, enable everyone to do great

things. And so it pro like I would

assume it comes from that as well like

part of being able to uh keep the

googliness is to just be very open and

there's actually like we've mentioned

the sur book there's also an SV book um

software engineering at Google the

office

>> yeah I have I have it here on my desk

software engineering at Google it's also

it's available for free online uh Google

made it available like it's officially

free it's not like one of these

pirated books. But yeah, it's it's

pretty big.

>> Yeah. and they they write about this

like that book in general like goes

through like it does talk about a fair

amount of the tools that we talked about

like the the Piper and the monor repo

and the critique and all that stuff but

it also has you know a big section of

like you know why are we doing this in

the first place and there are some

beliefs that you know software

engineering is a team effort and u like

these are the type of people that you

should have in a group in order to do

software engineering well

>> one thing that Google really gets And we

didn't talk about it so far, but they

really get how software teams work.

They've run both a lot of experiments.

You know, they famously run an

experiment where they removed all

managers and they figured out what's

going to happen. They didn't know like

they they thought that teams would maybe

work better without managers, just

engineers, and turns out they didn't.

And then they went back and they tried

to figure out what do good managers do,

what should they be technical and and

like they've done a lot of research and

they have published uh a lot of these

things but you know at a lot of

companies I think as a developer you get

really frustrated for because it's it's

often times the business you know CEO or

someone pushing developers like do this

or that and they're asking why why is it

taking so slow? Why are you guys I don't

know like lazy or or do more with less

this kind of stuff. But things like

making a case that it would be nice to

have a platform team internally. It's

almost impossible at a lot of companies.

But at Google there's like platform

teams left and right which means you

know that they just build an internal

product or internal platform that the

other product teams use and most

companies like a nontechnical CEO would

not understand like why would I need to

do this like we just we have our

engineers like they can I don't know use

open source tools or whatever and even

when you use open source tools or for

your CI/CD system you still need someone

to maintain it at Google like it's

probably one of the best places where

yeah everyone gets it because they've

been doing this that the people up there

are software engineers. The founders are

are I mean they were PhD students but

they are software engineers even though

the founders are are are no longer uh

there but everyone all the way to the

top understands and breathes software

and I think they understand that the

software is a series of tradeoffs. It is

it's not just code. So even when it

comes to like AI, uh they're they're not

going to be like falling for what

everyone else is saying that I don't

know like AI will replace software

engineers. Like if if it would Google

would have zero of them, but Google

knows the value of software engineers.

>> Yeah.

>> And the limitation of them.

>> Yeah. Uh exactly. But I think that also

like to tie it back to killed by Google

like like that's probably why like you

know you have a lot of freedom to try

things out uh and then you build

products that might not make sense and

like if you had a much more kind of

product person influenced organization

or design person influenced organization

yeah they probably wouldn't have the

graveyard of killed by Google like Maybe

there would be like would probably be

way smaller and they would probably not

be as vocal about it like they wouldn't

make all of these sweeping announcements

at Google IO every year to only have

that product u you know go bust a couple

months or years later but

but that's like that's the other side of

the coin.

>> Yeah. One interesting thing that comes

up with Google outside and but I want to

touch on this. It's not really software

engineering but it kind of impacts us

OKRs

objective key results. Now if you're if

if you're a software engineer you

probably like and you worked at a

midsize or larger company this probably

came up like what are your OKRs? What

are your teams OKRs? The objectives the

key results and the goals and apparently

Google made this super popular this uh

this framework right?

>> Yeah exactly. So technically they didn't

invent it. uh they were actually

introduced in the 70s at Intel which is

so long ago but there's this guy John

Door who uh was at Intel before he

joined Google kind of early and uh in 99

he introduced this idea of OKRs and they

fit really well with Google at the time

and it became a big part of and

ingrained in the culture of of how they

operated. method. So yeah like

objectives and key results. Objectives

is like you know a kind of more highle

goal of like this is what we want to

build and then the key results are

specific measurable things that you can

measure in order to know that you're

moving towards the goal. some examples

of when they introduced OKRs in the

beginning back in 99 like their first

objective was build a great search

engine and then they had they came up

with their key results serve at least 10

million queries every day achieve sub0.5

second response time for searches

improve accuracy of search results based

on user feedback and the last one hire

worldclass engineering team and you can

kind of tell that because they separated

out the goals from these very specific

measurable things. Everyone knows to be

on the same point and like okay so what

is what's the most important thing? What

what are we prioritizing? What do we

need in order to serve 10 million

queries? We need the data centers. We

need the network like we can't use

normal DNS. We need to invent our own

things etc etc. So, I I'm I'm going to

be honest like I'm always a little bit

like suspicious about OKRs and Google

like to me like because it it is uh the

book Measure What Matters was published

in 2018 and from there on it's really

blown up and I think everyone's like

using OKRs cuz it like there's this

narrative that OKRs make Google

successful. But I'm kind of thinking

like is this a little bit saying that I

I don't know like using Jira made

whatever company successful, SpaceX

successful. I'm not sure they've used

Jira, but like whatever ticketing system

they use, did that make them successful?

Cuz I'm like the smell that I have is I

have a sense Google would have been

successful whatever they use because you

know like it started with page rank.

They did something that everyone wanted.

And I I wonder if if OKRs is is

something that I mean it's it's probably

it works, but it it could have been

anything else cuz whenever I used OKRs

at least and you know we we we try to

use it like having a clear goal and and

a and a team that was focused on

building something was always way more

important than having whatever OKRs

because there's a usual criticism of

OKRs of like well if you make it a

target it's kind of like it's kind of

silly because now you're only optimizing

for that. Because I saw at Microsoft for

example when I worked in like 2000 like

2020 2010 or 2012 the organizations were

all focused on their goals and they only

cared about their metrics and it was

terrible. We couldn't do stuff that

Google did for example like my team we

we couldn't agree to add our codecs into

the new Internet Explorer called Edge

while Google Chrome had it bundled cuz

the two orcs had different goals and

they cared about download size and not

not what we cared about. So anyway, it's

good to know that Google uses them, but

I I'm still kind of like I I I wonder if

that really makes all that much of a

difference for them. I'm sure it helps,

but I think it's a bit overblown. Yeah,

I mean it might have helped in the early

days just like I can imagine like maybe

convincing stakeholders or like early

investors and each other maybe of like

okay what are the things that we need

and like at the end of the day OKRs is a

tool right like this is a way of framing

and communicating

priorities and what needs to happen with

each other. It's like if you use it in a

good way then you figure out all of like

oh actually we would need to do

something else or we need to do

something additionally. So I think if

you use it as a tool like you can use

tools in very bad ways and you can use

tools to great success. And I'm sure

Google has had plenty of OKRs that are

not even remotely close to uh what they

did you know in these early years. Um,

but like yeah, maybe it helped like

since they've been around since 99 like

probably they know like you know it's

helpful. Um, but yeah, I do think that

the tendency of like oh they use this so

therefore we should use it and then well

be Google is yeah that's not how it

works. Speaking of OKRs as as a tool for

communication,

u communication in general at Google is

is and at least has been very open and

very transparent. So historically, like

this has changed a little bit now. We'll

we'll get into this, but like culture is

shifting across the industry, including

Google in late years, but historically

it's been incredibly open and

transparent.

Um again like maybe it's like part of it

being the the monor repo and the fact

that everyone has access to everything

anyways but you know since pretty early

days uh Google used to have the or still

has them these weekly companywide town

hall all hands meeting check-in type

thing. It's called TGIF. So, thank

Google it's Friday or that was the uh

that was the original. Um and then like

with the engineering team being or the

company really because this is for the

company not just engineers uh it is

global so it's actually it's on Fridays

in one time zone but not in the other I

don't remember but so it's more like

TGIT now so think thank Google it's t

Thursday.

>> Yeah. But basically, uh, like it used to

be more like Sergey and Larry on stage

talking about stuff, doing open Q&As's.

You'd have different teams come in and

like present what they're working on or

what they've built. Um, and I think it's

it's one of those kind of cultural

cornerstones it seems where like I

remember when I was at um when I was

interning you know it it was on Fridays

and like there's there's the all hands

itself that's TGIT or TGIF but then you

know there would be an event at the

office where you know there would be

free food and drinks and sometimes some

like event like I remember there was a

Halloween one that had themed and like

they had decorated the um the cafeteria

and you'd just like have this weekly

chance to like go hang out with your

colleagues before going home from work

that like you'd learn all these things

from across a company.

>> Um and then

>> so it's a fun fun event, right? Like

it's worth showing up.

>> Exactly. It's a fun event, but it's tied

to one of like the kind of cornerstones

of communication across the company. And

then that you know it kind of trickles

down in a way because like Google

organization is very fragmented like

again because Google is basically many

different companies in one. So like

you'll have they're called product areas

like the big sort of completely separate

companies. So YouTube is one product

area, cloud is one product area, search

is one product area, advertisement is

one product area. Yeah,

>> that are like the big ones. There's

another one that I can't think of right

now, but you'll have those. And then

internally they, you know, you'll have,

you know, different departments and

different teams organized in some way,

but it's like it depends. There's reorgs

very very frequently. So you mentioned

like teams can just evaporate and cease

existing which is because of reorgs

because of you know projects being

sunset moving around. So like there's

probably never been like an org chart

that's lasted more than a quarter inside

of Google. Uh but then like within all

of these different organizational kind

of factions, you'll have, you know, kind

of all hands meetings and town hall

meetings.

>> Yeah. So you're saying it it kind of

like goes down, right? So like there's a

company one every week, but then you're

going to have your I don't know your

wider org and your your like you know

like the bigger org and then your your

teamly will you'll have a weekly team

for sure. So like every week you'll have

the TGIF or let's just call it as as in

your team meeting and then every other

week or every fourth week you would have

some of the other orgs and they can just

stack up.

>> Exactly. And then there's the like

functional orgs as well that comes into

it which I don't know if it's as much of

a thing with engineers but like you know

they have the SRB or and the design or

>> Okay. So a bit of a culture shock if you

come from like a 10% startup.

>> Exactly. and like the Devril or and then

like each of those like discipline based

groups they'll have diff like there are

different ones in different PAs and like

so it's it's so much like it very very

much depends on where you are in what

org in what discipline

>> you're trying to say this is a downside

of transparency right because hear me

out so at Uber we had something similar

it was a little bit ridiculous and like

on the kind of the orwide all hands

which it didn't really concern And most

people people were just coding on their

lap cuz they were expected to show up at

on the meeting room. People will be

coding on their laptops like I I I don't

want to be here but I I need to show up

cuz the SVP is here and whatever. But

like what's what's the alternative?

Right? Cuz if you if you're saying we

are transparent and we want everyone to

know, you know, like we want everyone in

Google to know what the CEO thinks like

want every engineer to know what the CTO

thinks. You want to know what your

director thinks and

>> and just what like what's going on, what

people are working on. Well, then

there's a lot of meetings. Or you can be

what Apple does or like a more secretive

thing where like look, you're in your

team. You are not allowed to talk with

anyone unless you have special clearance

and you don't unless you're, you know,

so you have your team meeting every

week. That's it. Don't worry about it.

Oh, why are they like, you know,

drilling off the wall and like

disassembling next to you? That's not

your problem. Like,

but I feel those are the two extremes

and like there's different sort of

trade-offs. The sort of trade-off is you

will be in the dark and you will have no

clue why they're like wearing funny

outfits today and why they're like all

laughing and and then the other one that

you will know it's just like there's all

these oh you've not been in that

meeting. They actually told us there

like oh no sorry I was trying to get

some work done.

>> Yeah. And and just like it can probably

be pretty overwhelming.

>> Yeah. Um but I mean they are good also

again maybe because Google is so global

I think they are pretty good at you know

recording like I know I've heard

especially since the working from home

like pandemic situation like after that

they have even better kind of processes

in place for this kind of stuff. So like

cross crossatlantic meetings for

instance like there these days

apparently like they do some all hands

stuff twice. So they'll do one for a

time zone that makes sense for Europe,

one that makes sense for US because that

also used to be a thing where uh like

you can work on something that's like

primarily based in the US in Mountain

View, but you can be in in based

wherever you want, but you will have to

wake up in the middle of the night to go

to meetings if you want to know what's

going on.

>> So let's talk about some things. There's

so many things, but some things that

make Google special. And one of the

things that came to my mind that I

didn't really hear before a term called

reglers

and you know Google has this like fun

terms for like new Googlers newler

exgoogler googler. Reg Googleers is

apparently a program where Google talent

acquisition reaches out to former

Googlers saying hey you left Google a

few years ago want to rejoin and

apparently it's really successful. A

bunch of people come back. That's the

part that is not really common at a lot

of companies and it's a program. It's

working. People like it and yeah, people

are rejoining as well.

>> Oh, interesting. I didn't know there was

a pro program for it. I know plenty of

people who've left and rejoined. But

>> I heard that there's an outreach

program. Uber started to do something

similar, but I think it was just in one

of the offices, but I someone told me

that it seems to be happening. And I

don't know if the the program is

official, but yeah, the term regooler is

it's it's a fun term.

>> Yeah. I mean, I I love all the names for

the different Googlers. I have I have a

few. Yes. Like noolers. When you're a

new Googler, you get the nooler hats,

the famous ones, like you know, the

little caps with the little propeller on

it.

>> I actually I have this uh I got this

little android

>> friend when I was interning there. Uh,

>> wow. That's a collectible now today.

>> Yeah, exactly. It did have. So, this is

the little nuclear hat. It used to have

the propeller, but I broke it.

>> Wow.

>> And like it has the little Google

backpack. You can even open it.

>> Wow.

>> It's just so cool. But I think this I

mean this is part of like the googliness

of it all, you know? Like we've we've

talked a bit about the the playfulness

and how it's it's just part of the

culture. It's uh like the offices,

things like this.

>> But but what what what is googliness? Is

it like kind of fun, quirky, geeky?

What would you say it is?

>> They go through this in the SVE book

actually. Uh but like they have a couple

of kind of like values or

characteristics if you will uh of being

googly. And maybe the term like being

googly is like somewhat uh being like it

might have been bigger previously and

now it's they talk about it differently

but like being googly is a lot about

thriving in ambiguity because things

move so much all the time. There's lots

of reorgs and you know you try things

out. So that needs to be a part of of

who you are. Uh there's a lot of values

feedback which ties into you know the

the Perf now grad uh feedback cycle. Um

challenges the status quo. I think we

touched on this as well like that's also

been like from day one with trying to

get people who look outside the box and

really accept that you know things could

be better. puts the users first

is

uh maybe somewhat of an ideal rather

than

>> Yeah, that sounds pretty ideal from from

using Google products.

Yeah, cares about the team. And yeah,

this is again goes back to the like it

seems from I mean I'm sure there's

exceptions but in general it seems like

the Google culture and googliness is

more about teamwork and succeeding

together. I think we mentioned bonuses.

One thing actually in the bonuses is

they have what's called peer bonuses and

also kudos which is like how googlers

can you know they have ways of sending

like an hour of massage to someone they

think did a great job. Um, and then

there's the peer bonuses that are uh

like more proper like monetary like not

like huge bonuses but like a bit uh and

like those really incentivize you know

doing things for other recognizing

things for others.

>> So there's like probably a few hundred

dollars or something like that

>> I think so. Yeah, I can look it up but

something like that. Yeah, but I I don't

I don't think have many companies have

this. Like, yeah, some do have the you

can send thanks and they're public and

everyone is like, "Oh, that's nice." But

usually there's not like a monetary

something attached to it. That sounds

pretty unique.

>> Yeah. And then the last Googly thing, at

least on the list, is does the right

thing, which I think is maybe um

ambiguous a bit. I mean Google used to

have the motto don't be evil which they

kind of faced out and I think it was

like 2018 but that was one of the

tenants from very early on to just

I think it goes as again with the status

quo like there's plenty of examples of

big corporations

you know starting out with good

intention and then maybe getting lost

along the way. Well, it it it could be

lost along the way, but also it could be

like when you're big enough size, like

it goes back to like when you start to

be uh doing government contracts and

then the government does something that

is just either ethically wrong or or a

group of people disagree with it or a

large group of people disagree with it.

Do you stop working with the government?

And if so, you're now giving up that

space for your competitors. And then you

know it now goes into the territory of

like what about other governments when

you're a global company. If your

software is used in every single

country, what if one country attacks the

other? Are you also the evil country or

or if if two countries attack each

other, you know, like both sides will

think. So all I'm saying is there there

could be a point where by being involved

you you can be part of it. So that that

might also be one part because that

that's also one thing that Google is

being attacked on for for example uh not

just Google but all all companies of you

know like providing software for I I

think I think maybe it's the the US

defense uh ministry because they're now

using it for something and all the big

tech companies now provide software

there and you know the alternative is

like pull out and give up on the market.

Yeah. And also I I guess this goes back

to like do the right thing. It's it's a

it's in this book. I I just read it. But

the right thing for who? Right? Cuz u as

a software engineer, what what is doing

the right thing for a service mean? Does

it mean that we will have a great on

call experience and uh we will invest a

lot of time maintaining the system or do

we do the right thing by shipping

features quickly so our the business

gets stays ahead or do we do the right

thing that when customers complain the

tickets come to developers immediately

and we wake up in the middle of the

night? like the right thing for who,

right?

>> So, there is a little bit of ambuggy

there.

>> Yeah.

>> But but to be fair, like it's it's in

the book here actually. Yeah. It's great

that they printed it in the book. Do the

right thing says has a strong sense of

ethics about everything they do. Willing

to make difficult or inconventional

inconvenient decisions to protect the

integrity of the team and the product.

It's interesting. So customer is not

mentioned here, nor is user. And and

there's no customer anywhere. They do

say user, but there's no customer.

That's one thing I noticed with Google.

They never talk about customers. And

about 70 they always only say users. And

that's I think that's an interesting

thing uh cuz about 70% of Google's

revenue comes from ads. So they need

users but not necessarily customers. And

this is one frustration by the way that

like I personally have with Google. You

know, you cannot you can never get

customer support. You you're paying for

the product but you cannot get through

to a a person. And this is you know it's

very different to Amazon where Amazon

does give you first class customer

support but they do burn engineers in in

into pushing to make sure that uh you

know that the systems are work they're

they're repaired. Interesting

trade-offs.

>> It makes sense in a way where like

obviously Google Cloud Platform

I mean I guess the the earliest like

kind of precursor to that I think is

when they opened up App Engine back in

2008. engine. Yep. I was an early user

of it.

>> Yeah. Uh because like again like the the

Google infrastructure was primarily

built for Google. It was never meant to

be built for customers and then you know

they had these you know they

externalized parts of this and that you

know grew to become the Google Cloud

Platform. They obviously made design

decisions and choices pro I'm I'm

assuming while externalizing some of

these like building basil um coming from

blaze kubernetes from borg you know

they've must have built in you know

parts of it that's like okay so how do

we make this work for other companies

other use cases but yeah it's a it's a

different it's an interesting difference

between GCP and and other cloud

providers is like where where it started

from so to say.

>> Yeah. Yeah. That that that that is

really new to to Google. So I think

Google cloud in in general it did start

from app engine which so unlike a lot of

Google services it was not start from

internally and externalized but it was

built as a an app I was an early user of

app engine. App Engine was so darn cheap

everyone used it because of it. It was a

lot cheaper than using AWS and running

your own ET EC2 instance and and you

didn't have to worry about scaling it.

autoscaled. And then what happened in

2010 or 2009 cuz I was a user of it. I I

built a side project on it that had a

few hundred thousand users and I was

paying pennies for it and there was like

some big reorg inside Google and they

shut down a lot of projects I assuming

that they were not profitable and

overnight Google app engine changed

their billing to be like 5x as expensive

and suddenly before they they said like

all right like you can deploy you know

your code and we will autoscale you

don't need to worry about it and now

they had to worry us about like index

rights and They exposed us to our

infrastructure and everything became a

lot more expensive. People were voted

and they gave us 30 days of notice which

was like really really short. So it felt

to me that it was a do or die moment in

the sense that either that that or

proves that it can be profitable or or

generate revenue or they're shut down.

But it was the first time with Google

where I felt really burnt. I I I used to

think of Google as like this amazing

place that you know will not trick their

users. And I felt just tricked and I I

was really like miffed. Now, I wrote a

really nasty letter on the customer

support forum because of course it's a

the only support forum was a Google

Google groups or Google forum or or

whatever that was. That's where the

official engineering team work with us.

You can see that Google is terrible at

dealing with paying customers. It's

almost like they don't they don't care.

It's almost like they despised them a

little bit. Not always, but but in a

weird way. Like most companies will be,

you know, like put them at the the top

and Google just treats them the same as

free users. At least that was my my

sense. But yes, that that's how Google

Cloud started. And there's this really

really weird thing or unique thing with

Google where everything that Google

builds, every major product or that they

invest in massively is number one.

YouTube, Gmail, Google Maps you could

argue, but it's probably the most used

map solution. Android, Chrome, and then

you have Google Cloud, which is the

number three cloud service provider uh

across a bunch of different

measurements. They're way behind uh AWS.

They're behind Azure and they're very

they're not really seeming to catch up.

They seem to be stuck in this perpetual

third place. The strange thing about it

to me is is I I would assume if it's

Google, it's very easy how to make it

you know number one is like I start

Google start using their own cloud

service and I mean that gives the

confidence of everyone well if Google is

built on GCP you know like this is uh

what what like you can you can trust it

and AWS did this over a long long set of

time. They have moved over almost

everything. Amazon.com runs on AWS as I

understand. It took a long time, but now

it's all runs on it. When I was at

Microsoft, they they just bought Skype

and I was in the Skype or they forced us

to move over to Azure and we hated it.

It was not ready. There's a lot of

things, but we had to move move it and a

good part of Microsoft runs on Azure.

Not all of it. Like Bing I understand

has their own infra but Google doesn't

really run on GCP or maybe some small

parts of it do.

>> Yeah. So they've had a few from from my

understanding my research they they have

a few like they've made attempts to move

and migrate some stuff over to GCP and

there are things that run on GCP. I

don't know what but some things do. the

way that they they've externalized their

product as they say it's it's very much

like

you know Kubernetes is not Borg uh by

choice and Borg is set up for planet

scale is you know what they refer to it

as

>> and that is not most use cases it is

very specific and they've made a lot of

engineering decisions that you know like

with again like everything from

networking to databases to like

literally everything is custom. So like

does it actually make sense to just

externalize that? Not really. But that

also means

that like well if if that's what they

have like if they want to win in cloud

that would probably be a thing that they

should do in order to

you know really boost the platform to be

as good as possible

but then again it's like do they have to

win at cloud because maybe if they win

at cloud they are not going to win at

all the other things. Yeah, I I I the

question is if if they want to win, but

I I got this because I have been asking

a few Googlers or GCP people about this

like what because I still remember

inside Microsoft it people were not

happy music and it was just dumb. By the

way, the guy who did it was Satia Sachia

Nadella. He he was pushing people to do

it. He was not the CEO back then but he

is now. But you know Microsoft clearly

could be number two with Azure because

internally they're pushing it just as

much as externally. So they're they're

going to keep improving it. But someone

at at Google an engineer told us how

like I I have heard a lot of Googlers

say that their internal infra superior

and it's engineer told us that superior

is an interesting term here. It's not

like feature to feature Google internal

is better than GCP but the level of

vertical integration across the the

entire development process from like you

know like like doing the planner doing

your docs code reviews all that is

unmatched because every part of the

workflow has been thought of and it's

got these like nice hooks and as a

developer it just works so much better.

So there's all these like decades worth

of integration of the custom stack that

it just works between all the tools that

there is tight coupling that would be

not possible and in the end devs will

just do whatever makes it easier work

for them like Google as a company will

probably be like well we want to be

productive right that's why you have

your internal platform teams and as you

said that's probably Google being

productive and building their product

and generating ad revenue 80% of the

time and other 20% will be hardware

sales and like some service sales and

all that, it's probably more more

important that they they grow their

business as opposed to just growing the

cloud. The cloud or can figure it out

and being and maybe being number three

in one of the biggest business in the

world. Um, in the case of cloud is

acceptable just the same way as Google

is number two on on mobile in a lot of

regions with Android. They're not number

one. They're number one in some part of

the world. They're number two in some

other parts of the world. So, you're

right. May maybe Google is way bigger

than this and and maybe this is a this

is not a they don't need to win at

everything right like only in the in the

important search with self-driving there

seem seeming to be investing heavily

LLMs maybe those are the things that

they really want to win in

>> I mean speaking of of tradeoffs

in general I think like if you really

think about it and if if Google were to

move everything to GCP like if that also

I guess like because they built out, you

know, their build system, their monor

repo, all their developer tooling on top

of the same infrastructure. It's

different.

>> It just might not not work as much as

especially when you have like all the

permission system that are like built

baked in into internally. Who knows? I I

think it's trade-offs, right?

>> Yeah.

>> It's probably a good reminder that like

you don't need to like there's no no one

solution. And also history of a company

is I think pretty relevant to understand

why they are where where they are right

now.

>> Yeah, exactly. That's one of the the big

takeaways for me doing this research.

Maybe I mentioned it earlier as well.

Like I think one of the reasons why they

can be so open about the stuff they're

open about is that is like it just like

it happened this way because it was so

early and you know they made some fairly

early acquisitions and strategic pivots

into you know like we're not just

building one thing we're building

completely different things like the or

is set up based on that the workflow

developer tooling everything is just so

interconnected with Google, which is why

I think it's so it's been so interesting

to uh learn about it

>> and and I I want I'm thinking that the

companies that are now growing as fast

as Google did in the past. Open AI is a

good example of of this of some of the

AI other AI startups or maybe you know

Nvidia's growth is is speeding up

although they're more in the hardware

business or for social media Snap uh or

even Meta. Well, they they were earlier

a little bit, but let's say for for

OpenAI, they are now, you know, they're

building other things custom. We're not

talking about they they're using cloud

like they're not going to I I mean,

OpenAI is seems like they're investing

in their own data center, but it's going

to be whatever everyone else is doing.

We're now talking about the the LLM

stack, for example, that might be

custom. So, like they're just taking

whatever is there. They're they're not

reinventing that part cuz why would you?

Snap is a social media company. They

used they were very heavily I think

they're one of the biggest Google cloud

customers and kind of Google always

shows them off as like an example of

like someone who grew with them because

they could just throw money at Google

and optimize it later. And even Uber has

moved over to a mix of Oracle and and

Google Cloud from their own data

centers. So it probably helped Google

that they were early in the internet,

right? Like there were just no good

search engines back then. They were the

ones who built this. One thing I I have

to mention internal mobility. there's

there's just so much internal mobility

inside Google and there for large

companies there is usually some level of

internal mobility but as I understand

inside Google is just really easy to

move teams if you you're not in a bad

performance standing you can pretty much

move teams anytime as I understand and

and usually companies have a lot more

limitations on who can move or can

managers veto or not and here it's it's

a free-for-all so like people can switch

teams And people do switch teams a lot.

Like I think it's hard to talk with a

Googler who uh if if they've been there

for like 10 plus years if they've not

worked on several teams and and some and

sometimes changing teams like a few

years in a row like almost like and you

know knowing how big Google is like

these are like thousands of of teams

tens of thousands of teams actually and

yeah you can just go between them.

Obviously for smaller offices a bit

harder because there's not as many

around you but but still

>> yeah I think there's a there's a slight

thing. So um just to mention during the

pandemic obviously Google started

working from home

just as as the rest of us and my

understanding is especially then the

internal mobility kind of like from and

maybe a bit after that kind of spiked a

bit as well. Again like most of us you

realize that like it's possible to do

this without being in offices. Uh, and

so I know of of folks who were able to

start working remotely for teams in new

locations.

>> Oh, so so they were able to do internal

mobility. Previously, you needed to be

in the same location. Now they could

remotely join that team for a while at

least.

>> Exactly.

>> I'm pretty sure that's going to go back

to where it was before slowly but

surely.

>> Yeah, cuz it does it has done that. like

they I mean Google now is I think almost

everyone's on a hybrid schedule where

they expect you to be in the office like

at least two three four times a week

probably depends on where you are and I

know there's some

>> follow your manager. Yeah.

>> Yeah. And like how important you are to

Google probably.

>> Speaking of exceptions, there is this

concept of singleton.

>> Yeah. Yeah. So a singleton is basically

a person who is on a team but like it's

the single person from that team working

in a new location essentially. Uh so if

there's a team say Whimo for instance

but they have like this one person who

really wanted to move somewhere else or

refuses to work there unless they can

work from that particular location. It's

like okay then you're a singleton. So

you might still work at a nearby Google

office, but you'll be the only person

like from that team working in that

office.

>> Yeah. And I guess it only makes sense.

These are senior people, people with

like key skills. Maybe if there was a

reorg, they were left there. Like you

need to be in demand typically for your

knowledge or your expertise.

>> It's not super common and uh it's

definitely an exception rather than a

rule, but uh like it does exist. One

more thing that is very unique about

Google is the non-stop rewrite like

everything is being re not everything

almost everything is is being written

every few years and this does happen to

some extent at most large companies but

with a lot slower pace I don't know if

it's the engineering enablement the fact

that there's a lot of new technologies

invented by Google as well right like

they they they created the go

programming language for example gRPC

protocol so so any open source

contributions or that the business is

changing that frequently. But because of

this, I mean, this is a good and a bad

thing. Like if you work at Google,

you're going to be really good at

rewrites and migrations because with a

with a rewrite, there's usually a

migration as well and then deprecation.

And that's a good thing. The bad thing

is that this is not usually the work

that most engineers would want to sign

up for. You're excited about building

the new thing, but again, there there's

that thing when you build the new thing,

how are you going to get the customers

over there?

>> Yeah. But I I think it's it's like on on

two sides there because they have the

monor repo they have direct access to

like uh they can actually make they they

do have a tool called Rosie uh which is

a tool for doing like large scale uh

migrations. Well, with the migration, I

guess there's two parts, right? There's

a code rewrite itself, which is always

easier one, but you can automate that.

And then there's a data migration, which

is going to be the the tougher one, and

the more errorprone one, and the one

that you want to get right. And by the

way, that's a really useful skill to

learn because like usually most

engineers don't need to migrations all

the time, but when you do, you better

know how to do it properly and and with

the right steps and with the right

safety and planning. But once you've

done it a few times and you burnt

yourself, you know, you'll be

unstoppable.

>> Yeah. Either Google can be the worst

place for it because you do it all the

time or it's the best pace because they

do it all the time so they know what

they're doing.

>> But you can also move teams, right? So

on once you've done a migration, you're

seeing the next one's coming, you might

just move teams if you I mean, if you

did an okay job, it should be easy

enough. You you can look at it from

different ways. And obviously moving

teams I like it's probably going to be a

bit more nuanced than that. You do need

a manager, a new manager who will be

supported. But as I understand with

Google, your current manager does not

need you don't need to ask for

permission. You can just move because if

you would, then that would tie people in

a lot more and you know, you could have

manager bias and all of those things.

>> Another one of the aspects of Google

being so big like we've mentioned that

they're basically different companies

operating in the same company. So that

is one thing to consider. So like if

you're you know if you've been at

another company and done internal

migrations and or uh yeah like move

teams also worth keeping in mind that

moving teams at Google might be a much

bigger shift but then again it's

probably a shift in like the tech stack

is obviously the same like you don't

it's not moving companies in the way

where you have to learn a completely new

tech stack and like how they use their

tools and all the different quirks of

like yeah you've done Kubernetes before

but how do they do you Kubernetes at

this new place rather the the thing that

you're gonna run into is probably more

on the how do you prioritize what are

the communication like all all the like

softer things might be very different uh

moving from team to team

>> and I guess one thing about Google that

is kind of special although a lot of

other companies do it these days but

just how much they contributed to open

source and the industry the broader

industry like some of the biggest

project that that they they have built

or open source or started and now are

still sponsoring and investing.

Kubernetes obviously one of the big huge

ones. Angular which react is now a lot

more popular but it's still it's I think

it's gaining popularity again and Google

is very heavy user of this front-end

framework. TensorFlow for machine

learning it's so widely used. I mean we

we cannot not mention the LLMs uh with

the that was not the technology but the

paper that that kickstarted all of this

with ascension is all you need the go

programming language chromium uh as the

the browser engine and just just so so

so many other things I think you know

Met Meta has a bunch of strong

contributions in Microsoft's in in

certain areas but I feel Google has a

really wide range from like backend

frameworks machine learning front

content frameworks, protocols. My sense

is that

overall they might be the single most

kind of contributor to like the kind of

broader open source ecosystem,

especially when you take the papers into

account that that kicked off even more

projects or or software businesses.

>> Yeah. And

inspired people as well. uh and like

looking through some of the papers

uh even from early on but even later

papers that I look at like they're also

very open with the just like learnings

of like what what works what doesn't

what should you take from this what

should you not take from this and I do

feel like and like I was reading through

some of their old like tech post blog

posts as well uh like they have like

they had a tech blog for or maybe just a

blog for like Gmails like the Gmail

email team had a blog that they wrote

from like 2007 to 16 where they just

talked about the time that Gmail went

down and they had to go in and recover

data from all their tapes. It seems like

they haven't ever or like they don't

think of sharing this information as

some kind of you know moat or something

they need to be secretive about because

like what would happen if other

companies copy us? I really like that

about Google actually. I mean, I think

it used to be like that. I feel that

might be slowing or maybe there are just

not many blogs. I I don't remember like

any major engineering teams sharing, oh,

here's like cool learning. So, I think

that might have been the earlier years.

>> Yeah, it could have been.

>> Uh, and I think now it might be a bit

more controlled and there is no like one

Google engineering blog or I don't even

know of like some other teams, but still

for the open source for sure and for the

papers. So the the research and the open

source is there and I mean to be fair on

conferences Google speakers do show up

and they they do share they do talk. It

might be a little bit changing because

now Google does sell to developers. They

have some developer tools uh like like

Firebase

a lot of Google cloud. So now they do

have dedicated folks who are you know

Flutter is another good example like on

their those area they're kind of a lot

lot more active of sharing like all

right here's how to use it how to build

it etc. But but yeah, I still asked this

uh on on the podcast episode about

Kubernetes. Like I still didn't really

understand why did Google release

Kubernetes because they had Borg and it

worked really well for them. And so why

bother building something that they

didn't even use? Like they just put it

out like oh here's kind of some some

lessons from Borg that others can use.

And I think where we got to is that they

probably did it because well first of

all now looking back uh it was it was

good for their uh very good for their

cloud business to have a technology

where it's very easy to move from let's

say containers on AWS or Azure to GCP

also by by knowing this there's not much

harm

it wasn't too much investment for them

to do it but it now helps the

recognition of the brand it helps with

recruitment and it They and they're also

now pretty much steering the technology

that is the winner, Kubernetes. They

have a huge say in it. Like yes, it's

it's it's an independent organization

that's that's there, but most of the

contributors are still at Google, so

they actually have a pretty good say in

that. So, so, so maybe it's it's a mix

of these things, but it never felt to me

that it was like some sort of business

decision. It was probably some engineers

thinking like, it's a cool idea, why

not? And then you can you can justify

the business for it. So, like I wonder

if a lot of Google is like this, like

engineers are like, oh, here's here's an

idea. I'm like, okay, let's see if we

can justify some some business numbers.

>> One of the things again like we're doing

this research from the outside looking

in, right? Like we're able to get to the

stuff we can get to and we've talked to

people. Um, and one of the things that

has come up is definitely like the

culture is shifting.

uh like it there's like you know the

winds of change in Google um following

you know partially just like the vibes

of the industry as a whole but partially

very much internally also during the

pandemic you know they they had some big

leaks uh so like they stopped some

internal transparency in the all hands

and the full access to like everything

going on um like I know that's been

restricted.

>> Yeah. So, so let's let's talk a bit more

about this because I I feel this is like

the Google of today. Basically, we've

kind of arrived from like where Google

started, how they built like all all

these cool things to what is Google like

today from from all all that we've

gathered and I guess maybe we should

just like reflect a little bit on how

the whole as you said the whole industry

has gone through a massive change which

was I mean there was a couple of like

kind of like left turn and right things.

First there was a pandemic which the

whole world thought would be would be a

disaster and then it turned out to be a

blessing for tech because everyone

started to hire like crazy and interest

rates were still down. Uh there was

close to zero interest rates in the US

and and worldwide on on borrowing money

for more than a decade and this was just

interest rates were just about to go up

before COVID and then because of COVID

every country cut it down to like zero

for another two years. So tech had this

thing where there were still like zero

interest rates meaning investors

couldn't really put their money anywhere

but like tech stocks or startup

investment uh tech had a big boom

everyone started to hire so this was a

great time and this was 2020 and 2021 I

I had so many friends and and former

colleagues who like got 30 40 50%

compensation increases like just by

going to a company that did similar

things but they just raised money. It

was a great time and a really hard time

to hire or or to retain. People kept

leaving left and right. I heard of

hiring manager a hiring manager who had

a engineer sign and ready to join them

but they didn't didn't show up on the

first day and I was like oh called them

up and like oh yeah I got like a 20%

higher offer. Sorry I'm I'm working

somewhere else now. And then this was

great for like a year or probably a bit

more than a year. And in 2022, just as

lockdowns ended and the world recovered,

tech started to crash down. There was

like mass layoffs across companies.

There was I think it all started with

the fast bankruptcy. One click checkout

sort of fast just went bankrupt from

being one of the hottest companies in

tech to just bankrupt overnight and then

a bunch of other startups including like

stripe and some other like almost every

kind of large company did layoffs. And

this turned out later that as we look

back it it had to do with interest rates

rising and when interest rates went up

um this meant that companies and

investors looked for profitability. So

everyone suddenly focused on that and

there was a bunch of overhiring in the

previous year. So suddenly we had this

like dual shock effect of going from

everyone in tech is in demand and people

could not hire enough boot camp

graduates because there were not enough

university graduates to just layoff

shocks uh happening as well. A few

company bankruptcies and just a really

kind of negative vibe in the industry

and this was this went up all the way to

2023. Big tech had big layoffs and

Google had the first ever layoffs in

almost the first in company history. In

2008, they did like a 3% layoff because

of the financial crisis. They then did

some layoffs after they bought Motorola

in 2014. But since then, they they

haven't really had any layoffs. And

Google used to be known as the the place

with like great job security, work life

balance, almost impossible to get fired

if you do a a minimum good enough job.

And then they did like 6% layoffs just

cutting people with like including

people with 10 15 20 years of experience

just sending an email to them at night.

And I think this really changed the mood

at Google. This was 2023

and then in 2024 they they there were

some more layoffs coming in not as many

as before but it's now seems like that

kind of period of Google was perfect in

so many ways. perks, money,

work life balance, clubs, investing in

everything. Like it was just impossible

to hire away from Google pretty much.

Now there's a bit of a sense of there is

some level of being cutthroat. Not as

much as their competitors like Meta or

Amazon where it's a lot more tougher,

but but still it's it's like, you know,

it's it's a company. At some point, you

might get fired and you'll get a good

severance, but they'll tell you that

it's it's game over. And maybe it's not

your fault either, but on on one end,

it's it's a it's a change that hasn't

happened before. On the other end, I was

like, come on. You you cannot have it

all everything for the whole time. Like,

especially for like such a large

company. So, like one part of me is

like, well, I mean, it's kind of sad

that it's over, but my other sites and

at least startups have a chance. At

least they can point to one thing Google

does not do perfectly.

>> Yeah. I mean, it's it does seem like

they had a really good run for a while.

And like I'm sure there's pockets at

Google that is still probably a

fantastic place to work, but I do think

like it's not necessarily bubbles

bursting, but yeah, like vibe changes

and like part of that is the industry,

but like part of it is also just like

the actual products. Um so in terms of

like

uh you know YouTube was and is in many

ways the new TV like it is dominant. Um

but then Tik Tok comes along and

Tik Tok is you know much more focused on

the users and grabbing your attention

and getting you pulled in. Um whereas

like YouTube has definitely done that as

well but like not to the same extent in

terms of their shorts but then all of a

sudden like now YouTube has has and kind

of has to push for shorts because they

like now they're in the attention war

and similarly with

you know like I feel like there was much

more in like the the kind of public

stratosphere in terms of yeah it's like

oh Google sure has a lot of our data and

they're sure doing things with it and

you know Google search results are like

a lot of them are sponsored this doesn't

feel great. So I think there there's a

bit of a shift as well in terms of just

you know like they don't yeah they they

cut the don't be evil but like maybe

they leaned into it as well. Who knows?

>> Well, but I think this is the part where

so I saw Manu Cornate who writes all the

all the the these comics. He was for 12

years at Google. He then quit Google and

and joined Twitter and then lucky for

him he he joined right as Elon Musk

bought Twitter but he joined he told me

that he he loved Google because he over

the 12 years I think from 2010 to like

2022 towards the end he started to

become disillusioned of Google because

he joined with you know he believed like

what they said the don't be evil the

make the world a better place the

whatever uh and you know build cool

stuff and then he started to see how a

lot of his comics started to become um

more reflective of how he's thinking of

just how like he had a comic of Google's

naming of the throwing darts, how it's

all chaotic. It was it was starting to

criticize a company where clearly like

there's a lot to criticize about Google.

But my my and some of the sometimes

profits started to come come up on on

some of his comics on how Google is

prioritizing profits. And so here here's

the thing like you know when you're

going up uh including at at Google like

you reach the L6 level which is staff

engineer that's the same level as a

manager. Now if you think about it as a

software engineer you think like oh I

just want to think about the code my

colleagues and then as a manager you

need to think about the business and

your budgets and headcount and hiring

and firing. Now you're now paid the same

like as a staff engineer and a manager

is paid the same and they kind of are

expected similar things. So a manager or

one level up especially a senior staff

engineer is kind of expected to

understand where the you know like a bit

more of the managerial side where the

business lives and how it makes money

and one thing that I think anyone

working at Google or any other company

needs to understand is where does your

salary come from and how can Google keep

paying top of the market and it's to do

with their profits just keep increasing.

Uh it's ridiculous. If you look at the

chart, every year Google grows about

about like 15 to 20% in revenue, which

is which is bonkers because they're now

so big. They're making like 300 and

something billion dollars per per year.

But as long as that happens, things will

be good, right? There's not going to be

large layoffs. There will be large

bonuses, all the perks, new offices

built, etc. As soon as that slows or it

goes to zero, bad things will happen

because there will be uh layoffs and and

you know Google's doing everything to to

not make that happen. But eventually

that reality will creep in which is at

some point your job might involve

helping Google make more money so that

they can hit this thing or if it's not

making more money then help investors

believe that next year they will make

make more money which is has to do with

all of the things why Google is going

all in on AI or or if that doesn't help

then then tell them how you're going to

cut costs faster. So it I think at some

point both in the life of a company but

also in your seniority you cannot ignore

the business and then you cannot ignore

like how they make money how they will

make money will it naturally grow

without you doing anything because if so

you're in a good place or does Google

for example need to expand the areas

that it services which which will

include things that are controversial

right like like again like will it get

into military contracts and and the easy

answer will be no but now when when you

need to increase your revenue by 20% and

by not saying by saying no to them, you

cannot do that. Then the there's all all

these things that that trickle down as

as a result of that. So

>> yeah, it's it's growing up in a in an

industry and in a an economy that only

goes up.

>> Well, then Google has it it went from

being a startup in a in a garage not

even 30 years ago. Wow. in 1998 like

just an idea to one of the biggest

companies in the world I think fourth

biggest company right now by market cap

and you know like how much more than can

you grow like I'm sure you can grow

right but but where is it like okay they

can now you know they can aim to

overtake right now it's Nvidia and Apple

and Microsoft ahead of them but but but

then what and will growth always always

continue I mean this is more of a

philosophical question but I think all

of big tech will eventually have to

reckon with this this question because

we went from tech companies being kind

of underdogs, you know, like there

there's people who still remember

Facebook just being an idea or or like

being be used by teenagers. Same same

thing with you know older older

listeners or or viewers when Google did

not exist to like yeah they they won and

now the question is how how do they keep

winning and eventually winning is

innovating but at some point it it might

be trying to lock out other competitors

which you know Google is being sued

right now by the US Department of

Justice for offering Apple a bunch of

money and for Apple accepting to be

their default search engine and not

having any competition on on let's say

iOS. It was interesting how things

change.

>> Yeah. And it is it's interesting. It's

like the the amount of power these

companies have as well. I personally

couldn't imagine life without Google

because like you know it's my calendar,

it's my email, it's like so yeah I have

a background in design and uh there's

this general idea in design that really

good design is design you don't notice

because it just becomes a seamless part

of your day-to-day experience like you

can point out bad design easily because

those are the things that you notice and

that provide friction in your life and

Google is like They have a lot of things

that just you barely think of them

because they're so ingrained in your

life which means that you know they do

wield a lot of power like you know

you've probably had that you know when

they decide to change some aspect of

Google calendar or change you know a

color of something or whatever you know

you have like you can your whole day can

be completely thrown off. Yeah, and I I

think there's a good question because I

think so far a lot of what we talked

about Google and what makes Google

really unique is how they started. There

was a startup. It innovated so much.

They had 20% time. They kind of got rid

of it in 2013, so about 10 years ago.

The vibe is al also also changing. But

the reality is that anyone who joins

Google today, it's a very different

company than it would have been even 10

years ago because there's a phase of

growing and innovating and there's now

pock there's pockets of innovation,

right? AI is still up for grabs. there's

a really open battle between uh all all

the leading AI companies including

Google and it's kind of fun and exciting

but there's also the areas that are just

one if you start to work on Gmail I mean

it's already market leading like what is

going to your mandate going to be it's

probably going to be I mean you know

keep existing users don't let them turn

uh or extract more money from them in

terms of ads because that's how you make

money or or upsell them to something but

it'll be mostly like maintenance and and

don't mess up or if it's a cash c

product like Google search. You know, we

we've now seen reports uh that some of

the executives knowingly kind of made

Google search worse to have people see

more ads to generate more revenue. But

the point is like working on a on a

product that has been built, it's been

proven, it's been innovated.

There's now very small innovations

compared to what it used to be like. And

and so at some point I and which I I

don't think it's a necessarily a bad

thing by the way, but at some point this

this thing comes where like okay like if

you want to work on something that used

to be like the old Google, it's probably

going to be startup or if you're lucky

it'll be a team inside of Google that

has a green field project again like

like all of those things happen all the

time. But but yeah, but for some of the

the big areas, it's it's different work

to to work there. And this is by the way

how this is one of the few ways we used

to be able to when I was working at Uber

and we were a lot smaller than Google

how we used to be able to get people

with Google offers with stronger overall

compensation numbers accept us cuz we

would tell them like look you can

totally go to Google like get paid

really well and all that and you know

you can be a cog there like you know

like do your little small little thing

you know like tweak a few things and

just be unsatisfied with your work or

you can come here you you can get less

less cash but like here's all this stock

which you know it's it's the same we

promise well I mean but we couldn't

promise but that's that's the nature of

stock but if everything goes well you'll

have this huge impact here you know

you'll have the coc your work or or your

your like everyone uh and we're building

something new and you'll have freedom

and that was the thing that made a lot

of people do it in fact I think that's

the reason that people will leave this

really cushy cushy place called Google

is if they just get a little bored and

they feel that they could do so much

more

>> obviously in like there's always

innovation uh but just like it just

looks different today I think and the

scale of it is different because I mean

yeah like Google calendar does come out

with new fun things fairly often and you

know there's new features in Google

meets and Google chat and and all these

things but it's yeah it's a it's a much

smaller scale uh so I think it's like

You can definitely still be like do fun

innovative stuff at Google, but it's

yeah, it's not going to be the new

Gmail.

>> So, so let's talk about who do you think

would be a good fit at Google? Like who

are people who could get a lot of out of

it in today's Google? Like not not not

the ideal Google, but the one that that

that we know today who could get a bunch

of value out of working there. And when

could be a good time assuming you manage

to get in because I think we should be

clear getting in is is super hard but

for for those there what could be good

question to ask of like am I in the

right place or or should I use this

privilege that I'm working at Google

because once you're at Google it's so

much easier to go anywhere and maybe

explore some other avenues. There are

some of the things that we've been sort

of talking about the whole episode. Like

if you're really

super into the specific tech stacks and

trying new tools and playing around with

new frameworks the second they get out,

you know, Google is not for you.

Basically, you're not going to be able

to use or reuse any of your like

triedand-true

favorite things because you're going to

be working at with completely different

things at Google.

>> So, you're you're you're basically

saying like if you're interested in the

frameworks in the industry that startups

use that that you build up the knowledge

that I don't know like the latest React

framework or latest ML framework that is

out there that makes you in demand for

other places. Right.

>> Exactly. So if you like keeping up with

the industry like keeping up with the

tech industry's cutting edge as opposed

to internal Google cutting edge that no

one knows except for Google but then you

might not be able to talk about it

because of the NDA and who know

>> exactly. Uh so that's one part of it.

Another part like if you're someone who

like who is not into reorgs or like

things changing all the time like the

googly thing of being into ambiguity

like if you like things being somewhat

like stable and yeah then Google is

probably not for you either.

>> It's interesting because the the

perception outside will be Google is

stable as a whole. I mean maybe teams

change but you're saying you know things

change so just get used to like you're

you might get new managers or several a

year.

>> Yeah exactly like reorgs are a staple.

>> Yeah I actually I think I talked with

someone I think it was Google who said

like I had like you know like seven

managers in a six managers in a span of

a year. It was just a lot of this was

someone pretty senior so like was being

thrown around a little bit but yeah.

>> Yeah. And then on the flip side of that,

I think if you if you do like trying new

things and innovating and trying things

out,

like I think Google is good for that as

well. You know, like you mentioned, they

did, you know, 20% time was way more of

an established thing in the past. Like

they didn't completely get rid of it. It

more phased out. it more became like 100

to 20% time where you can work on things

but it's going to be you know in

addition to your normal work but they do

also keep they have some like incubator

type teams at Google still uh they have

one thing called area 120 you know they

build completely new very like

startupbased completely new apps uh that

very quickly like often just transition

straight into the killed by Google

graveyard. Uh but you know they'll

probably like they will reuse some of

this technology as well. So like like

there is a like killed by Google is

definitely true but it's not like all of

it's wasted like they have they yeah

they've done so many chat apps and so

many social network type things where

the products didn't survive but the

technology got you know it got

incorporated into what's Google chat now

and Google meets and you know so like if

you're into innovation and trying new

things Google can be for you but it's

not it's probably also not going to look

the way that you imagine. it to look

like and if you get in love with your

idea and you know the whole I kill your

darlings thing. If you're not good at

killing your darlings then probably just

do startups instead of Google.

>> Yeah. Well, one thing I'll add is Google

is very very good for one thing which is

the pedigree. So if you have if you

worked at Google for let's say you know

sometime even a year it's one of the

most recognized brands even to date like

there are some other companies that are

that you know keep going up and down

right now. Open AAI for example is is

also very very recognized and of course

you know Meta but Google has been like

this for almost 30 years almost since

the since the beginning and it continues

to be and part of it is the bar of

getting in is just very high. So there's

this thing I think this this it's kind

of funny that we're saying that should

you work or should you not well first of

all like can you get an offer because

most people unfortunately cannot and

this is made even worse that Google's

headcount has been flat pretty much in

fact likely declining since the last 3

years which has never happened before so

until then they were growing basically

it was easier to get in uh considering

assuming the same number of candidates

applying every year. So it is kind of

getting harder to to get into Google. So

it's not taking for granted. So like my

suggestion would be is if there's a

reach out from a company like Google, it

can be a challenge to just go through

the interview process even if you have

no intention because their interview

process is very very similar to the

interview process of the companies that

are hardest to get into including the

scaleups and startups that are super

hot. Open AAI and traffic. they will

hire very similarly than how they hire

from Google. And then there's this other

interesting thing. If you look at where

the hottest startups of today hire from,

you know, may may this be open AI,

entropic as I mentioned, Ram, Stripe,

so many of them will be from Google.

Like Google has a lot of people who are

underutilized, but they're very smart

and very capable. And the companies that

can pay more than Google or can match it

or can have a bigger promise with equity

will will often just take the shortcut

instead of interviewing you know so many

people with with with no proven tracker

just go go to the source. So that's one.

And then there's a network. Uh because

if you're someone who is is curious or

talks with other people inside Google,

you can build up a really good network.

Just getting to know people. Uh the ex

Google network is very strong. The the

fact that there's a Sugler network who

as I understand they they help each

other. There's like investment networks

and all these things. So if you have the

opportunity to potentially get into

Google, see if you can and then decide

if if you want to do that. Having it

behind your back, it it it can it can

strengthen your your your resume and

your opportunities for for like a decade

or even more to come. You can always say

you're ex Googler and the thing is not

many people will be able to say that

globally. So especially as as a software

engineer. So yes, one more thing to keep

in mind.

>> I know it's changed but like there is

one thing of like interviewing with

Google like it is a bit of a funnel. So

like there are some of the uh interview

process that's just like you know get

get your foot in the door to begin with

and then like once you're in there like

I do think you still have somewhat of a

choice and you know you get to talk to

some a few different teams at least you

used to like talk to a few different

teams like see the vibes before you like

uh jump on fully.

>> Yep. And Google that has this

interesting thing called team matching

which is for software engineering

positions typically they don't interview

for a specific team but they interview

in general. And once they decide like

all right you're good you meet our you

meet our our bar. Then a team needs to

claim you. So you need to kind of go

through a team matching process which

can be really frustrating by the way.

The recruiter might tell you like

congratulations we want to hire you. and

you're like great where can I like how

much is the compensation how are I

signing like we just need to go through

team matching and sometimes this team

matching can take months and sometimes

it comes back with I'm sorry no teams

were available or or wanted your profile

in in this case so that's the other

thing it it is it's kind of it's kind of

harder to get into than most places and

I've heard that recently uh about like

six months ago this happened that uh a

bunch of people were rejected and and

very disappointed that they couldn't get

into So, it's it's one one one of these

things. Again, it's it's it's it's it

can be frustratingly hard to get in when

you want to get in. Uh but again, uh

it's good to know cuz I hope that we

were able to share some details cuz it

this environment really is not for a lot

of people. And you do need to put up

with a lot of a lot of things that come

with with large companies. Uh and in

this case, a one that is very

transparent, which means there's a lot

of information overload as well. Oh,

yeah. I think if if you're if you're not

good at like multitasking or if it

stresses you out to like have to go to

meeting middle of the day while while

coding, you'll probably hate this place

probably.

>> Yeah. Again, like maybe there's a pocket

somewhere. I'm sure there's some team,

but in general. Yeah. And I guess that

also would maybe be like my last

reflection on who would fit at Google.

Like it is a big company. It is so big.

There's so many people. Again, like I

was there for like not even four months.

And in that time I I met so many people

and like yeah if you go to an afterwork

and meet someone it's like yeah you're

talking to someone who might as well be

at a completely different company. And

also like when I left and then after

like after a couple months I happened to

be in London again and I like went to

the office and visited and like in just

like four or five months like I I

recognized like almost no one and the

people I knew it's like no they'd

already moved or actually like this used

to be the case where the London office

used to be kind of a holding hub as well

like people would be hired and then go

to the London office for a year and then

they would move to the zur IC office cuz

like immigration wise that was easier

from a lot of company uh a lot of

countries and so there was just this

constant flux of like new people, old

people. It's like oh where are those

people? No, they moved. And if that's

not your vibe, if you like like knowing

your co-workers and feeling like oh this

is like a nice

space where like you know it's fairly

stable then uh yeah and Google's

probably not for you. Interestingly,

Google is one of the very few tech

companies who are very innovative. They

come up with so many new products even

today like an AI that they're they're

leading. They're a frontier lab. They're

one of the few companies who build their

own model. Microsoft doesn't even do

that or if they do, they're they're kind

of hiding it. But they're also a company

where a lot of people retire from. So,

this is the company where it's it's not

unusual to see people with 20 plus years

of having worked there. And when you

look closer, it'll be different teams.

They will switch teams every now and

then. positions some sometimes you know

they'll go from engineer to sometimes

TLM sometimes to PM and back so there's

a lot of mobility but it is one of the

places together with maybe Microsoft to

some extent Amazon where like I do see

people probably in larger amounts or

larger percentages just stay there and

clearly decide either that they're

they're very happy there or that they're

the happiest they they can be compared

to other options and they do it all the

way to retirement and because Google

pays as well as as it does. Retirement

doesn't necessarily come at the around

65 or whatever the legally mandated is.

A lot of people will say I'm retired

earlier because I have saved off enough

together with with Google's perks and

pension program and and whatever that I

will now have a very comfortable life.

And and you see people in their you know

like 50s or so say that they are like

early retiring after a decade or or more

at Google. And some of this has to do

with a bit of a bias that like 10 or 20

years ago joining Google getting stock

meant that the the valuation brought it

up. But again, it's it's rare to see uh

companies like this. So that's that's

just kind of an interesting positive.

And you know, maybe similar to banks

used to be places like this where like

in tech divisions when when I I worked

at JP Morgan, it was pretty common for

people to retire from there because it

was stable, it was predictable, and

there were some lifers as as we called

them. But I mean I think it just shows

the tech industry is changing. You know

now there are stable companies to

startups that turn into stable companies

that are still in innovating but they

kind of won their market. So and Google

is definitely one of them in in some of

parts and in some pockets very exciting

and and doing a bunch of interesting

stuff.

>> We've just spent how many hours talking

about Google?

>> About three.

>> Yeah. We could probably go on and we we

do have you know we have written deep

dives to accompany this podcast. But if

you want to go in even more detail about

some of this stuff, go check out the

deep dive articles. We'll have lots of

links. And again, because Google is so

open, a lot of this re like a lot of

this data you'll just be able to find

like you can find the papers we've

talked about. You can read the books we

mentioned.

>> And and that's the thing. Uh one one

thing that I would just close with is we

could go on. We're we're trying to cap

it at a at a reasonable length as as

reasonable as it got. And we do have

more structured notes in the show notes

below uh that that we're linking in the

pragmatic engineer deep dives as well in

previous deep dives. But don't forget

that for every company that is a large

company. It's it's not just one place.

There's so many different teams and

everything that we might have said or

covered about how things generically

work. It might be absolutely false for

for one for that specific team that you

might be working in or or that your

friend is working in. So don't forget

like I think personal relationships

really do matter. And what I have seen

you know pe reason re reasons people go

to Google for example or leave Google

might be their manager. They had an

amazing manager at a company and they

happen to move to Google and then they

they followed them and the other other

way around. So you know people come and

go between uh companies like like

Google, Meta, big tech, startups and

scaleups and there are some things that

can be generalized but yeah don't forget

if if you meet interesting and valuable

uh people just you know keep in touch

with them because they might they might

end up in interesting places that might

or might not be like these. And I hope

that these details were interesting and

and probably collected for the first

time in in this format. This was an

experiment for us as well. So, let us

know what you think of it.

>> Yeah, it's been a lot of fun, a lot of

information, but uh yeah, hopefully

we'll do this again with uh other topics

in the future.

>> Yeah, let let us know your feedback and

hopefully we'll see you in the next one.

This was our Google podcast episode. If

you'd like to get even more details

about Google's engine culture, check out

our deep dive article in the primatic

engineer newsletter linked in the show

notes below. If you've enjoyed this

podcast, please do subscribe on your

favorite podcast platform and on

YouTube. A special thank you if you also

leave a rating on the show. Thanks and

see you in the next