@@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.
@@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
"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!
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
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
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
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.
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.
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.
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..!!
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 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
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.
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
"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.
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
"so what did you understand?"
"Nothing :)"
😂😂
Everything... that i don't see in my lifetime
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
Didn't understand a single thing.. but enjoyed it 😂
True 😂
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
My favorite one of your videos so far - wow great job!
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.
These Time stamps are legendary 😂
💀💀
lol, this is what 500 lc problems does to a mfer
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.
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.
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..!!
everything went top of my head
same
lmctfy isn't really esoteric, it's just an acronym for "Let Me Contain That For You"
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.
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?
0:09 Heavenly Delusion Season 01 🌝
Love the kevin fang style videos. Keep it up!
Sounds so interesting, thanks a lot for making this!
Funny that this video doesn't mention memegen as the top tool built at Google😂
long time no see, very glad you're back
Thank you for this video. Very informative.
I am very glad you are back
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.
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 💀
more design architecture stuff PLEASE!!!
Great video!
I really love this kind of videos 😊 Please make more of them ❤
Great video, liking this a lot
what anime is that in the beginning?
Love the sense of humor! 😆
Excellent video and info!
Excellent video. Thanks a lot!
Most of this just went over my head.
Nothing understood, but enjoyed.
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
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
aaaah finally neetcode revealing his faceeee , always wondered how u look like...
Love your stuff, neetcode
How are you doing the transitions between the old/new code?
I believe Borg mon (Borgmon?) is another one. The open source equivalent is Prometheus. Don't quote me on that though!
source 0:10 ?
the king is back in town!
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
Bring on the “ultra secret google tech” 😅 jk, great video!
Thanks Pooja 🙂
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 😂
These stuffs are already known and talked by many already. There is no secret sauce here. But, anyways thanks for summarising these.
Typo @ 2:48 - "Intermadiate" KV PAirs
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
Thanks!
this was awesome!
didn't understand a word. Can anyone point to some resources on learning about the above?
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.
My brain is so small I can't understand any of these tools.
I don t know by what I was hit but I am subscribed and ready to learn-suffer more
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
What your views on flutter
beautiful just beautiful, i dont understand it but dammit it is beautiful
It's so fun to watch your videos!
Will be cool about languages
For a moment I thought this was Fireship's channel, wait now on his channel I will mistake him with you
me watching this in 4 am: "I like your funny words, magic man"
I expected Gira
I heard borg was also superseded but I don’t remember the name.
Where are you going next?
When a culture promotes on delivery instead of results.. what a mess
In what software do you animate your code?
MS Paint
God bless you brother
You forgot Spanner
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.
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.
sauce at 00:12?
Man I know all these, but I can't make videos like these.
Bazel is a nightmare. You're lucky that you didn't have to use it.
badass video
bro these kinda titles could get you in trouble with them
Lmfao at that thumbnail 😂😂
Yp ... still a lot to learn😢
distinguished comp sci. undergrad and i understood nothin lmfao
Why people always want to join Google then ditch them once they in lol
Boredom
Abseil is not so popular eh?
The people that came up with this shit are genius (real computer scientists).
Us software engineers just copy paste lmao.
so what's next after quitting google?
i thought you were never gonna return
I wonder if they use PyTorch for ml 😂
We do indeed
Ultra Secret xD
ok but sauce for the intro?
jhuangtw/xg2xg
didn't understand shit, bt it was nice
0:10 sauce ?
Heavenly Delusion
@@that1boii969 XD thanks...
i can say definetly i didn,t understand anything
My brain
And they do ALL of that to display the same 4-5 websites...
Piper :Waz:
lol, google has no ideas what developer platform is. :|