Having a non-typical tech stack helped us get better candidates
blog.agentrisk.com
blog.agentrisk.com
His response was that on the contrary, people who use Elm tend to be enthusiasts by nature and job postings in Elm are rare enough that if you post one, they will seek it out and come to you, because they really, really want to be using Elm in their day job.
The alternative, using an extremely popular language/framework, means that even though the number of enthusiasts out there is absolutely greater, your job post is just one in a sea of similar ones - so it's much less likely any candidate is going to seek you out or come to you, based on that alone.
That side of the business was a java shop, and had just got 70% through a very long and expensive migration from some old CRM, payment and auth system, to a new CRM payment and auth system. (something like 70 people for four years, lots of design by the CV, Cassandra, and other silly design choices.)
Two devs knew how to use Elixir, they bust out a service, everyone says "Ooo well done" flung it over the fence and leave. Noone else can really support it because they are almost all junior java devs. The other departments can't support it because A) everything was custom, B) only one other person in the entire company (300 devs) knew elixir. Total defecation show.
So when you see people do something because another company said so, politely tell them to reconsider.
to translate into a different context:
Project is to build a grain silo. four teams: One team makes the walls, one the roof, one the vent system and finally the floor.
Roof team decide to use wood, because they've not tried that before, and it looks good. They are all metal workers. They quickly realise the mig welders do not perform as well as they do on steel.
Wall team are using corigated galvanised steel and bolts. Start building the walls, are blocked by both the roof team re-skilling and the floor team.
Vent team decide to use the same, but don't want to use imperial bolts.
Floor team have decided after an away day, that they don't like the current range of ground anchors, so they have decided to spend six months designing a new fixture out of carbon fibre.
To tie it back to the article.
There is no possible way to prove the argument with one company, you need a double blind.
There is literally NO reason (other than time, mentoring and desire) that the jr. Java developers couldn't pick up Elixir in a short amount of time and be fully productive.
Put in another way. If your devs can't learn a new language that's not super foreign in 3-4 weeks to a decently productive level, you didn't hire good devs in the first place. I'm sure they would create a similar dumpster fire in Java.
If you're expecting a certain error condition, handle it, otherwise blow up the world, because you can no longer trust it.
I've had the same problem trying to convey that we don't need someone who is proficient in C# AND JavaScript, and we should be concentrating on the skill that's harder to find good people with experience in, or just polyglots. I'd rather see someone good in 2+ languages that aren't what we're using than one who is bad in those we are.
> All of the following is process, business and design failures
none of this is really about tech, its about process.
Your point:
> We don't want to let people grow beyond the cogs we hired them to be
No, The business wants the product to be built as quickly and cheaply as possibly. That is literally what you are paid for. When you hire a cleaner, you don't want them to spend all their time mixing their own blend of cleaning spray, because they read on a blog that its 15% more efficient. You want them to clean.
The very reason that this team were allowed to repeatedly make stupid decisions was because it was dressed up as personal growth. "I'm going to let my team do what whatever they like in what ever tools they like so long as they don't leave, and they hit these moveable targets. Those targets affect my bonus, so lets not make them too hard." Cue a mountain of tech debt, neatly partitioned by age and fashion.
What is so shameful about using the tech you have to finish the task at hand, reusing stuff where you can, so you can spend time on other things? To reference the grain silo analogy again if they all used the same connectors, material, it'd be build by now and could work on designing a better one.
this point:
> There is literally NO reason (other than time, mentoring and desire) that the jr. Java developers couldn't pick up Elixir in a short amount of time and be fully productive.
Yes if they are given the correct time and support. When you have to learn, elixir, scala and nodejs all whilst still supporting production legacy as well, its not a nice environment.
Dumping your legacy on bunch of juniors because you were making services to furnish your CV is unforgivable.
The whole process looks like a test with no control experiment (i.e. a set of interviews with a more popular stack).
Don’t get me wrong, I’m quite sure Carlos is an amazing engineer, but I don’t think your stack has much to do with it
It also tests for in the worst case the ability to convert Google'ed questions from one language to another. Or a more likely case of writing new code.
http://www.paulgraham.com/pypar.html
Always excited to see more phoenix/elixir love
It's a wisely chosen stack, indeed.
I do wonder though if this might actually be more of a personality type thing and maybe less "better candidate".
Folks who want to learn something non conventional might be better, but they also may share personality traits that mesh well too.
Curiosity is probably what they have and what helps in solving problems.
Even really awkward folks who apply some logic to their interactions can work those things out in my experience.
1. Correlation != causation.
2. Confirmation bias.
There was no comparison mentioned in the article (or just about any similarly purposed article). The author has no - or at least did not state any - insight as to whether or not _this_ particular bullet point (Elixir) had any impact what-so-ever on the quality of the candidates that applied. There were no controls or comparisons made. Just a blind assumption that anyone who applied _must_ be better because of the language choice.
I have no doubt that the esoteric stack did have one major impact on the recruiting process: they had a far smaller pool of candidates to draw from. They weren't wading in resumes, trying to pick out ones that somehow stood out. And the highly specific details of their stack meant they weren't trying to ascertain whether or not a given candidate with no direct experience would be able to "pick it up". They were able (and had to) pay much more attention to each application. They read each resume carefully. And they were probably less strict about which candidates got that initial phone screen/test.
There is a likely a bit of correlation between programmer "quality" and esoteric language knowledge. My experience has been that polyglot programmers are so because they love to program and do so at work an in their spare time. They love learning concepts, ideas, patterns, etc. And they have a lot of tools and (often superficial) knowledge to draw from to solve problems. But, I've also found that often polyglot programmers are terrible at completing. Once the perceived, initial, "fun" problem is "solved" their interest and motivation levels to work through the details, customer feedback, and bugs tanks.
All that said, I'm glad they were able to hire Carlos, and I hope he turns out to be the superstar they are looking for!
Turns out it has nothing to do with being non-typical and everything to do with Elixir.
This is more of an ad for their company than an article on hiring for unconventional tech stacks.