Nah man, nice try, but you're wrong. I worked at Google on at least one of the codebases you're talking about, and I can tell you that the "skills" that most Google interviews test for are almost never applied there. Certainly not in an "on the spot" format either.
Most of the work @ Google, especially on an established codebase like Chromium (my experience), is about slow incremental engineering in very small bits and pieces doing mostly really mundane administrative things. And when there's 'core algorithm' type stuff to do, there's plenty of time and space to stop, consider, read the literature, and move on from there. Nobody is going to put a gun to your head and put you on a clock and then score your results like in an interview.
Most of the intractable difficult problems at Google are more "how to get there from here" and organizational; how can I pile up this series of code reviews over months to get to this final destination where this system is cleaned up or more efficient or this feature implemented/implementable.
Google's use of algorithm testing in the coding interview is simply a result of the fact that they have hundreds of thousands of applicants and need a way to filter in some repeatable and measurable fashion.
And it's worth pointing out that the interview process @ Google goes through a whole series of metrics & calibration towards that effort. It's not just "could solve this problem", it's "solve this problem according to interviewer X's satisfaction, but we've calibrated interviewer X's scores at level N, so adjust according to that" and so on. There's an attempt to be scientific about it.
Most other companies applying "leetcode" are not doing that, they often simply have a highly reductionist mental model of what "software engineering" is, which IMHO doesn't accord with the reality of the profession.
Are you lucky to work at a company that gets thousands of resumes from seemingly qualified people a day? Probably not.