> I really ask myself where those top engineers that make it through Google's famous hiring practices land.

Can I question the quality of said hiring practices?

I have been rejected for a project that was starting from scratch on something exactly like I had been building for 6 years at a competitor, based on such famous hiring practices (not at Google though). I was literally more experienced than the whole team on what they were building.

Because you hire people who are really good at leetcode doesn't necessarily mean that you always get the best candidates for the job?

Personally, I think we as a community should all question that theater.

My sense is that it likely made sense before Campbell's law took effect. IIRC they developed a reputation in the early 2000s for only hiring very bright people who could solve those kinds of problems on the fly. Then 1. the company needed more employees and 2. people started grinding away practicing those problems so they could pass tests that were intended to filter them, and you got what you have now. Lots of other companies cargo-culted them in the meantime and thought the studying was the point, or maybe for them it was (measuring compliance instead of brilliance).

Also concurrently I think a lot of HR departments were increasingly trying to create an air of objectivity to reduce legal risk, which is also where you get the N years of experience crap (e.g. my company's HR just made us change wording from something like "strong ability" to "5 years experience" with Go. I don't even have 5 years of Go experience specifically and I'm the technical lead on the team. Actually the way Go's culture is, I wouldn't be surprised if a lot of experience with it were a negative as far as I'm concerned).

having worked on AOSP for 3 years. I can attest most developers are capable but are not incentivized correctly. The appearance of improvement (demo quality code) is good enough in many circles to "complete" a project and move on. Net effect - the tragedy of the commons. Compound over a decade and 10-20 minute builds and 5-10 minute test time is the norm, and at that point even properly motivated - "would die for clean code" - sort of devs have a hard time. Put in place completing management chains all behaving the same (want to appear more productive/useful than others) and the mess is very hard to get out of. People were allowed/encouraged to cut corners I would let a junior dev cut on any project (duplicating resources from different parts of the build), building tool that demanded duplicate configuration, etc. Not a problem of capability (in some cases, yes, but rare), a broken selfish set of senior devs and leadership. Likely because it's not in google's interests for the project to be easy to work with/productive on. Open source washing was useful early on, now it's something of a liability. Only data gathered from devices and a little bit of cash from the play store are assets.