For every task you need some minimal iq. Some tasks need higher iq than others. A programmer is someone who can at least do the least iq requiring task. He will fail on some more difficult tasks.
Iq just a standin for mental compute capacity.
Inventing Calculus was hard, but virtually anyone can learn to pass a Calculus test given enough time and incentives.
Also like you say, everyone won't pass calculus. Not even programmers.
Googling the original problem description will (for a novel formulation of the problem) not result in any advantage and implementing a standard algorithm will not work if you need n to be large for your application.
I will admit that it's a slightly contrived example ;)
I'd guess that at you get to at least a few percent if you count grad students, researchers, people working on performance critical stuff like GPU drivers, people working on state of the art tooling like Google internals or large OS libraries etc.
I've encountered concurrency challenges in my day-to-day work that have no cookie cutter solutions, are specific to my application (particularly in constraints and requirements), and I haven't even been able to fully convince myself of the correctness of my own solution, let alone contrive a way of systematically proving or even testing it.
On the other hand, programmers faced with solving technical challenges such as optimizing and approximating in the face of limited resource, where heuristics and intuition only discovered and learned through experience and trial-and-error (pattern building and "finding" at its best). These meta "design patterns" aren't found in any books yet, especially because they are pretty hard to articulate using the English language.
There is an inventive element to the sort of problem solving that good programmers perform that goes well beyond pasting solutions from StackOverflow. This is why duct tape and bubble gum cobbling of out-of-the-box solutions rarely works in practice (and why good engineers are paid so well). Clever hacks are actually pretty damn clever.
It's scary how many "best practices" I've only learned through building my own production systems and having actual users test what I've coded -- having already done a fair deal of sitting in classrooms being inundated with CS theory from the very minds who conceived it -- even years of building pet projects of my own haven't prepped me for the challenges I am encountering now.
That sounds like an accurate description of 95% of existent software in the world.
If the end user experience is anything better than catastrophic and it's making a profit, it's very hard to make anyone care. At best, there will be a big cleanup project that takes it from being totally incoherent and inefficient to being merely very stupid, but in a fairly consistent way.
The truly bad programmers destroy more than they create, making extra cleanup work for competent and productive programmers like me and everyone reading this.
On the other hand, that's an average. Most anyone can solve any individual problem once.
Apply the Intermediate Value Theorem to this example, as needed.
Working memory: Memorize things that surprise you. Then Try to understand why you were surprised. You don't have to memorize things you understand.