I live-coded Haskell a couple of times at job interviews for non-Haskell positions where you were free to choose.<p>It’s fun because the interviewer often doesn’t grok the paradigm. In one case, I was asked to make a password generator, and I went with QuickCheck’s Gen, which lets me write a random generator of things without explicitly defining a single function (they’re all monads).<p>So you go from somehow describing the thing you want to make to “I’m done.” :-D
I remember I did an Advent of Code day 1 in Haskell a while back.<p>The meat of the code was a one liner. But opening a file, throwing away the first line and parsing a CSV took a lot more head scratching, especially if you've only ever done puzzles in Haskell.<p><i>Makes the hard things easy and the easy things hard</i>
Always fun to see this kind of Rosetta Code thing, feel like no matter the topic there's something to glean from reading!<p>That said: if I ever gave the palindrome question to a candidate (I haven't) and they pulled out a `reverse` library func/keyword we'd be encouraging them to do more.
Typical Haskell coding post with no mention of order or efficiency of the algorithm solutions. The thing is, even in basic coding quizes, if the interviewer is worth their salt, they will ask about how to improve the efficiency of the naive solutions first put forward, like the palindrome answer in this post.<p>What is the order of sumNToTotal?
Well, that fizlle implementation is not a good example of a great answer. It checks for the two conditions twice. At least I would use a where clause to define fizz and buzz.
> Silly job interview questions in Haskell.<p>Well, it's not clear to me why we're terming these as silly. They mostly seem simple, instead, to me.