These sorts of hiring filters are not something that can be solved for industry wide, because many developers don't want a common solution. Otherwise the solution is simple, because absolutely every other industry has solved this problem.
The solution is universal, objective, screen criteria backed by industry, which is also known as licensing. Using a test prove that developers have required knowledge, can read code (this is the big one), and can make certain basic decisions. In addition to testing also require documented experience from trusted and validated sources, continuing education, and some form of educational baseline (not necessary academic).
Absolutely every other industry has figured this out. Licensing isn't magic and doesn't create talent, but it is an excellent initial filter.
---
When looking at potential employers there are two things I look for now: subjectivity and selectivity. If the potential employer is not very about skills assessments I get nervous they are looking for the wrong qualities in applicants such that they may contain a lot of dead weight on their existing teams.
On the other hand if they are selective about skills, but that selection is purely subjective I go from feeling nervous to thinking they are phony. I get the feeling I am on a bad date that will end up as a broken marriage. The hiring party has absolutely no idea what they want, but they have some primitive notions about what they don't want. The common root cause of subjective nonsense is because the hiring party is insecure and seeks to qualify some level of comfort unrelated to the skills tested.
The reason why many developers don't want licensing is because many developers lack the skills necessary to complete such licensing criteria. They would be out of the job. This isn't true just of applicants or aspiring developers, but also true for many people performing hiring.
In a recent interview I had to prove I could read code in a language I have never written in before over the course of about 90 minutes, and it went very well. The goal was to prove I could quickly read/write original logic after getting over some basic syntax. The hiring party knew exactly what they wanted and were very clear in achievement criteria. Everything was pretty objective in that this process was a testing to see how far a candidate could get into a given problem in the time allotted and the effort that candidate would put into refactoring. All other technical qualities were ignored to reduce selective bias.