Innumeracy is the norm: I'd guess > 85% of people don't understand the concept of a function.
And they probably can code if they were working independently. Or they've done some classes, wathced some videos and think they understand it.
But when you add the pressure of an interview, your unpracticed skills fall apart. Also, you have to think on your feet to fill in the blanks in a question.
That's how it should be, because we're not hiring hobbyists; candidates need to be able to demonstrate that they're pros, and able to do so under the pressure of an interview.
I've done my share of phone screens who were flatly unqualified as developers. (Thankfully we've never had someone completely clueless land an in-person interview. That's also a disservice to the candidate as we should provide better guidance through the phone screen.)
Some of them are junior, possibly they lie on their resume and simply keep applying to job after job. That's the 99% that Joel wrote about.
You also occasionally get guys who were in management or similar roles and are looking to transition to being engineers. And I think these may have a similar problem to the senior engineers: they have lost the skill (or never had it) and are finding out the hard way.
It's not an analog. It's the actual skill up close. They should be explaining their thoughts as they go, and you're asking why they do A instead of B.
> I spend a minuscule fraction of my time writing algorithms in my daily practice
A good problem isn't simply an algorithm, but also tests how they break a problem down, how they compose a solution, how they think through engineering tradeoffs, and how they communicate all this to you.
Consider the difference between an artist and an amateur painter. That the artist has practiced brush strokes is not surprising, anyone can practice painting a lot. What really matters is the artist can take the image in their mind and composing it into a complete scene and then express it all that through their medium of choice.
> but problem solving and troubleshooting are way more valued skills in my group
Is that a good thing? If your group wrote better code, wouldn't they have less troubleshooting to do?
Yes, that's a tautology, but I've worked on code that was kludges on top of kludges. And while kludges can be inevitable, if they persist, it indicates the person doesn't have the mastery to see a better way to express a problem. That's a skill deficit.
When I'm analyzing someone's ability to code, I'm presenting it as a problem to solve. We solve problems by restating them in such a way that the solution falls naturally from the question.
The candidates who can do this well will put together well structured, coherent code, and my team will spend more time delivering features and less time troubleshooting.