Not all younger developers have to jump through those hoops. There are plenty of companies that don't do that kind of nonsense, because they're trying to hire good engineers, rather than, specifically, engineers -- good or bad, that'll get sorted out later -- who will happily sacrifice their spare time to figure out how to jump through the arbitrary hoops that their jobs entail.
Holding this kind of bullshit interview isn't a bad idea if you're a megacorp with chaotic teams and fourteen levels of management hierarchy where people spend most of their time on infighting and career building. You need people who jump through hoops, because successfully delivering most projects in these environments is 10% difficult technical work (which the good engineers can handle, and you can typically hire enough of them via recommendations), 40% YAML-poking bullshit work, and -- optimistically -- 50% jumping through all sorts of technical and non-technical hoops, most of them self-inflicted.
I navigated this kind of process successfully early in my career, and the only thing that made me more miserable than interviews like these was the work I got to do afterwards, after accepting the offers. Once is happenstance, twice is coincidence, three times is probably just how these things are -- I'm now pretty convinced that the quality of the interview is (barring statistical accidents) highly correlated with the quality of the actual position.
It's very difficult, because making sense of the examples would require explaining all the convoluted decisions and corporate mechanisms behind them, and that would make it trivial to identify the companies in question.
I can give one example, I guess, since it's been a long time, it's a very common scenario, and this is an internal thing, so anyone who can identify it is either already there (tequila's on me this evening, mate) or has worked there before (I'm still up for tequila).
The buggiest component in one of the projects was the testing framework. It was a home-grown testing framework, incredibly slow (think "takes about 5 seconds to send a 20-character string over a 115200 UART line"), and it had a huge bug backlog.
Virtually all bugs got closed with WONTFIX. The person who'd written that monstrosity had made it up the management line, and his minion was now in charge of the team that allegedly maintained it. Since all sorts of bullshit metrics like bug fixing rate and total number of bugs and whatnot came up during quarterly operational reviews, a low bug count was nice to have. And since no customer ever complained of a bug in the testing framework, for obvious reasons, all that was required to keep the bug count to zero was an understanding between these two guys that all bugs would just get closed.
So you had to spend a few hours finding creative workarounds, since the two-line fix you'd come up with in five minutes would never get applied. And I mean creative. We had code that literally eschewed non-functional framework code by exploiting a race condition in its code in order to do RPC calls without going through the buggy framework code.
Now imagine you have to do something like this for every single task you do and you have a pretty good idea about how it goes. I mean you technically spend 100% of the time doing what you're supposed to do, but only about 30% of it is actually what you're supposed to do, everything else is mostly fighting cargo cult practices, senior engineering ego, and management disinterest.
Holding this kind of bullshit interview isn't a bad idea if you're a megacorp with chaotic teams and fourteen levels of management hierarchy where people spend most of their time on infighting and career building. You need people who jump through hoops, because successfully delivering most projects in these environments is 10% difficult technical work (which the good engineers can handle, and you can typically hire enough of them via recommendations), 40% YAML-poking bullshit work, and -- optimistically -- 50% jumping through all sorts of technical and non-technical hoops, most of them self-inflicted.
I navigated this kind of process successfully early in my career, and the only thing that made me more miserable than interviews like these was the work I got to do afterwards, after accepting the offers. Once is happenstance, twice is coincidence, three times is probably just how these things are -- I'm now pretty convinced that the quality of the interview is (barring statistical accidents) highly correlated with the quality of the actual position.