Applicative is nice.  I had to Google for hsc2hs. This is what I get for learning Haskell from the Haskell 98 Report and the Gentle Intro, and by writing programs.  I read and commented on RWH while it was in beta.    But I don't even know C.  As a kid, I got tripped up by = meaning "binds to, for now" instead of being an equivalence relation (though I didn't know that at the time).  As an adult, I just didn't care.  I studied Mathematics and Philosophy and learned how to write proofs in maybe 2 dozen logics and maybe 100 algebras.

This is a common problem in "rich" languages: There is more than one way to solve a problem, even if the algorithmic content is essentially the same.  The only sane way I have found to deal with this is to just ignore unfamiliar combinators and focus on a function definition's mathematical content, as much as possible.  In particular, every function is a many-to-one relation made from a "join" of types (in the lattice of types).  Haskell's rich type theory makes this easier than Perl or Lisp, for example.  You can often guess the right interpretation for a combinator merely by looking at its type, and mentally deriving its free theorem (or equivalently, characterizing its free function), which is easy with some practice.  Put another way, free theorems/functions are plumbing to be ignored.  The mathematically interesting parts of a function definition are the parts that aren't free, and have to be explicitly defined, often in terms of pairs of values.

This mathematical approach makes these sorts of litmus tests trivial, in the worst sense possible.  I'm not interested in memorizing hundreds or thousands of combinators.  That's what Google/Haddock/text books are for.  I had to Google to remember what FizzBuzz was, and I had to try GHCi to figure out of mod was named mod or %.  And with the right tools, I was able to solve it in under a minute.  It took about 10 seconds to get the logic down on paper, using arrows of the Categorical variety.  This does not make me a Haskell n00b.

These kinds of ideas are rather subversive in a business environment.  In my experience, businesses want to balance this sort of flexibility with maintaining a common body of knowledge.  This leads to those brutish patterns OO people seem to love.  At least functional patterns are expressive and often written in terms of free functions for some type or type class.

I remember an incident at a previous job, where a slightly more senior employee told me that I should be using the factory pattern instead of a map to traverse a list of "logic objects".  I gave him a little challenge.  I told him to just write up the supporting code (i.e., just the class names, imports, interfaces.  No implementations.) for the class hierarchy while I solved the problem my way.  It would be a race.  10 minutes later, I was done.  Half an hour later, he came by my desk, looked at the logic for traversing a list of hashes and writing a functor into the solution space, and agreed I was right.