There is a lot of glue code at FAANG, but there are a lot of cutting edge libraries and services that you need to understand before you know how to properly glue them together. That is very different from mostly gluing together well documented standard public libraries.

From an efficiency standpoint, it is probably a lot cheaper to hire smarter users of those libraries than to ensure all new libraries can be used by less smart engineers. Especially since many smart engineers who can write great libraries doesn't necessarily have the ability to document those libraries well, so by removing the need for great documentation they can get a ton of such engineers that other companies with lots of mediocre engineers cannot find a good use for.

There are also a lot of developers working on the internal payroll, HR activity scheduler, communications apps, among others. I still remember an interview when someone was expounding about the wonderful opportunities to work on the site that Google employees use to book yoga classes and other offerings.

That said, I understand that in the interest of fairness and allowing equitable access to the highly lucrative RSUs, it's important to give interviews equally rigorous to candidates for the AdWords team as those who end up pushing protobufs all day.

There is no "this engineer should only touch glue code" and "this engineer should work on the really hard cool stuff". For category A, if something is expected to be extremely tedious drudgery, usually vendors/contractors are used rather than full time employees.

It’s perfect code with 105% test coverage and there are amazing meetings and everyone is as smart as they think they are.

So if I'm understanding your cynicism correctly, the code at FANGs sucks and so the solution is to lower the hiring bar?

Not at all. Just pointing out that a high bar for hiring still leads to shit code. And that's fine, its called growing pains.

Sure there's some of it, but not in my group and it's not something I'd be tasked with hiring for. Occasionally there's some infrastructure related task but I'd prefer someone on the team who actually has to use that stuff be the one to work on it.

We don't have a lot of glue code because we don't glue things together. We write the things other people glue together. That's why this is fundamentally different than 90% of anything I've ever done.

I also don't mean to say that all FANG work is like this. I could see some roles at, say, Google working on Android where it very much would be the kind of gluey work I've done before.

For a long time I am considering anything coming out of F an anti-pattern and an example of bad engineering.

There's glue code, but nobody wants to work with people only capable of doing glue code.