I helped with recruiting and interviewing for a Haskell team in the past and, in our case, it was substantially easier to hire for our roles compared to non-Has

I helped with recruiting and interviewing for a Haskell team in the past and, in our case, it was substantially easier to hire for our roles compared to non-Haskell teams in the same company and location (Target in Sunnyvale/remote). I figure there were two reasons for it: 1. A lot of people actively want to use Haskell, more than there are Haskell roles. Nobody is going to jump onto a generic Java role for the sake of using Java! 2. Language choice is a way to show rather than tell that you are willing to do something different and interesting. This ended up mattering even to non-Haskell candidates—I remember one very qualified OR expert told me he chose us over Google in part because the Haskell/PL angle to our approach sounded a lot more interesting. When I later moved to a more traditional data science team at Target, the difference in recruiting was pretty striking. I used to field qualified inbound candidates all the time, while the new team rarely got any; the recruiting pipeline was noticeably spottier; when we did get qualified candidates, they were more likely to reject our offer. Programming language choice wasn't the only difference between the teams, of course, but it was probably the most externally visible difference to candidates. With this experience, if I ever go start a new team or company, I'm going to use Haskell as a secret weapon to make hiring much easier. That goes against tech industry "common wisdom" but, as ever, common wisdom is far more common than wise.