Running marathon is way harder than running 100m. Most people are not even capable of doing marathons.
But that doesn't mean that winning 100m is easier than winning a marathon. Might even be the opposite, because of harsh competition.
When you're building products, your goal is not run. Your goal is to win.
About 10 people on planet earth could have come up with Spanner.
I'm just talking about engineering. I'm not talking about building products which get market acceptance, which is a lot more than engineering, and might be your point.
I'm not convinced. I've worked in many industries and many company sizes and I've met smart people everywhere. I think a lot of devs who are busy pumping out CRUD could create these kind of systems if they were in a situation that called for them (hell, it gives you a chance to actually use all that stuff from your CS degree), just as I know for sure that a lot of devs who are busy pumping out CRUD are more than capable of creating a programming language. The bottleneck isn't technical ability, it's being in an environment that will actually pay you to work on that stuff.
Folks like Jeff Dean at Google are really out there. He built a number of systems that very few people were capable of. But you have to be at a certain level to even see it.
> But that doesn't mean that winning 100m is easier than winning a marathon. Might even be the opposite, because of harsh competition.
If we go much, much farther into this analogy, it tells us that for any given agent, one of these races is always going to be much easier than the other one.
If you want to be competitive in marathons at a world level, you need to be East African. If you want to be competitive in 100m sprints, you need to be West African. Which race is easier? That depends who you are.
Not necessarily. FAANGs have an army of product/project/program managers, market researchers, and other analysts and experts to handle product vision, etc. for the engineering team. That's the big advantage of being a megacorporation: they can afford the overhead of having their employees be narrowly focused specialists.
(It's also why one sometimes see people who leave FAANGs stumble when they join a startup; they're used to having all that infrastructure supporting them and have to adjust to an environment where it isn't there.)
Google, collectively, may be among the best (I'm not hazarding an opinion) at solving technical problems.
I, however, expect good engineers to help with product vision, understanding and addressing customer pain points, and amongst the senior engineers especially, be effective at communication and helping manage upwards to achieve those ends. Somewhere, Google engineers are dropping the ball there, or are so detached from those problems that their abilities in those skills are untested.