Yeah, that seems like a weird rule to have. If anything, I’d want engineers to be excited about languages, tools and paradigms, even if they weren’t exact fits with the current stacks we’re using.
The whole article’s point is that these change, anyway. So those people they’re rejecting on this silly rule might eventually become the people they crave if functional programming becomes cool again at Culture Amp in 5 years.
That would be reasonable if the post put it that way, and said they ask lots of additional questions and back and forth to determine this specific thing.
But as it is stated, it just seems like an overly broad rule that will hurt more than it helps in the vast majority of cases.
> if functional programming becomes cool again at Culture Amp in 5 years
I think that's kind of the thing they're actively trying to avoid. They don't want one type of programming to become popular and have the team decide to spend $X and y months and switch to it because it results in increase in some nebulous programming productivity or whatever because they hired a bunch of z programming paradigm fans, and then later spend more money and time to switch to another thing etc etc when the importance of programming language or frameworks on the making money aspect of the business is not clear at all.
But functional programming might be the best choice for some project in the future. And this whole decision just seems like an overreaction.
To discount candidates entirely based on their excitement about one paradigm (saying nothing of their excitement of others) seems like it’s just pushing the needle to the other extreme.
(I'm a front end engineer at Culture Amp, and have been involved in hiring)
Perhaps the wording in the blog post is too strong, because people in this thread seem to be interpreting it as a hard rule. The wording was:
> When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.
When we do interviewers each person fills out a scorecard for the candidate with several criteria: things like technical skills, communication, UX thinking, interest in the company product/mission, etc.
Under "technical skills" I would usually have counted interest in Elm as a positive, as long as they weren't expecting to only write it. As I mentioned elsewhere in the thread, they'd also be likely to be contributing to Ruby on Rails codebases... so they better be open to, and maybe even excited by, different paradigms, because that's going to be part of the job.
Exactly. Idk if anyone here has used Culture Amp, but from what I've seen it could be built with any boring framework with a form builder (Django, Symfony, etc).
The whole article’s point is that these change, anyway. So those people they’re rejecting on this silly rule might eventually become the people they crave if functional programming becomes cool again at Culture Amp in 5 years.