Live data from Hacker News

Having a non-typical tech stack helped us get better candidates

blog.agentrisk.com

31–32 of 32 posts

Re: Having a non-typical tech stack helped us get better candidates

#31

I was at the FT when they "adopted" Elixir. (There is nothing wrong with Elixir, it actually look quite fun. All of the following is process, buisness and design failures) 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 b…

No, this is just a fancy tautological development argument. This is how we got into the Java trap (yes, it's a trap) to begin with. Everyone knows Java, you can hire Java devs easily, etc. etc. There's really no reason for this other than: "We don't want to let people grow beyond the cogs we hired them to be". That may or may not be "good" but at least call it what it is: Broken internal human factors processes, inst…

to quote my argument:

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

Re: Having a non-typical tech stack helped us get better candidates

#32
I've read many articles along these lines, and I'm gonna say they all suffer from two logic fallacies:

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!

Post reply on HN