I think one thing to keep in mind is that this probably highly selects for "jack-of-all-trades" candidates while rejecting candidates that might have more knowledge / expertise in a particular area, when most likely the job is only going to require specialization in some of those areas.
I'll discount the second interview since that seems heavily prompted from the interviewee's experience, but the first interview asks pretty in-depth questions (for a junior) in both C++ and web development. Chances are, developers aren't being hired to work on both - so why not focus on one or the other, rather than potentially kick great web developers out of the process because they don't know much C++ (or vice versa)?
> "I think one thing to keep in mind is that this probably highly selects for "jack-of-all-trades" candidates while rejecting candidates that might have more knowledge / expertise in a particular area, when most likely the job is only going to require specialization in some of those areas."
FAANG-class companies do not want one-trick ponies or even few-trick ponies. At least in my experience, they explicitly want to hire not just for the current job but for the long term, which means selecting for highly-capable generalists with the ability to rapidly specialize in any area. And, having spent many years at a FAANG class company, they are right to do so. I worked on embedded systems, physics simulation engines, network services on a gigantic scale, RF related systems, etc. All that stuff one learns in college that many HNers say is useless, well, I found that I wound up using most of of it.
macOS is at least 20 years old, and Apple needs to maintain it indefinitely. They need engineers who aren't going to accidentally break things for the 100 million strong existing user base. Nobody rapidly specializes in Mac development, there is simply no substitute for experience in this area.
The results are pretty obvious and depressing when you see Apple throw engineers at the Mac who don't understand the Mac. Low quality, bugs, constant accidental breakage, bad design in opposition to the platform standards.
Not every engineer can work on "the next great thing". You need a lot of engineers to work on the old great thing too. A mixture, a balance of engineers is important. A company gets diminishing returns from having all jack-of-all-trades engineers.
Google is the absolute worst at this. They're constantly creating new things... and then discontinuing them a few years later. Their follow through is terrible. Nobody wants to do long-term maintenance. Even though most of Google's revenue comes from the old things, such as search. (My impression that Google search is actually less accurate and useful now than it was 10 years ago.)
People love to make sports analogies, so here's mine: imagine a football team that put 11 all-star quarterbacks on the field. They would be the worst football team in the world. Every team needs role players.
I think this is the opposite of how FAANG or FAANG-like companies treat the hiring of SWEs. They don't want people to specialize in any particular area. They want engineers who can be freely moved to whatever product line or team has a need for years to come, possibly working on fairly greenfield stuff that nobody has pre-existing expertise on. But deep knowledge of the fundamentals of computing and software engineering are non-negotiable.
They're looking to build a maximally deep bench even if you don't meet a specific immediate need they have. It's sort of like the dichotomy you see in pro sports draft philosophies, where some teams focus quite specifically on finding players who fill existing holes in the current roster and some teams just try to draft the most talented person possible even if they can't figure out what to do with them right away.
The sports analogy is not great, because tech companies can't trade engineers to fill a need, and there are no multi-year contracts, so any engineer can quit at any time.
There's also no hard industry-wide salary cap. With the salary cap, the best way to maximize your overall team performance is to get superstars under contract when they're young and underpaid, because a team can only afford a few veteran superstars. Also, sports teams have a hard roster limit, whereas big tech companies can hire as many employees as they like. The analogy breaks down in so many ways.
The analogy is with the dichotomy in incentives between teams that have to win now versus teams trying to build for the future. Some companies need you to hit the ground running because they are presently making no money and need to get a product out the door as quickly as possible. Some companies are going to make more money than God next year no matter what and are more concerned with ensuring they'll still be in a dominant position ten years from now. That affects the kinds of candidates they're looking to hire in terms of narrow specialists versus generally talented people, independently of any constraints in the candidate pool and compensation markets.
Again, the sports metaphor breaks down, because winning and losing is a zero-sum game, whereas companies aren't necessarily playing a zero-sum game. Moreover, a team's draft position is inversely correlated with its record, so there's an incentive to "tank" to get better draft picks. ("Rebuilding" often means getting rid of your expensive best players and intentionally losing for a while.) No such analogous situation exists in business, it's just an arbitrary effect of how sports leagues are organized. It's actually designed that way to encourage competitive parity among teams, prevent any one team from dominating forever.
It's also that they don't necessary hire for specific positions. They know they'll need 500+ junior devs by next year so they can afford to hire then determine placement.
It's also why they are frequently the firsts on college campuses.
I'll discount the second interview since that seems heavily prompted from the interviewee's experience, but the first interview asks pretty in-depth questions (for a junior) in both C++ and web development. Chances are, developers aren't being hired to work on both - so why not focus on one or the other, rather than potentially kick great web developers out of the process because they don't know much C++ (or vice versa)?