That's because most "programmers" are utter crap. They don't know their tools. They don't know the language that the program in. They don't stay up-to-date.
I don't "know the tools" or "know the language" until I'm fucking using them. Then I google whatever the fuck it is I need to do using whatever the fuck it is some clown has put in front of me, RTFM, and get it done. Interviews test for the dumbest fucking shit. I for one generally don't care what fucking language or environment I'm in. With documentation (the fucking internet 99.9% of the time) learning how to do X in Y is trivial. Knowing that you need to do X instead of x is the trick. When you give an applicant a test to do X in Y, you're just testing if they know Y and maybe if they have memorized X. You're not finding out if they understand anything or can think critically.
They cannot reason about problems. 95% can't do the simplest of problems. You have to really deep before you find people who can talk about design principles, design by contract, etc.
When your "problems" are all pulled from the same "Shitty Questions and Tests for Shitty Interviews" site/book, what do you expect? If you're looking for people who talk about "design principles" or "design by contract", you're retarded. There are only three design principles: Correct, secure, and fast. There is only one design contract: Deliver X for $Y. If you don't understand what X is or why it's X and not x (even if the customer doesn't, or if the customer asks for X when they need x) then you're gonna have a bad time. See Oracle and IBM and anyone who's ever contracted with them.
You're getting mindless applicants because you're asking mindless questions. You cannot discern a competent programmer/developer from an incompetent one because you're looking for memorization, certifications, etc. Of course, the people conducting the interviews are typically not competent programmers/developers, so they don't know what else to look for or how else to evaluate applicants.