I haven't really figured out the "why", but the observation is that people that start using the typical functional portions of a language (map/reduce/whatever) are more likely to get bogged down if the code doesn't do what they expect. And this is even for people that seem really good at it.

Debugging functional code is a bit different and not everyone picks up this skill. That's why functional code tends to be harder to debug and people who pick up this skill will take longer in debugging it.

The main reason is printing. All your code is inlined into a single expression. You can't really throw a print statement in there. With haskell it's even crazier as if you do manage to print your code it comes out backwards.

This is because creating the exact right abstraction for the job is time consuming. It may pay off later, and your typical FP person is fairly convinced that it will in terms of being able to be confident you got things right without having to test a lot of basic shit first (types tend to replace tests).

This is not suitable for the typical interview format.

That theory seems relatively sound. I'm digging more into functional programming again, because I think reading code needs to be easier than writing code, or at least reading code should be as easy as possible, and maybe it can meet that need.