I didn't say that your "making applicants solve problems" was bad, just that the problems, especially the third, in this thread are bad.

"Unless you can make a convincing argument that the tests will decrease the fraction of qualified applicants, your post just smacks of arrogance and entitlement."

I believe that others on this thread have made such an argument. Again, I'm considering just the three problems on just this thread.

For how to sort through "1000 candidates", I do have an improvement: Don't use the test of this thread!

So, that takes us back to what we had last week.

You want to move forward from there? For that, I'm lost; I don't see the severe problem. I've been in computing for a long time and have interviewed and been interviewed, done projects and supervised projects. Once I had made some progress in my career, I never thought that recruiting or interviewing was very difficult.

Here is a way to improve the situation: Return to the early days of Java, when it first came out. Then the job ads were awash in requests for persons with "two years of Java experience". So, why not just call up Gosling since he was the only one who was qualified! That example is from a very general pattern: Pick some highly specific, improbable combination of 'skills' and demand that an employee have all those 'skills'. Nonsense. So, the first step forward is to quit recruiting for specific 'skills'. Just STOP it. Don't do it anymore. Drop it. Give it up.

Next, mostly what recruit for is general technical talent. A BS, MS, or more in math, physics, or computer science (in that order!) from a good university should do fine. If there is more evidence that the person is 'bright', then fine.

Next, recruit for some basic computer 'skills'. We're talking declare and allocate variables, assignment statements, if-then-else, do-while, and call-return. How difficult is that?

Next, recruit for interest in the work.

Next, recruit for general presentation of self.

Then, hired, expect that the person will get 'trained' on the job. The person will need a few months to become useful to the organization. The training can be self-taught, mentoring, routine supervising, some video materials, some presentations within the group, some training programs, maybe even with tests and grades, etc.

I've seen plenty of just routinely well qualified people dive into a new computer with a new operating system with new hardware devices with new programming languages, etc. and do just fine. E.g., when I was Chair of a college computing committee, I led an effort to get some new computing for the college. When it arrived, the existing staff jumped right in. One project was an application to contact, track, send mail, and get responses back from alumni. The guys just did it! Soon the college was sending boxes of mail daily to alumni. The software project quickly, uh, 'paid for itself'! Soon the university took over the project, rewrote it from just the high level description, and rolled it out to all the colleges on campus. Likely it again 'paid for itself'!

Where's the really big problem?

The main guy who did the alumni system? He worked for the college, but he didn't have a college degree and had had no courses in computer science. Not a problem.

I'm in the Mid Hudson Valley and hope to hire. I will be able to pick from people from community colleges, four year colleges, various development labs, and, of course, maybe Yorktown Heights. I don't see a problem.

If you see a problem, make sure you are not looking in a mirror.