If the devs at your company need to put out fires constantly, then maybe it's a good test of whether they'll be able to do that.
1) The companies that do this interview a TON, so there are bound to be bad experiences, and those are the ones that people blog about
2) The questions are supposed to be hard, but achievable. So you get two scenarios:
A/ candidates who are not good enough and are not aware of it. "How am I supposed to know if the hashmap/dicationary data structure in the language I say I'm best at maintains insertion order? I just google that every time - everyone does!". Sorry, bucko. That's the kind of in-depth understanding of your tools that we DO expect you to give a shit about
B/ Immature interviewers with a bar that's too high that are using overly complex questions and don't get noticed right away by the more experienced interviewers.
So ultimately, YEAH, the questions I ask, for me to want to move forward with a candidate, I expect you to solve the problem. But I'm not expecting you to solve it in the most efficient way or GTFO
At a high level that reflects the work that we do. The project scale may be 20 weeks instead of 20 minutes, but the level of complexity is scaled accordingly.
Of course, we miss out on some candidates that could be great at executing on a large timeline but can't demonstrate it in a short in person interview.
But, (see my edit), this is all we can do to scale our interview process, and we don't want to take risks.
i look more after how people approach problems at a high level, where they show how they build the whole system and how they interact with peers and other departments to tell if they can gather data, organise it in specs, and then fine tune nicely build parts of a system. not code monkeys.
The vast majority at the FAANGs are full stack engineers which includes long term system design.
The comparison to a car assembly factory is so ridiculously out of alignment with reality that I can see why you chose to go with a throwaway account.