Depending on what you're hiring for, it's really not all that depressing.
If someone has been doing maintenance programming in a company without excellent culture that values code quality - their brains start to rot pretty quickly.
Five years later, they know how to debug, estimate, work on a team, just not really develop anything from scratch or think critically.
If you want people to do real development, those are hard to come by. If what you really need is someone to maintain some bloated codebase and make it worse, but not too fast, then most people will do just fine.
Another thing is: what do you really want from a candidate? What led you to start asking them trivia questions in the first place?
The really good ones will be put off by trivia because it brings them zero value. If you ask questions that actually pertain to the field you're hiring for, it'll go over much better.
For example I applied to work at a major bank, and got asked a bunch of security questions, which exposed me not understanding how main in the middle attacks worked. The interviewee had requested that I go home, do a bit of research and email them the answer.
This brought them value because they found out that's an area I have little knowledge in, and it provided me with value because it pointed me in the right place to go research.
Trivia puzzles don't add value to anyone. Frankly if you're doing trivia and are upset by the response you're getting, a part of that is your fault :)
Making sense of his codebase is harder then writing from scratch. Maintenance programmIng requires a lot of puzzle solving. What it does not require is modern technology. E.g. maintenance programmer should answer this question easily and have problem it you ask about react.
You don't want to work with people who can't solve trivia like this. Something like man in the middle can be learned, basic problem solving takes time to develop.
TIL building products that make money (as opposed to pre-revenue VC-funded CRUD apps) with a team that enjoys their job and can be home by 4 every day is not "real development."
Not all teams that do what you suggest write garbage code as the GP implied. I have worked a places with large garbage and excellent code bases.
The places that have garbage and years of technical expect far less from their devs because they can get far less. These are also the places that prevent tickets for refactoring and never let devs pay down technical debt, then they get mad when development is slow. They value the next piece of "functionality", even if it as simple as new entry in a menu more than they value their future. When there is so much technical debt that adding that menu entry takes a skilled developer 60 hours this becomes the norm instead of a problem to solve as a business.
I would rather not hire a developer familiar with such situations and failing to fix them. Whether the failure was their ability to recognize or communicate the problem doesn't matter the problem existed and they were near it and it wasn't fixed. If I start having those problems I want people who aggressively deal with technical problems in my technical positions.
I can of course be persuaded to hire such a person if they explain what they did and they seem highly competent. Perhaps, they did do all the right things, did go above and beyond and the culture was still so toxic as to prevent progress, I have been there before. But the interviewer would need to convince me and I think that is the point of an interview.
Determining if two intervals overlap is not a trivia question but a trivial question for a programmer and hiring people who can't do better than O(n²) probably is good only for really boring maintenance projects where the workload lags far behind Moore's law.
I'm not necessarily saying that such things don't exist, but not my cup of tea.
If someone has been doing maintenance programming in a company without excellent culture that values code quality - their brains start to rot pretty quickly.
Five years later, they know how to debug, estimate, work on a team, just not really develop anything from scratch or think critically.
If you want people to do real development, those are hard to come by. If what you really need is someone to maintain some bloated codebase and make it worse, but not too fast, then most people will do just fine.
Another thing is: what do you really want from a candidate? What led you to start asking them trivia questions in the first place?
The really good ones will be put off by trivia because it brings them zero value. If you ask questions that actually pertain to the field you're hiring for, it'll go over much better.
For example I applied to work at a major bank, and got asked a bunch of security questions, which exposed me not understanding how main in the middle attacks worked. The interviewee had requested that I go home, do a bit of research and email them the answer.
This brought them value because they found out that's an area I have little knowledge in, and it provided me with value because it pointed me in the right place to go research.
Trivia puzzles don't add value to anyone. Frankly if you're doing trivia and are upset by the response you're getting, a part of that is your fault :)