Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very expensive.

Personally, I think being excited about a cool language is a mixed signal. An interest in technology is great, but on the clock that has to be thoroughly suppressed in favor of actual business needs and constraints. At home, I like fucking around with all sorts of stuff. At work, I'm a confirmed member of the Boring Technology Club. [1]

[1] https://boringtechnology.club/

If all you want is something to thin a stack of resumes why not be honest and just randomly throw out the required number?

Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. One kind of bad hire is the technology-lover who values their own preferences over the needs of the business.

E.g., a friend of mine took over a team with a couple of strong FP advocates on it. They had written a core tool in very FP-ish JS. They enjoyed the novelty of the greenfield work, but once it was down to just making the changes users needed, they got bored and moved on. The remaining part of the team tried picking it up, but it was too alien, either because of the FPness or just because the code was opaque. Either way, they eventually had to rewrite it.

Or personally, I have made a lot of good money coming in after some would be brain genius, ripping out their supposedly cutting edge work, and replacing it with something boring. I remember one place where a core part of a system was build on the 0.7 version of then-fashionable technology. Except it wasn't even 0.7 as released, but something with custom patches applied. None of the people there could maintain it. Looking at git blame and doing a little web searching, it turned out the developer responsible had then done a self-promoting conference talk about their amazing work, and then quit shortly thereafter. After I removed it and replace it with something much simpler, not only could the people there maintain it, but it worked better than before.

> Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down.

I'm certain you could increase the odds of a good hire in all sorts of other ways by seeking correlational stereotypes, but some of those (age, gender, race) would be seen as... very bad, possibly illegal, and some others (traditional-ness of first name, for example) would possibly also work but would be highly questionable. Heck, I bet you could find a correlation with whether or not the person used an AOL email address or not. What makes filtering by this stereotype correlation superior, ethically, to those other stereotype correlations? If "interest in new tech" is an immutable attribute of the person's personality (which it almost entirely likely is), then in both cases you're filtering based on immutable attributes, so they should be considered ethically equivalent on paper, where you have a lot of false negatives, but your "good hire" rate goes up.

> One kind of bad hire is the technology-lover who values their own preferences over the needs of the business.

So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see.

> So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see.

No, you have it exactly wrong. What you describe are good development practices that provide actual long term business value. What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features. Engineering is about solving problems, and technologies are tools to solve them.

> What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features.

How does that sentence show that, exactly? All it shows is that they're interested in new technologies. That says nothing about whether or not they are interested in "[solving] problems the business has like too many bugs, or slow runtime, or missing features". Those two are not mutually exclusive; one can certainly care about both.

Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.

> How does that sentence show that, exactly?

On its own, it doesn't. But if they don't show some interest in what the business is doing as well, it's a red flag, because they will probably end up building something the business doesn't want or need, or fulfill requirements without foresight or understanding into future business direction, but rather based on what they find stimulating (aka more complicated than necessary, at the limits of their understanding).

> Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.

Anybody working in a small team where you have embedded people from all aspects of the business and work together to make the company successful.

So, me, and everyone I'm interested in working with?

If you're in a giant company and the only satisfaction you can get from your work is the toys you get to play with, to me it's just a sign of corporate disfunction and misalignment between business and engineering.

But interestingly, some of those examples you cited are literally solutions to some of the problems you cited, so... For example, a language like Elixir that has "trivial concurrency and immutability" enables a test suite that can run across all of your cores at once and is deterministically guaranteed (assuming you watch how you touch shared mutable state outside that code, such as a database) to not step on itself while doing so. Compare this to any one of a number of mutable languages (such as Ruby) that claim concurrency but in actuality often contain deep software bugs that result in flagging, nondeterministic tests UNLESS they are run single-core. That is absolutely a solved engineering problem that then may prevent other mitigations like having to run the test suite across 25+ cloud machines (in single-core mode) and waiting 25 minutes for a test result before being able to continue, which then directly increases developer productivity.

Also, being interested in those 2 things is not mutually-exclusive. I LIKE that this is a tangible business result of a fundamental language design decision.

If you're after feedback, nothing in this post sounds like a tangible business result to me. It sounds like fun technical wizardry.

Being able to run a test suite in parallel on your own machine is massively more useful than having to run it across a bunch of machines in the cloud. First of all, clouds go down (the external-dependency problem), or become unavailable when Internet isn't available (and also cost extra money). Secondly, you get instant (more or less) feedback on whether you broke anything, and that allows you to maintain velocity without having to backpedal. Thirdly, if the suite is run concurrently in a deterministically-random fashion (where it outputs the seed before the suite starts), you can often identify reproducible concurrency bugs that will NOT (or be very unlikely to) show up on your multi-VM cloud test runner (which run all the tests single-threaded on separate machines). Fourthly, if we're talking a functional immutable language, those types of bugs (which are some of the worst and most costly of bugs to track down and fix... I know this from experience, a nondeterministic session-loss bug at Desk that it took me a month to fix likely lost thousands of customers, not to mention the cost of essentially benching me for a month plus the benching cost of the previous devs that took a stab at it and failed) are rarely found to begin with.

Every one of these leads to either more productive employees, lower ongoing costs, or happier customers. How are these not tangible business results?

I am too stuck in single thread front end integration tests to be able to relate. Are you actually talking about testing full stack or just some backend tech. We almost never have problems with our cloud testing, it is expensive. We need it to have some control over the front end work, benefit is that running the back end stuff is trivial and fast.

I have a design bias- I pretty much refuse to build anything for the front end that is not easily testable without using a headless browser as part of my test suite. Headless browser driving adds so much more resource consumption and time to the test suite over time that it defeats the entire purpose of a test suite, which is to (as quickly as possible) assess if any logic in the app has begun violating expectations, so you can proceed with building the next thing quickly without backpedaling and without waiting.

I completely understand that individual browsers may have this or that problem or idiosyncrasy and that may need to be tested but I'd put that in QA, not your official standard app test suite. At the most I'd test whether endpoints actually spit out HTML, CSS etc. but not actually check the rendering step. I do have a JS suite as part of my full test that uses jsdom to check DOM manipulation but it is only because it is not resource-intensive and runs fast.

Oh I agree with the potential technical benefits. I think the business justification is pretty weak, though.

The business benefits you listed are defensive. That is, if the business is doing well, those are things you might optimize for. The same way you'd, say, try and decrease power consumption.

There are companies where an order of magnitude decrease in ongoing costs opens allows a whole new kind of product. But order of magnitude increases in the things you just listed are rarely developer process improvements or refactors.

Customer happiness is a fun one. If you have a buggy or unreliable app, you'll frustrate customers (I am very aware of this, if you check my post history). You won't _make them happy_ just by building reliable software though.

As someone whose #1 priority is reliability right now – fixing bugs faster very low on the list of things that matter. The problems users have with our platform are a combination of the wrong architecture, and non existent tooling for customer communications.

Which gets back to the original post. We want to hire devs who can identify out what our users need most today, figure out what we can do about it (if we can at all), and then implement what makes sense.

I see your points, and were I at a company currently (I'm looking), I would prioritize the business-leading things, of course.

> #1 priority is reliability

Yeah, mine is too. (In fact, I think we're approaching a crisis of reliability out there, if we're not there already.) That's why I went with Elixir, and it's paid off so far. The only time the site's been down in years is due to my hosting provider, not me... (So of course I'm looking for another hosting provider...) I have to deal with the occasional 500 errors as well, which, as it turns out, are also largely due to my hosting provider and not my code (but sometimes my code...).

The thing I realized about reliability way too late is this: The utility of a service (or a person) to a person drops off VERY quickly if you dip below 99% reliability (or arguably, 99.9% reliability). Something (or someone) that is 90% reliable is practically useless, because it is bound to fail at the worst possible time. So in all the software I write, I focus on this, and in all my relationships with people (or orgs, or bosses, or my son, or my S.O.), I know that if I commit to them, I must be as reliable as humanly possible because the costs of every slip-up are huge and rise exponentially as they accrue.

An example of a service that is just unreliable enough to be a huge annoyance (which has also caused bad communication failures as well in my experience) is SMS. SMS failures are the worst.

If you can explain why you like them in terms of business value they provide, in the context of the specific problem this code is meant to solve, then I agree.

But without these, it's like hiring a construction worker who will use any excuse to use a backhoe, even when it isn't suitable, just because they love operating it. It's childish and unprofessional, and as an employer, even if you have full time backhoe work for them to do, you want to avoid hiring them, because they'll probably cause a lot of damage to your building site driving the backhoe everywhere when a wheelbarrow would have been more suitable.

Elixir is great for massively parallel web facing problems, and if you can explain it as a tool you have in your toolbox for solving this kind of problem then great. But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me.

I think the majority of programmers don't have that problem, especially with semi-regular discussion/contact.

In the past, when I really wanted to try something and the boss didn't agree with spending work time on it, I spent my weekend time on it (back before I had a kid- Seems like a luxury, now!). Most of the time, I came up with something I could demonstrate on the following Monday which got accepted. Sometimes, it didn't, or my hunch/effort was unsuccessful (but I wasn't unhappy because at least I tried).

> But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me.

uhhh, so Elixir is a general purpose language that solves everyday problems. and just happens to havethis phenomenal almost "no-code" solution to literally the problem you just presented, with Elixir Livebook.

...

The VM is 35 years old. The syntax is Algol inspired, the Elixir syntax is 10 years old, FP as a paradigm has been around since 1958.

It's not some new and shiny toy, it's simply unfamiliar to you.

> So basically you want to hire non-technology-lovers

That is pretty far from what I said. Try again?

Alright, I will.

> One kind of bad hire is the technology-lover who values their own preferences over the needs of the business.

OK. This is not a mutually-exclusive relationship. One can prioritize both of these; the best team player will prioritize the needs of the business (and the team) more, however. This to me seems like you're really addressing the problem of "vanity/primadonna devs" who are not team players, and not just devs who really like certain technologies which will possibly blind them.

I also think experience tempers this quite a bit. I've certainly had dev experiences where I became enamored with an idea or trendy tech, felt I absolutely had to implement it, and then ended up regretting it later. I think this happens a lot with younger devs and that's OK because that's how you learn. (Make sure they get assigned the mess cleanup when it doesn't work out though. LOL)

At hiring time, it can be very hard to tell the difference between "vanity/primadonna devs" and "devs who really like certain technologies which will possibly blind them". And even among the latter group, there are tradeoffs in hiring them. There are many reasonable places to set the dial on how much a hiring manager wants to take risks on that. But I maintain that, as with many other hiring criteria, erring on the side of caution is a reasonable choice. As I said, I think being excited about a cool language is a mixed signal.

> The remaining part of the team tried picking it up, but it was too alien, either because of the FPness or just because the code was opaque.

Sounds like they hired people unqualified to take over product maintenance.

If your engineers can’t wrap their head around ”FP-ish” JavaScript, they’re not exactly batting .300.

There’s plenty of code that can be so complicated that it becomes easier to rewrite versus understand. I worked with a coworkers who made the most absolutely spaghetti-like JS modules, insisting on event emitters and queues and stuff like that for even the most basic tasks. The result was an incomprehensible mishmash of events shooting from file to file to file. Touching how these events were handled in some way might destroy how they were interpreted for completely different tasks, it was wild. It’s very possible that the code in question wasn’t just opaque because it was “FP-ish”, giving the parent the benefit of the doubt.

Exactly. Code that is too asynchronous with lots of pubsub basically turns into GOTOs with data - there's no way to trace the execution step by step.

At least gotos generally tell you where they're going.

Depends on what you mean by "FP-ish". I never saw this code, but the way this was described to me as high church FP, the kind of people who really wanted to be working in an ivory tower FP language and so had coded as if that's what they were using.

I don't think it's unreasonable for average Javascript programmers to look at that and say, "WTF", the same way that they'd look at code from somebody who wrote C in Javascript.

I feel like we just went back from “it doesn’t matter need to filter somehow” back to “it matters”.

Of course you blindly throw out 30% of the resumes -- you want to filter out the unlucky candidates. :P

I totally agree. I engraved Angular 2016 in our Tech Stack. Fast forward 7 years now, and we are on Angular 14.

Accomplishments so far? Large and stable platform as well as a Low Code Editor on top of it. We systematically componenized every useful piece of Frontend there was and evolved from a library into a platform, while other departments jumped ship every now and then (jQuery, React, Vue, etc.). After years of resistance all finally joined out platform, because it is fast, stable, convenient.

Moral of the story: consistency is everything. A tool is a tool.

For sure. I used to be a real tech snob. And I still like experimenting. But I've had to admit that the particular technology used just doesn't make the difference I would like it to. E.g., PHP is a "fractal of bad design" [1], but Facebook seems to be an ok business. Or Javascript was clearly a frightful hack job to start, barely adequate for mouse rollovers and a little form validation, but now you see plenty of companies doing fine using it front end and back. These days I would much rather have a good team and a good culture than my favorite technology.

[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Facebook hired dedicated people to invent their own hack-language over PHP to deal with PHPs problems.

Sure, a business can succeed with a crappy language. But that doesn't mean the language has no impact, otherwise Facebook would have just sticked to it.

I don't believe that I said language had no impact. What I said was, "the particular technology used just doesn't make the difference I would like it to".

I guess I misinterpreted it, sorry for that.

Sounds more like it was about consistency rather than about boring vs. exciting technology.

Because 1.) Angular was still "the hot shit" at the time, 2.) React was already there, so you could have chosen that as well and it would have still been here.

Agree completely. I prefer react over angular, but when you have everyone working with the same tech stack, and all of your apps look the same, it's very easy to always be productive. How does service x work? Oh, just like the last 3 I worked on. Context switching isn't just expensive in the short term, it's expensive over weeks and months for these kinds of decisions.

> Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very expensive.

I think it depends on how you define "fine". Perhaps "fine" from the hiring company, but it externalizes the cost of wasted job leads for candidates.

If you think that a technology/language/etc is cool and better than the rest but it is not as common as <mainstream thing>, of course you’d be excited to learn that a company is using it.

If you’re a company that chose a very niche language because <a number of reasons> and discard an applicant because he likes the same very reasons, LOL, you’re a bunch of idiots

Well, they're moving away from said language, so why would they want to hire someone who joined because they liked Elm but then doesn't get to use Elm at work? They're more likely to leave the company than someone who doesn't really care so particularly about Elm (or whatever language or tool it may be). So in OP's case, it's a sound business decision.

Adversarial take: if your company says it does Elm, then hires people (who took Elm as part of the decision of joining) and then decides to stop using Elm, why should we push the guilt of leaving to the employee? I mean, it looks a bit like bait-and-switch, and "We the company altered the deal, pray we don't alter it any further".

How is that employees should be loyal to any decision upper management does? What's the limit? What if the company decides to go into JBoss/JQuery? What if the company decides to stop doing software altogether? What if the company becomes a mercenary army a-la-Wagner? Where do we place the line between employee is guilty for not continuing/company is guilty for changing everything that matters?

I think you're reading guilt where there is none. I just mentioned that it's a sound business decision, as well as a better decision for the employee who likes Elm, to not hire people who like using a tool your company no longer uses. There's no guilt on either side, it's just pragmatism.

I don't believe that's what they said.

I mean it depends, right? There are several technologies out there that are fantastic because they are less annoying, have fewer footguns, easy to debug, easy to read, good tooling (docs, tests, package management), and respect the programmer's sanity. Is it wrong to only want to work with such systems? If some company rejects me because I'm a tech stack fanboy without asking and understanding why I care about the stacks that I do, that means they don't respect my sanity. Hate to say it, but most "boring" technologies with a legacy from, say, pre-2000-ish, cared zero about those things.

So, great. Buh-bye.

Nb: many technologies post-2k also don't care about those things. So yeah, don't be shiny new on those either.

Sure, but you're now evaluating the technology in business terms. That's very different than somebody who loves the ideas of a language. I don't want to start a language war, so I won't name one. But consider all the developers who were very excited about "blockchain" not because it improved anything practical for their projects, but because it was a hot concept.

The point is there are languages where the "ideas" of the language are these "business" ideas. Technical choices can also lead to good/bad developer ergonomics.

Do you really believe that there's an experienced developer who doesn't believe, "Technical choices can also lead to good/bad developer ergonomics"? Maybe try assuming I already know the basics of the field.

The plenty of fish on the sea argument don't hold if you enforce a systematic bias.

This is the right attitude. I make a conscious effort to find reasons not to use a technology in excited about at work because my excitement otherwise will bias the decision in the other direction.

It's funny because that slide shows why we use Elixir. With the clustering BEAM offers out of the box we've been able to eliminate things like memcached, redis, and rabbitmq from our production environment.

But most people wouldn't call Elixir "boring tech".

> But most people wouldn't call Elixir "boring tech".

In the sense most people mean boring, Haskell with sum types, pattern matching, and pure functions is the most boring someone could ever hope to get.

However, most people wouldn't consider that boring either :)

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.

I think the idea is you want to avoid hiring the person who will quit if you eventually stop using their pet technology.

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.

The previous couple sentences before what your parent quoted make this clearer IMO. e.g. they don't want hires to be "purely technology focused".

> 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).

“Culture fit” always seems like a cover for decisions that are arbitrary or just personal biases…. or in some cases bigotry.

He doesn't go into much detail here but what I _imagined_ he meant was that if someone came to an interview excited about Elm but knew nothing about the company, that would be a strike against them. If someone came excited about Elm _and_ was interested in the company's product that was fine.

But this is just me filling in the blanks as I think they should be filled in. It'd be great to see him spell this out a bit more.

> but knew nothing about the company

How much does anyone really know about a company they don’t work at?

It's just ego imo.

> If someone came excited about Elm _and_ was interested in the company's product that was fine.

We're talking about a company that makes workplace engagement surveys. I have trouble imagining anyone is actually truly excited about that product. No 5 year olds ever said that they want to grow up to write engagement surveys. They aren't saving the world.

And that's ok. Most products aren't very exciting when you get right down to it. One of the most toxic beliefs in tech companies is that everyone should be obsessed with the product.

I had a leader once who told us outright any mention that Haskell was a motivation for the job is a red flag. It was a Haskel codebase. Turns out we failed to hire basically anyone (most were all yes but a single no from the leader) and then the leader pushed us to move off Haskell citing difficulty hiring and that he had hired people in another office who didn't know or want to learn Haskell. Dirty tactics.

> I had a leader once who told us outright any mention that Haskell was a motivation for the job is a red flag.

> then the leader pushed us to move off Haskell citing difficulty hiring and that he had hired people in another office who didn't know or want to learn Haskell. Dirty tactics.

Yeah, that was planned from the beginning.

Oh definitely. There was even more bad actor nonsense too but I don't wanna say to much or else I sky demask myself. But I promptly quit and the dude went from buttering me up to to make me stay to insulting my new job in the exit interview real quick once I made it clear I had no interest in being his employee.

If my current employer hired this dude as VPE, I would immediate quit. Just an asshole.

Be honest though, I'd say a good 95% of jobs are literally something I could give 2 shits about or I have absolutely 0 interest in what their core offering is. I have rarely worked in a place where I was "excited" about the company or its mission.

Sometimes the tech stack itself IS the interesting part of the job or there were interesting problems to solve, but the company itself?

Sorry, I honestly don't care outside of the paycheck.

> If someone came excited about Elm _and_ was interested in the company's product that was fine.

Why hold people interested in Elm to a higher bar than the 90+% of hires who don't care about the company they work for and just work for $$$?

I'm not suggesting people have to care deeply about the company they work at. I'm just saying that I'd expect people to come to an interview having read the company website and job description. That's all.

(I work at Culture Amp)

In our interviews one of the things we look for is people who care about our mission (improving workplace cultures, basically). Its not a requirement but it is one of the factors when it comes to making a decision, particularly if we have more qualified candidates than roles.

> If someone came excited about Elm _and_ was interested in the company's product that was fine.

I'd even say if someone is excited about Elm _and_ was interested in making a great quality product (great UX, accessible, performant, maintainable etc.) that would also be a good fit.

I also mentioned above that the engineers we hired to work on features that happened to have Elm front ends would have been working on Ruby on Rails backends most of the time, and we generally expected engineers to be willing to jump into both sides of the stack, even if they specialised in one or the other. A person who is really excited about functional programming and joining only for the chance to work in functional programming languages might end up grating against working in a rails codebase. That's the sort of practical thing we were trying to avoid. (The same would be true today for candidates who are super excited about TS / React / Next.js - they're still going to be expected to occasionally jump into whatever backend stack their team is using).

My take on this is that he wants to avoid "science projects" being produced rather than client work being finished.

It does feel like a landmine they've set up, perhaps another benefit for them of moving to React is that they can stop worrying about it?

I've seen a lot of companies that superficially resemble Culture Amp. I've seen one that uses Elm. I'm probably going to come in talking about Elm.

I have some sports-related decoration in my living room. It would be a weird experience for someone if they came in, saw it, started discussing sports, and I was put off by that.

Agreed. It's almost as baffling as a company rejecting an applicant for mentioning they like to make money.

I interviewed somewhere once and mentioned that I did some projects in Erlang and learned a bit about functional programming. The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer.

This was one of my first tech interviews after spending nights and weekends self-teaching. I only mentioned this at all because the dudes LinkedIn said he was involved with some Erlang orgs.

Anyway, I did take a non-eng role there, and it was easily the worst and most abusive (like verbally abusive, psychological abusive, generally fucked up) places I've ever worked. Eventually i got my first engineering gig at a more humane company and have been doing great since

I learned recently that the other company went to zero. Good riddance (though I am bummed for folks who lost their jobs)

I've recently had an interviewer tell me that "Erlang is an academic language" and promptly stop the conversation after that. That's in a company that was attempting to make distributed applications easier to write.

This was both:

- factually wrong;

- a bright red flag that the company doesn't know their own domain as well as they think/claim;

- a bright red flag that their scope is much more limited than what they claim in the job description.

:shrug:

"You wouldn't perchance know what the 'Er' in 'Erlang' is short for, would you?"

Oooooh!! I know this one! Ericsson!

Do I get a prize?

I personally don't mind academic.

However, part of my response was that Ericsson had been using it industrially since the 90s, and that in fact Erlang was actually less academic than Python or Go. The recruiter handwaved this as "well, it's an academic language".

You totally dodged a bullet.

Even if the company despises Erlang for whatever reasons, it's still very valuable for them to examine and be educated about it. Erlang makes tradeoffs for X optimizing for Y, we'll choose a different tradeoff since we're optimizing for Z.

Once I interviewed at a company with many competitors. I continually asked "how will this company succeed while the competitors have a ten year head start? What choices do we make that the others didn't?". I got blank stares. Literally nobody was interested in examining the competitive landscape.

Oh, I've had that, too. I've interviewed with a few companies that create products that are literally years of research behind their (sometimes free) competitors. And don't realize, typically because they don't have the skill to even comprehend the difference.

And for fun, all these companies interviewed me on cloud development, rather than on their core offering, despite the fact that I actually happen to know a thing or two about said branch (i.e. I have both a PhD and commercial experience in the domain).

One of the things that makes Erlang so practical is that it is not an academic language.

I’m guessing it’s probably the prolog-like syntax that gets it thrown in to that category by some. I’ve never heard someone consider Elixir “academic”.

Well, it tells you those things about that specific interviewer.

I would just stress to folks that red flags go both ways. If the work environment seems toxic from your experience as a candidate, chances are it will only get worse once you join.

That's not both ways. That's exactly what a red flag in interviewing means.

Employers look for red flags in candidates, candidates should do the same. My apologies for confusing you.

1) "The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer."

This sort of person intends to sleep in the bed that they make, so best to leave them to it.

On the other hand...

2) I'm an Elixir guy looking for work for a few months now. Should I be concerned that this is the perception out there? IS this the perception out there?

I'd say that it's all in the eye of the beholder.

Not so long ago, everything FP or reactive programming was considered academic. Heck, even virtual machines, garbage-collectors, threads or distributed programming were considered academic. These days, who doesn't use most of these bricks?

Which means... sadly, it means that I have no clue what the future holds for Elixir, or Erlang, or any technology that is perhaps a bit too much in advance on its time.

I'm endlessly fascinated by the strong opinions people in software develop about tooling. I never saw it with such intensity anywhere else... I'd like to get more into that someday. Maybe because we use these tools with our minds so it's a very intimate thing. Maybe because people find hard to learn a set of tools due to so much of foundational knowledge behind it having been abstracted away so they develop mental defenses against other sets of tools as a rationalization of why they don't wanna lose the sunk cost...

> Maybe because we use these tools with our minds so it's a very intimate thing. Maybe because people find hard to learn a set of tools due to so much of foundational knowledge behind it having been abstracted away so they develop mental defenses against other sets of tools as a rationalization of why they don't wanna lose the sunk cost

It is both of those things, I think, and more. For me, at least in Elixir's case having come from Ruby, it is also that I am acutely aware that Elixir virtually eliminates entire classes of bugs that in some cases took me months to run down in Ruby.

I don’t think it’s a SWE thing at all. Just bog standard human behavior.

People like consistency. They hate change. If they get used to a specific tool or way of doing things, I’m pretty sure you’ll find similar behaviors.

The key is time spent with a tool. I would expect if you took away an engineer’s favorite CAD software, even if it costs many thousands of dollars, you’d see a similar reaction. Would they be able to do their job with another tool? Certainly. Will you hear about it? Even more certain.

I moved away from Rails and then back to it because I really wanted to join a particular company. The answer to 2 is somewhat yes, but Elixir no longer counts. People "build" with Elixir, it's the builders FP. This isn't my opinion (I try not to have one on this subject, fed of language snipes) just the general attitude I've noticed.

> Elixir, it's the builders FP

I'm really glad to hear that, because to me it does seem like Elixir is the FPL that is closest to satisfying a GSD mentality and not getting caught up in too many interesting rabbit holes.

We (Ockam.io) are definitely building very real and critical things with Elixir. We filled our remaining open position for it last week though so we’re not currently hiring for an Elixir person. Just wanted to point out there’s definitely companies out there that value it for non-academic reasons.

What was your method for hiring; were you looking for Elixir people who can come in hot, or people interested in it specifically that want to learn, or just "good software people" who'd be WILLING to learn it, or something else entirely?

I wasn’t the hiring manager for those roles, so I’m not 100% sure. If by “can come in hot” you mean people with existing Elixir experience, then based on who we hired I’d say that previous experience would have been required.

What does GSD mean, please?

Get shit done

Answered already, but in $previousjob we had a team named that, for the reason given. I thought it was kind of clever but unique - 3 jobs hence I work for another company that has the same, so maybe more ubiquitous than I'd thought.

I find being a "builder's FP" more true of something like Rust than Elixir, in my experience. This is mainly due to the lack of static and algebraic types in Elixir, which makes debugging very difficult, as well as more annoying to reason about the problem domain, because you can't represent it in types as well.

> lack of static and algebraic types in Elixir, which makes debugging very difficult

In about 6 years of working with Elixir, I've found it easier to debug than pretty much every other language I've ever worked in. But to be fair, I've mostly been working on code I've written myself in that time (although you'd be surprised what you forget in a year and then go back to).

You can also add typespecs; I know it's opt-in, but it's something, and it will get checked.

Algebraic types are orthogonal to functional programming.

Functional Programing can be static or dynamic.

Also, Rust isn't an FP language, per say, it has way more in common with the imperative programming paradigm with some ergonomics lifted from the ML family of languages, specifically around it's type systems.

I think people who are earnest about the sentiment aren't screening specific languages. They're trying to find people who think hard about business problems and follow with implementation.

We do this. Our hiring process is impossible to pass for people who fixate on implementation. We have people do a simulated building exercise, and the developers that do well let the user needs drive the implementation.

We think we've noticed a correlation between some dev communities and people who lead with implementation. We've seen a little of this with Elixir, but I'm not really worried about it. We've found a number of people who really enjoy Elixir that are also user-first.

When you talk to a manager, you should lead that you are interested in building great products. Even if my company is using functional technologies, I want people who are professionally interested in learning business domains. It's great that you're interested in functional programming, but my fear is that I will hire someone who puts great effort into changing the culture to use avant-garde tech in a place that doesn't provide return on investment. (Or worse, drags us into a culture of malcontent!)

That isn't to say Erlang, but I've also seen an organization that struggled to hire because it couldn't find enough Clojure expertise and saw good developers onboard slowly because they had to learn domain, language, and paradigm in a practical environment.

There is a secondary worry in hiring people who present as tech-forward: if we need to make pragmatic decisions that mean using industry standard technology, will they leave out of frustration? If we need to make a decision to leave some technical debt there for business reasons and address it later, will this cause difficulties with the developer? ____

(That said, I know a fair number of good developers who have struggled to find work in this environment. It has nothing to do with Elixir.)

> I want people who are professionally interested in learning business domains

You can want in one hand, as the saying goes. If you select for people that care about business domains you're more likely selecting people good at feigning interest in your business(aka liars, or otherwise honest people who need to eat). Even if you get what you want you won't do well in the long run. I rarely see people who aren't passionate about technology avoid making a mess of it.

I have genuine interest in both. I build things because it's awesome to make someone's day better. It's a demotivator for me to put out software that doesn't work well. Technology is a means to that goal.

Because I'm wired that way, it's a lot easier to find people who are also wired that way. But I can say that there are absolutely places for people who are wired to be passionate for technology for its own sake. (Some of Fintech and adtech is a good place, for example.)

And if you feel you need to lie to work in a place with a product driven culture, then great. But don't be disappointed when the job is listening to calls with users and your conversations are around "which of these approaches will make the user's life better?" and there are technology radars that are justified by users' needs.

What company. Worth avoiding.

> Anyway, I did take a non-eng role there, and it was easily the worst and most abusive (like verbally abusive, psychological abusive, generally fucked up) places I've ever worked.

Sorry this happened, but it’s a good lesson for everyone: If interviewers do anything resembling “negging” in an interview, they’re trying to push your limits and see how submissive you’ll be.

The founder may not have cared about Erlang. He just wanted something to attack you with.

Some people think that lightly insulting people is a way to get them to work hard to prove their worth. It does work on people for a while, until they realize they’re being used and abused.

Is there something about Erlang itself that makes it an attractive FP language for you, or is it the environment (Beam, OTP)? As a web dev, I find the performance of the system and concept of the actor model appealing and interesting, although admittedly I lack an in-depth understanding. I found the language to be too high a barrier though. This includes Elixir. http://efene.org/ looked promising, but when I tried to install it, I had some issue with something being outdated. Gleam is the next thing to try, although the more I read about it the less I understand, lol.

I've done some toy Elixir things and I really like it; not enough to get hired but enough to like the shiny packaging. (It might be that shiny all the way down, I just don't have the experience to say.)

Gleam though... that looks more to my liking _syntax_ wise. Familiarity more than anything, but might try some toy stuff on it soon.

BEAM interests me immensely from a user standpoint; I'm just wondering how much time it has in the world vs. containerization and orchestration.

Haven't heard of efene yet; thanks for that. Now my Sunday's ruined =D

> The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer.

Man, that would have left me with such a bad impression that I would have ended it right there, no matter the role.

That said, I've taken jobs where I had to in order to eat, and at least one of them ended up being shit, so I empathise.

Yeah I almost cried partly because it was so unexpected, and partly because I was so desperate dealing with lots of housing instability, and this was one of the first companies that even reached out to me for an interview. I wish I had more of a spine back then because that ended up being hardly the worst of it

In a way I'm glad to have gone through it -- I think it's helped me to be a lot more compassionate in situations when I have any kind of leverage over another person, and it taught me precisely all the wrong ways to treat people in general. Probably most significantly, it showed me that there are major costs in committing to fucked up people, costs that might not be obvious at first. Like you can think you're aware what you're getting yourself into, you can tell yourself it's just for a paycheck, but if they get inside your head at all, you might be dealing with that shit for years. And you can be sure that predators like that are all about getting inside your head

It also seems like the type of bullshit people would spout when asked "why do you want to work here". (Real answer is because i like money, but you can't say that in an interview, and talking about language is generally pretty safe)

To be honest, I don't ask this question, because of this. Why ask people to lie? Better talk about their interest and how we can both benefit from aligning them in the context of our tech stack.

There are thousands of companies that pay money. Why do you want to work here? Are you literally applying to every company you see a listing for? No.

It is a job, not a religion. I want to work at X due to some combination of having skills that match their needs, room for growth, reasonable work culture and reasonable compensation. Just like everyone else who applies. I am not going to have some deep seated emotional attachment to the company, and i am definitely not going to have it at the interview stage. For that matter i might not have even heard of the company before seeing their job advert. My knowledge of what the company is really like at this stage of the game is very limited.

Thousands of companies that have openings for positions that match your skills, that advertise at a time when you are looking for a job, and that are roughly within your reach (geographically or sponsoring a visa)? I don't believe you.

>Why do you want to work here?

Because it's 30 minutes from where I live and the office seems friendly. Most people in the world choose their job for prosaic reasons and because they need to pay rent, they're not on some heroes journey. Employers in the software world need to stop it with the self-inflated ego. You have firms out there who write ad software for billboards and they'll ask you whether you truly believe in their mission during an interview

Especially since it's Elm. How many people would have any idea how to even use it & not mention that they're excited by it an interview? Counting that against someone is probably an even worse interview practice than being overly reliant on leetcode. And I hate leetcode driven interviews.

After ten years of using Scala, I think if I was running a Scala team, the safest thing would be to hire people who are not excited about Scala. Like it, yes, but not be super pumped. Developers who are primarily motivated by the excitement of learning new technology tend to write code that commits everyone around them to learning just as much, just as fast, which obstructs and pisses off developers who are primarily motivated by getting shit done. A team needs to strike a healthy balance between powering up with new ideas and getting shit done, and having people in the team who skew to one side too much to either side of that balance is a recipe for conflict. Eventually people will leave, often highly productive get-shit-done people, unless you fire the disruptors first.

I’ve had the good fortune to work at a small place where the understanding between R&D disruptor types and get-shit-done GSD types was pretty good. When R&D types contain themselves/keep the playground from spilling over until whatever they’re playing with is ready/explored, and the GSD types don’t bulldoze the playground and let it feed them new tools/approaches/ideas when ready, it’s like an organization level flow state. Wish I had a formula for how to replicate that, is magical.

In my experience, the failure mode for "GSD" is more likely a thoughtless approach of pumping out code, without consideration for efficiency or effectiveness towards providing value.

As an ex-Scala developer I feel like Scala is also the worst language in this regard, even compared to more academic languages. At least Haskell is somewhat prescriptive; in Scala people continually invent new ways to do the same thing. How many iterations of dependency injection or IO are we at now?

Can’t be more than Java has :p. New libraries and ways of doing things are great for the ecosystem.

Ruby is another language where I wouldn't want an unrestrained/undisciplined amount of smart/clever code.

My impression of Scala from a few years ago was that the language itself was so flexible (ranging from 'not quite Java' to 'not quite Haskell'), that you'd really want strict adherence to a particular style (or set of features) for a codebase to have hope of being maintainable.

I love and hate ruby for this reason. I'm working in it now, and it does allow some really fast-to-ship coding, but some of the LargeBrainedOne's framework stuff is so weirdly overly abstracted and metaprogramming'd ...

They'll write 500 lines of inscrutable framework code to save having to write 5 lines of boilerplate 3 or 4 times.

What are you doing running a company that uses Scala without having people who largely know the stuff already, though? Regardless of how quickly some newbie learns, the senior folks should already know all that stuff, or at least most of it. If they don't, that's the actual problem.

As someone who works on a legacy scala codebase, Scala's an easy language to get into this situation with.

Scala's flexible enough that the old lisp pitfalls apply (though not nearly to the extent of lisp). That is to say, learning the language itself doesn't necessarily mean you're going to have any sort of grasp on a particular codebase, or even a different part of the same codebase.

There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages.

If you're not careful, your bus-factor is 1 and even the other seniors won't have any idea what's going on right away.

> There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages.

This is main point which, more often than not, turns out to be a negative for Scala (there could be specific circumstances where this may be a big positive but, usually not).

The rule of thumb for me for Scala code is, only follow constructs/idioms/style mentioned in the Scala Book[0]. Most of the time, everything else is unnecessary trouble.

[0]: https://docs.scala-lang.org/overviews/scala-book/introductio...

> there could be specific circumstances where this may be a big positive but, usually not

I mean, I think that those circumstances would be a solo passion project.

I still think scala is a beautiful and expressive language. But I think that expressiveness actually inhibits collaboration. If you're expressing novel thoughts in a novel way, you've added syntactic overhead to the already significant conceptual overhead.

So, yeah. Quite personally rewarding, but I can't recommend it for a work project in good faith after having worked in it. Enterprise projects should probably use java/kotlin if they want to be on the jvm, or go/python/js if they don't.

I see this as true generally. Managers want people who seem super excited, but people who treat the job as mundane often seem to get the best results.

There is the other end of the spectrum though, where people who overwhelmingly focus on getting it done, quite often, don't apply the requisite care to the code. I encountered an actual example of this, where devs were copy pasting hundreds of lines of code, no functions/methods with liberal hardcoding to scores of scripts. Each had the same warts since they were all copies. They all got the shit done while nobody bothered to clean up the mess into reusable chunks.

As a new member of the team, I took the opportunity to cleanup when I got a similar assignment, which took an extra day. Subsequently when another dev had to do a similar task, he used my setup and basically had to make changes in 3 config lines which took a minuscule fraction of what he would have spent doing copy/paste and modifications. He was happy and I was puzzled why none of them bothered to do it for so long; my cleanup wasn't rocket science and any of them could have done it.

As with all things, balance is the key.

> getting shit done

A team that gets shit done will later look back and see that what they've done is shit.

I run an OCaml project, but I would reject interview candidates who say they are primarily interested in the project because of OCaml. It's definitely a negative factor in the evaluation. I don't need someone adding baroque functional programming purity into a working project with real customers and regular developers. Plus there's a vast amount of C code which is not going anywhere, so I assume they would hate dealing with that.

One can enjoy OCaml while also being proficient in C and C++. I don't follow your logic.

It's more that it's a negative indicator. From time to time when we advertise a job we get a candidate straight from a university research background who can't wait to tell us how they love functional programming. We always pass on these.

There's a well-known phenomenon where a person who has just learned a programming language will tend to write code that resembles the idioms of a different language that they have more exprience with, until they learn to write properly idiomatic code in the new language. For example, someone coming to Python from Java might write so-called "Java-flavored-Python" until they become more familiar with how things are generally done by experienced Python coders.

Your comment comes across to me as "I run a project written in C-flavored-OCaml, and the last thing I want is for someone to come along and pollute it with properly idiomatic OCaml". Because otherwise, if you had good reasons to choose that language, and your code takes advantage of the language's strengths, wouldn't the code already be "baroque" to some degree? Why would you assume a new person would make it worse?

That's not what it sounds like to me at all. To me it sounds like they have some FFI into C and that OCaml may just be a part of the larger project. There is nothing that indicates that they write "C-flavored-OCaml."

You can look at the project yourself: https://github.com/libguestfs/virt-v2v I've been writing OCaml for 20+ years and C for 40 years, and other contributors have similar decades-long experience in programming.

I'd likely fail that filter, but not for love of baroque fp purity. my career has largely tended to be at the bottom of the stack, building the bricks that other team members use to build features, and I would be excited about ocaml because I think it gives you good tools to build solid and composable components. I would also do good work in the C part of the codebase if needed, I just wouldn't be excited about getting to work in C.

Hiring rules in general are bizarre.

I worked at a place that doesn't hire developers who use Visual Studio!

Another only hired ugly and disabled women for specific jobs to combat male sexual misconduct. Of course, an "ugly, crippled woman" got pregnant by a co-worker in no time.

Conflating getting pregnant and sexual misconduct is a weird take.

To whom it may concern: being respectful when attracted by someone is a thing.

The company does not accept sex between employees, pregnancy is irrelevant, relevant only to find out the relationship between employees.

I thought that same thing.

Besides, it wasn't liking a particular _language_ they took as a bad sign, it was _functional programming_.

If you like functional programming, and you encounter a candidate who also likes it, and you consider that a red flag ... that seems highly irrational and inconsistent.

(Not trying to sound combative. I appreciate the original post! Just being candid about something that sounds odd to me).

Edit: I would bet there's more context that was out of scope for the original post. I would not be surprised if it were much more than just "liking functional programming." If someone is overly zealous to the point where you might wonder if they'd start an uprising or storm off in a rage if asked to do anything other than functional programming (or anything else for that matter), that would be a red flag.

I think it's the over-zealous part. If someone can't name a few cons of some technology relative to its competitors, they probably don't have a balanced perspective of when it should be used and when not.

My thoughts exactly when reading that.

something I always remember from my brief time lurking on comp.lang.lisp is a post saying a really good language is one that would get you to take a job just because you would get to work in it. it's the pleasure of using a tool that fits well in your hand and works with you to get the job done.

I’d wager some big bucks that this never actually happened. Sounds super made up. No way they were like “Well Shelly really knows what she’s talking about, but too bad she’s excited about functional programming… that’s just so 2015.”

It’s not uncommon.

I’ve twenty plus years experience building software on the JVM. From EJB’s of early 2000s to original Spring, then the more recent Spring Boot, a plethora of other JVM tooling. Then I’ve used various languages on top of the JVM, Groovy, Clojure, ETA, Scala. I haven’t used Kotlin only because not had a role that needed it. Then I have a list of non JVM languages, frontend stacks and sysadmin/cloud or as they like to call it DevOps

Scala has been my JVM language of choice for the past ten years.

When I was last applying for jobs my experience with Scala seemed like it was a huge negative for the companies I interviewed at. It was “you’re one of them” and things got frosty after mentioning I’m reasonably experienced in Scala and its functional programming libraries and enjoy it as find I have less bugs.

If I removed Scala from my cv and never mentioned it I got a much more positive experience.

Some of the roles I didn’t mind it going frosty. My red flag radar went up aswell and I got the sense of big balls of mud and I’d probably hate it but needed a job. Some it was a huge disappointment, exciting company, exciting projects, perfect fit skills wise but I was seen as a Scala developer not a great fit for Kotlin as excited as I was to use it because of the companies projects.

Not sure what I’m trying to say but this “not good fit” attitude doesn’t seem uncommon if you have used specific languages/tools/things people interviewing you don’t like or didn’t grok. Tech talks a lot about diversity which is mostly virtue signaling and forget diversity of minds is also good.

I think the original point wasn't about it being uncommon but about it being a significantly problematic rule.

> It was “you’re one of them” and things got frosty after mentioning I’m reasonably experienced in Scala and its functional programming libraries and enjoy it as find I have less bugs.

You made people feel bad for not questioning their preconcieved notions... that's a nono! :(

It’s best not to hire an employee who is excited about anything. These people are running high on emotions and will almost certainly be a troublemaker later. Better to hire a professional who is ready to work and is cautious about rocking the boat.

It's always seemed to me like one of the main perks of having your company use a weirder functional language was the ability to attract talent that preferred it to more standard choices. An experienced developer might be willing to actually take a pay cut if it means using a favorite language rather than grinding out another Python/Typescript CRUD app or what have you.

I understand where the author is coming from, but I think having a preference and being excited about a tool your going to be working with all day is a reasonable thing, and it's ok if developers are excited about a technology for its own sake as long as they can make that compatible with continuing to make the business work.

As they said, it's an indication not a "rule".

Anecdotally in interviews, it seems that most people that say that they like functional programming, tend to like the idealized notion of functional programming more than actually building real-life systems with it. When asked about their past experiences with functional programming you'll rarely hear about anything else than toy projects (in contrast to other things people often list as things they are "excited about").

Connected to that (anecdotally) when working with them, those same people tend to be the ones that try to make the code "clever" or overly perfect (in an attempt to fit into the ideal functional programming paradigm). That usually leads to code that's extremely hard to read and maintain as a team.

I think full functional programming languages can have its niche, but I think most projects are better served programming languages that only borrow from functional ones in certain aspects of the language/standard library.

I agree that this sounds concerning, but in the context of the article, I see where it's coming from. They identify as a "product organization", not a tech one. They want people who are more excited about the problem they are solving than the tools they will use to solve it.

It reminds me of an article I've seen that talks about how companies have such generic "values" that they're not even worth having. Innovative? Well, of course. Integrity? Duh. Better values would be those that not everyone will agree with because it tells you what that company actually stands for. "Product over Tech" seems like a great one.

Anyway, as someone who has definitely been super intrigued by FP, I was initially alarmed by this comment, but understood it better after some thought. After all, he's not saying it was a litmus test, just something they noticed that might be a hint for who would and would not work well at this particular company.

> I understand the kind of person they’re trying to avoid hiring by accident

I think I might be that kind, firmly in the ivory tower.

I always feel frustrated and isolated because people just don't engage and acknowledge my concerns. I post in a busy Slack channel that the new API we're developing wont respond in less than half a second on my own computer, I ask if my setup is wrong or if our API code is just slow as shit. Nobody answers, but it reinforces my role as an ivory tower trouble maker. Two months later everyone is panicking that the new API is slow as shit. Or I find that our test database has a millions of plaintext passwords from real users (yes, some of you reading this were probably included), after arguing that this is effectively a data breach and we're failing our customers I finally prevail, and we wipe out the passwords from the test database at least, but this causes some extra work fixing some automated tests. Again, I did the right thing but in the end I was viewed as a trouble maker. Etc. This reflects my entire career. It just feels like something is wrong with the industry.

> I always feel frustrated and isolated because people just don't engage and acknowledge my concerns.

I've adapted by expressing only my highest concerns and making myself not care as much, honestly.

The amount of this you have to do if you're this type varies from place to place in my experience.

> I post in a busy Slack channel that the new API we're developing wont respond in less than half a second on my own computer, I ask if my setup is wrong or if our API code is just slow as shit. Nobody answers, but it reinforces my role as an ivory tower trouble maker. Two months later everyone is panicking that the new API is slow as shit

Then if you bring it up you're just dragging everyone through the mud ;)

I think it's fair, even though I'm probably someone who would be knocked by it. You make different tech decisions when you're motivated by the results vs the technology, even if it's not conscious

What's unfortunate is that it's really hard to get motivated by a lot of the products our industry pays us to produce, so we drift towards focusing on the technology instead

I felt the same and wondered what the right answer would be. I generally haven't interviewed at companies where I didn't know enough about them to be excited about their domain, and then be excited about their domain, but ultimately as a dev they pay me to write code so I want to also be at least as, if not more so, excited about doing that.

I guess the right answer, if the goal is honesty here, is to couch it in terms of "I'm mostly excited about <your problem domain>, but to be honest one of the reasons I even decided to go this far in the interview process is <tech feature>" or something? I'm not good with people, so I'm as much thinking out loud here and asking for feedback as much as asserting what I'd do.

I work at Culture Amp and have been involved in hiring decisions, including for people who were excited about Elm so happy to comment here. As others have guessed, this is an "indication" not a "rule", and it was more about people who were applying _only_ because of the tech stack, rather than a sense of wanting to build a quality product, or alignment to the company's mission (improving workplace cultures). We hired plenty of people who mentioned Elm. I mentioned Elm in my interview.

Part of the reason for this is very pragmatic: during the time when Elm was in common use at Culture Amp, almost all of the APIs that Elm would have been talking to were written in Ruby on Rails, and our engineers were expected to be able to contribute to work that required changes in both the Elm front end and the Rails API. If someone was a functional language purist, and only wanted to work in say Haskell on the backend... then they wouldn't enjoy being on one of our product teams where writing Ruby on Rails code was part of the day-to-day.