@@ejaz787 I've worked plenty of places where the place is kitted out like college / sixth form common room. Many of the people act like teenagers / children. One woman I worked with like the colour purple so everyone her desk was purple, her phone was purple etc. I recently had a retro where it was "Barbie" themed because that is . It is cringe meant to appease a child like mind.
4:58 To answer your question about why Google doesn't migrate to the open-source variants of Google-internal tools (e.g., why Google doesn't migrate from Borg to Kubernetes), I believe it's because: 1. The cost of migration is not worth it - given how much infrastructure and other Google assets (existing SWE knowledge, additional tooling, integrations with other Google-internal tools, etc.) are built on top of the old, Google-internal tool. 2. Open-source tool roadmaps are steered/influenced by other companies (e.g., Google doesn't have 100% control over what new features Kubernetes will support in the coming years). My guess is that 1 is the main reason - since some Google products DO use open-source tools (i.e., some Google products use Kubernetes). (That said, it's hard to make general statements about Google, since Google is so big and each team is actually quite different.) Great video, BTW. I learned a ton!
@@monad_tcp Than you are a bad engineer. gRPC and Protobuf has so many advantages above REST, some include version safety (including backwards compatibilty when you e.g. add fields to a message), type safety obviously, being much slimmer in bytes (because it's binary and not sending field names with it like JSON does) but also speed wise, as it's using HTTP2, therefore reusing connections. You open a connection to a gRPC service and then can burst hundreds of requests, without always having to open a new request which takes heaps of time. Apart from that, it also supports things that are hard to impossible with rest, like bidirectional streaming. A rpc defined in the service keyword can either (or both) be set as stream. That means, you could call a gRPC method, say "UpdateStatus", and every time something changes, you send a new message, but it's still the same request. Or you can get auto completion results as you type (every type results in a new message and the server is also streaming and sending requests as fast as it can). Or you have a batch processing scenario where you send mulitple messages, like chunks or files or whatever, and as soon as a message is done processing, you sent one back. But it's not coupled, so one streaming message from the client does not require a 1:1 response, you can also have the client stream however many it wants and when it's done, the server sends one single response, like "ok done, I processed all your 100 messages, bye now". But the video also depicted proto pretty bad. Javascript is probably the worst example for proto, because 1) the lang itself has no type safety and b) (i have never written proto in js, but) it looks kinda weird what he did in the code, like reading the .proto file and going from there.. because usually, in proto, proto compiles classes/objects for whatever language you are targetting. That means, you don't have to write the server and especically not the client yourself, you're only plugging the business logic. For java or go or whatever lang with type safety, proto generates messages in the language of choice and server/client stubs. For server, it basically creates an interface which you have to implement (which would contain all methods like UpdateStatus, etc. which you need to fill your business logic in, like querying from a database and then returning) and then call a method to create a new proto server with this interface. And you're done. Client even simpler, just create new instance of the generated client classes/structs, supply an IP/Port, and you're good to go. The object would then have all methods and handle the HTTP in the background. So no, using REST over gRPC in 2023 is nothing but being lazy. For new systems there is absolutely no excuse. Especically because proto can easily do REST (with grpc-gateway) as well. You can write options in each message (and rpc method) saying "this specific method would be a GET, this a POST and for that message, the name field should be in the path, etc., etc." and then it'll serve a REST API along to use. But gRPC was also made to be used for internal communication between microservices. So not having direct browser support is a feature, so to speak. Again, with grpc-gateway that is not an issue, but still, grpc is not really suited for it, as there is usually no authentication in microservices and opening them up for web is kinda.. not good.
I loved your leetcode journey - but can you explain your journey of how you're 'fluent' in all these tech stacks? Looks like a huge leap from doing X# of leetcode problems to all these academic tech stacks. I've come across some of these, but I don't think I'd be very good if my day job required me to understand all of this.
You likely don't often interact with these special tools at Google except in higher level Senior positions. These tools are already built, likely already integrated in the stack and automated. You may only need to ever interact with one of those tools in your project, and documentation is thorough enough to get you started.
I'm pretty sure he is not fluent in any of these. It's easy to read on these to get a surface level understanding especially after working at Google for a few months. Don't be deceived by the tone, he is not an expert at actual engineering tools.
"Spanner is the crackhead database that uses GPS and atomic clocks to literally break CAP theorem." YEAH! It is f'in crazy and hard to use correctly. I've actually never seen an implementation that didn't have contention issues. But there is absolutely nothing that scales better. Everyone doesn't know how lucky they are to not have to use borgcfg. Kubernetes FTW!
Hi, NeetCode! As I'm going through an interview preparation, I've noticed that it would be very nice if you implement the following feature to your website: when searching a particular task tell a user the topic of this task
7:32 Why is that?. Vast majority of the courses/tutorials are really FE focused. Even the ones that are supposed to be "Full Stack:" are just using some BaaS to avoid work on the backend.
My guess is because it's easier for self taught people. Backend isn't crazy either, but it requires a bit more foundational knowledge, so a CS degree helps.
I got kubernetes right (pats back) Other than that, i understood nothing in this video. On a serious note, thank you for compressing so much information in this short video.
If you're as rich as google just have everything in house and force your engineers to write every single line of code you want to use so that it gets refactored and maintained properly and so that you don't write code you don't need AND so that you don't have to deal with external deprecation that may pose security issues
Great video! I knew gRPC/stubby would be on here, learned some new stuff too. I did a gRPC video for IBM a few years ago and very few people at IBM know about it lol
@@jessepinkman144 Corey Schafer is another good one for Python. I also really like fireship’s quick and dirty explanations. Generally I’m usually very sketchy of people who plaster their face all over their videos or try to sell you something. TechwithTim I think happens to give good advice tho
Crazy that I was looking up Sergey Brin today and skimming through his paper he wrote introducing Google and in the same day I find this video simply going to your page because I know how influential you are in tech. I forget why I looked up Sergey but I do remember why I looked up your channel because I have to start practicing for tech interviews like yesterday.
Excellent explanation of Google's internal tools and their corresponding Open source equivalents or Competitors. You are too good at teaching these things...Thanks for posting these and please keep posting such interesting stuff..!!
I think many tech companies have their own internal tools for everything. Like in amazon there is a internal tool for every kind of work related to software development.
pay attention bro as he said he never really learned the build tool scratching the surface is easy but they all have depth that most will never need and thus never reach
This is the problem with Google IMO. They don't even use their own technology (I mean the open source/GCP version of it). Unlike Amazon which is literally a customer of AWS. So they don't understand customer pain points.
While they did aquire UA-cam, they did so early on. Google is the reason UA-cam became the juggernaut it is today, especially on the infra side. I don't think that's debatable.
"No one uses hadoop anymore, we use flume" Why are they all named like Nickelodeon substances
Wdym, who doesn't want a little 'Goops' in their tech stack?
Because many of these people never grew up.
@@dave7244haha what
To distract you from the horrendous things the technology will ultimately be used for
@@ejaz787 I've worked plenty of places where the place is kitted out like college / sixth form common room. Many of the people act like teenagers / children. One woman I worked with like the colour purple so everyone her desk was purple, her phone was purple etc. I recently had a retro where it was "Barbie" themed because that is .
It is cringe meant to appease a child like mind.
You should start teaching system design ASAP, top notch explaination
Wanted to ask for any recommended system design courses. Would definitely enroll in one from NeetCode
Agreed. ❤
no i
he is lol
This is just a fantastic explanation of Google's internal implementation. Please start a system design series too that would be great.
thiss
"so what did you understand?"
"Nothing :)"
😂😂
Everything... that i don't see in my lifetime
4:58 To answer your question about why Google doesn't migrate to the open-source variants of Google-internal tools (e.g., why Google doesn't migrate from Borg to Kubernetes), I believe it's because:
1. The cost of migration is not worth it - given how much infrastructure and other Google assets (existing SWE knowledge, additional tooling, integrations with other Google-internal tools, etc.) are built on top of the old, Google-internal tool.
2. Open-source tool roadmaps are steered/influenced by other companies (e.g., Google doesn't have 100% control over what new features Kubernetes will support in the coming years).
My guess is that 1 is the main reason - since some Google products DO use open-source tools (i.e., some Google products use Kubernetes).
(That said, it's hard to make general statements about Google, since Google is so big and each team is actually quite different.)
Great video, BTW. I learned a ton!
Stubby/RPC looks complicated but it’s really easy and convenient to use
Choosing things due to convenience is not a very engineer way, ironically
@@monad_tcp Than you are a bad engineer. gRPC and Protobuf has so many advantages above REST, some include version safety (including backwards compatibilty when you e.g. add fields to a message), type safety obviously, being much slimmer in bytes (because it's binary and not sending field names with it like JSON does) but also speed wise, as it's using HTTP2, therefore reusing connections. You open a connection to a gRPC service and then can burst hundreds of requests, without always having to open a new request which takes heaps of time. Apart from that, it also supports things that are hard to impossible with rest, like bidirectional streaming. A rpc defined in the service keyword can either (or both) be set as stream. That means, you could call a gRPC method, say "UpdateStatus", and every time something changes, you send a new message, but it's still the same request. Or you can get auto completion results as you type (every type results in a new message and the server is also streaming and sending requests as fast as it can). Or you have a batch processing scenario where you send mulitple messages, like chunks or files or whatever, and as soon as a message is done processing, you sent one back. But it's not coupled, so one streaming message from the client does not require a 1:1 response, you can also have the client stream however many it wants and when it's done, the server sends one single response, like "ok done, I processed all your 100 messages, bye now". But the video also depicted proto pretty bad. Javascript is probably the worst example for proto, because 1) the lang itself has no type safety and b) (i have never written proto in js, but) it looks kinda weird what he did in the code, like reading the .proto file and going from there.. because usually, in proto, proto compiles classes/objects for whatever language you are targetting. That means, you don't have to write the server and especically not the client yourself, you're only plugging the business logic. For java or go or whatever lang with type safety, proto generates messages in the language of choice and server/client stubs. For server, it basically creates an interface which you have to implement (which would contain all methods like UpdateStatus, etc. which you need to fill your business logic in, like querying from a database and then returning) and then call a method to create a new proto server with this interface. And you're done. Client even simpler, just create new instance of the generated client classes/structs, supply an IP/Port, and you're good to go. The object would then have all methods and handle the HTTP in the background. So no, using REST over gRPC in 2023 is nothing but being lazy. For new systems there is absolutely no excuse. Especically because proto can easily do REST (with grpc-gateway) as well. You can write options in each message (and rpc method) saying "this specific method would be a GET, this a POST and for that message, the name field should be in the path, etc., etc." and then it'll serve a REST API along to use. But gRPC was also made to be used for internal communication between microservices. So not having direct browser support is a feature, so to speak. Again, with grpc-gateway that is not an issue, but still, grpc is not really suited for it, as there is usually no authentication in microservices and opening them up for web is kinda.. not good.
I loved your leetcode journey - but can you explain your journey of how you're 'fluent' in all these tech stacks? Looks like a huge leap from doing X# of leetcode problems to all these academic tech stacks. I've come across some of these, but I don't think I'd be very good if my day job required me to understand all of this.
to become fluent at these techstacks you'll most likely be reading documentations or getting help from seniors at google to guide you
You likely don't often interact with these special tools at Google except in higher level Senior positions. These tools are already built, likely already integrated in the stack and automated. You may only need to ever interact with one of those tools in your project, and documentation is thorough enough to get you started.
I'm pretty sure he is not fluent in any of these. It's easy to read on these to get a surface level understanding especially after working at Google for a few months. Don't be deceived by the tone, he is not an expert at actual engineering tools.
Didn't understand a single thing.. but enjoyed it 😂
True 😂
"Spanner is the crackhead database that uses GPS and atomic clocks to literally break CAP theorem." YEAH! It is f'in crazy and hard to use correctly. I've actually never seen an implementation that didn't have contention issues. But there is absolutely nothing that scales better.
Everyone doesn't know how lucky they are to not have to use borgcfg. Kubernetes FTW!
Hahahahaha! You're cute.
Hi, NeetCode! As I'm going through an interview preparation, I've noticed that it would be very nice if you implement the following feature to your website: when searching a particular task tell a user the topic of this task
These Time stamps are legendary 😂
💀💀
lol, this is what 500 lc problems does to a mfer
7:32 Why is that?. Vast majority of the courses/tutorials are really FE focused. Even the ones that are supposed to be "Full Stack:" are just using some BaaS to avoid work on the backend.
My guess is because it's easier for self taught people. Backend isn't crazy either, but it requires a bit more foundational knowledge, so a CS degree helps.
0:09 Heavenly Delusion Season 01 🌝
I got kubernetes right (pats back)
Other than that, i understood nothing in this video.
On a serious note, thank you for compressing so much information in this short video.
If you're as rich as google just have everything in house and force your engineers to write every single line of code you want to use so that it gets refactored and maintained properly and so that you don't write code you don't need AND so that you don't have to deal with external deprecation that may pose security issues
Great video! I knew gRPC/stubby would be on here, learned some new stuff too. I did a gRPC video for IBM a few years ago and very few people at IBM know about it lol
lmctfy isn't really esoteric, it's just an acronym for "Let Me Contain That For You"
everything went top of my head
same
One of the few programming channels I trust, I’m so tired of grifters lol
Can you share the other channels name? Because I’m new to programming, so I want to follow them too, thank you!
@@jessepinkman144 Corey Schafer is another good one for Python. I also really like fireship’s quick and dirty explanations.
Generally I’m usually very sketchy of people who plaster their face all over their videos or try to sell you something. TechwithTim I think happens to give good advice tho
Shit just increased my love for Backend Engineering. I'm curious to know what role you worked as at Google. Backend Engineer? System design something?
Funny that this video doesn't mention memegen as the top tool built at Google😂
Crazy that I was looking up Sergey Brin today and skimming through his paper he wrote introducing Google and in the same day I find this video simply going to your page because I know how influential you are in tech. I forget why I looked up Sergey but I do remember why I looked up your channel because I have to start practicing for tech interviews like yesterday.
My favorite one of your videos so far - wow great job!
Excellent explanation of Google's internal tools and their corresponding Open source equivalents or Competitors. You are too good at teaching these things...Thanks for posting these and please keep posting such interesting stuff..!!
what anime is that in the beginning?
I am very glad you are back
long time no see, very glad you're back
lol, thought I was in a fireship video for a moment.
Hahaha. Yeah It felt to me like that too! less robotic, and a little slower pace imo
yeah the thumbnail and title baited me i thought i was clicking on fireship 💀
Sounds so interesting, thanks a lot for making this!
Thank you for this video. Very informative.
Typo @ 2:48 - "Intermadiate" KV PAirs
more design architecture stuff PLEASE!!!
I really love this kind of videos 😊 Please make more of them ❤
Great video!
Love the kevin fang style videos. Keep it up!
Nothing understood, but enjoyed.
Great video, liking this a lot
Love the sense of humor! 😆
I think many tech companies have their own internal tools for everything. Like in amazon there is a internal tool for every kind of work related to software development.
Excellent video and info!
whhhyyy did you change the ui of neetcode?? I loved that it was divided upon topics
It should still be divided by topics. There's a button in the toolbar of the practice page that lets you toggle from list view to grouped view
Most of this just went over my head.
source 0:10 ?
me watching this in 4 am: "I like your funny words, magic man"
Excellent video. Thanks a lot!
Love your stuff, neetcode
I don’t understand what he explained while explaining about how the data is stored at 6:56. Is everyone else able to understand it that easily?
Yes
Hello, Google intern here. This feels illegal to watch 😂
California?
u musta missed the part about it being on github
Hello, Google intern here. This feels illegal to watch 😂
Hello, Google User here. This feels meaningless to watch 😂
Lmfao at that thumbnail 😂😂
Here before google takes this down
Here before google fires me.. oh wait
@@NeetCode they been cracking down on leakers, wouldn't be surprised if you got a legal notice email from Chris Rackow
this was awesome!
the king is back in town!
I believe Borg mon (Borgmon?) is another one. The open source equivalent is Prometheus. Don't quote me on that though!
I expected Gira
How are you doing the transitions between the old/new code?
Bring on the “ultra secret google tech” 😅 jk, great video!
Thanks Pooja 🙂
aaaah finally neetcode revealing his faceeee , always wondered how u look like...
So you learned all of these tech at your time in Google? No wonder they hire the very best of engineers.
They teach pretty much all of them in the first week.
pay attention bro as he said he never really learned the build tool
scratching the surface is easy but they all have depth that most will never need and thus never reach
All sounds similar to stuff I use. I'm sure the APIs and details are different but nothing too extreme
I heard borg was also superseded but I don’t remember the name.
Names sounds like straight out of Rick and morty. Hey morty let's build a new project with good ol Stubby and Goops and add in a bit of hadoop
Will be cool about languages
beautiful just beautiful, i dont understand it but dammit it is beautiful
My brain is so small I can't understand any of these tools.
What your views on flutter
badass video
I don t know by what I was hit but I am subscribed and ready to learn-suffer more
didn't understand a word. Can anyone point to some resources on learning about the above?
God bless you brother
Where are you going next?
It's so fun to watch your videos!
This is the problem with Google IMO. They don't even use their own technology (I mean the open source/GCP version of it).
Unlike Amazon which is literally a customer of AWS. So they don't understand customer pain points.
When a culture promotes on delivery instead of results.. what a mess
sauce at 00:12?
Couldn't continue watching this after seeing UA-cam mentioned as one of the ways google revolutionized the internet.
While they did aquire UA-cam, they did so early on. Google is the reason UA-cam became the juggernaut it is today, especially on the infra side. I don't think that's debatable.
These stuffs are already known and talked by many already. There is no secret sauce here. But, anyways thanks for summarising these.
For a moment I thought this was Fireship's channel, wait now on his channel I will mistake him with you
You forgot Spanner
Bazel is a nightmare. You're lucky that you didn't have to use it.
In what software do you animate your code?
MS Paint
Ultra Secret xD
Yp ... still a lot to learn😢
distinguished comp sci. undergrad and i understood nothin lmfao
Abseil is not so popular eh?
My brain
Why people always want to join Google then ditch them once they in lol
Boredom
The people that came up with this shit are genius (real computer scientists).
Us software engineers just copy paste lmao.
I wonder if they use PyTorch for ml 😂
We do indeed
bro these kinda titles could get you in trouble with them
don't tell me if i want to be a backend engineer at google i have to understand all of this?? 😭😭
Most engineers at google are just updating config files, so don't worry about it dog
@@NeetCode 😀😀
@@NeetCode thank god, thank you for letting me sleep tonight 😂😂
@@SASA_maxillo Hope you realize that was a joke, in fact there's a lot more to learn to understand Google's backend :)
@@mammocastbh, he isnt joking that is the actual truth.
so what's next after quitting google?
didn't understand shit, bt it was nice
i thought you were never gonna return
ok but sauce for the intro?
jhuangtw/xg2xg
0:10 sauce ?
Heavenly Delusion
@@that1boii969 XD thanks...
Piper :Waz:
LOL timestamps
string name = 1 🥴
i can say definetly i didn,t understand anything
And they do ALL of that to display the same 4-5 websites...
lol, google has no ideas what developer platform is. :|