Having a non-typical tech stack helped us get better candidates(blog.agentrisk.com)
blog.agentrisk.com
Having a non-typical tech stack helped us get better candidates
https://blog.agentrisk.com/how-having-a-non-typical-tech-stack-actually-helped-us-get-better-candidates-77d12a7796d4
31 comments
Maybe I’m reading this wrong but, how do you know?
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
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's the human condition to think like this. We tried x method and were successful; therefore, method x is the right way to do things. No.. no there are a billion ways to do things and method x just happens to be one of them.
I agree, to a point. I've done my fair share of interviews (as an interviewer) with a vast number of candidates, from different backgrounds. With the little data from this experience (on purpose not calling this an "experiment"), I definitely saw a much higher S/R.
Being mostly remote doesn’t hurt, either.
In a sense their language choice selects for people who learned something not taught in school.
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.
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.
Yeah this is an interesting phenomenon. It's counter intuitive but it does make sense, if you think about it. I remember listening to a podcast (changelog I think) with the creator of Elm and he was asked about this - is it a concern if you build your frontend on Elm that you just won't be able to find anyone to hire?
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.
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.
This trope had been regurgitated for decades. At least as far back as small talk.
Oh for sure, it's not a new idea, but another aspect I didn't mention above is that he also talked about how powerfully this phenomenon can be combined with remote work, which provides a significant multiplier on the effect, and indeed is a relatively new and growing factor that wasn't so relevant even 5 years ago.
100% this.
I think depending on where you are there is a risk of fewer / not enough candidates if you're on the leading / uncommon edge technology a bit. It does make sense though that enthusiasts might be better candidates.
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.
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.
>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.
Curiosity is probably what they have and what helps in solving problems.
Curiosity might also help with working with others too, if directed properly.
Even really awkward folks who apply some logic to their interactions can work those things out in my experience.
Even really awkward folks who apply some logic to their interactions can work those things out in my experience.
Actually (again, just based on the samples we saw), candidates that came from the Elixir community submitted _way_ better code for the programming assignment compared others, which is one of the reasons that made them better candidates.
PG had an essay about this same subject ~15 years ago about python (which was still up and coming back then). I'm sure you could relate it to a trend graph with early adopters, hitting mainstream, etc
http://www.paulgraham.com/pypar.html
Always excited to see more phoenix/elixir love
http://www.paulgraham.com/pypar.html
Always excited to see more phoenix/elixir love
Thanks for the pointer! This definitely should have been a link in the post. Oh, well.
With Elixir, you get all escapees from the Ruby on Rails community. They will work for food to avoid maintaining those horrible RoR 1.x and 2.x web applications that they produced in their earlier years.
It's a wisely chosen stack, indeed.
It's a wisely chosen stack, indeed.
I've happily raised a handful of Rails apps all the way from 2.x up to 5.2. As long as you revisit them at least once or twice a year, and aren't afraid to regex your codebase, you can keep everything fairly modern and pleasant to work with.
The same is true of many things... that said, when you have an Angular 2.x app that needs to uplift to current, not fun. Same goes for the Node side itself as well... man it can be nasty if you don't stay on top of framework upgrades.
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 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.
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.
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, instead of couching it in pseudo-technical tomfoolery.
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.
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.
>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.
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.
True. But it's a big paradigm shift from OOP to FP with pattern matching and adopting the "let it crash" approach. But switching from Java to Elixir is a proven 1000% increase in developer happiness :)
I've generally had the opinion of a let it all burn first approach... in web ui, first thing I do is mount an error handler for the window and unhandled promises that effectively clears body and set's its' innerHTML to <h1>Unexpected Error</h1>. Similar elsewhere forcing the process to exit.
If you're expecting a certain error condition, handle it, otherwise blow up the world, because you can no longer trust it.
If you're expecting a certain error condition, handle it, otherwise blow up the world, because you can no longer trust it.
> 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.
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.
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.
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.
> 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.
> However, it turns out that there are a lot of developers that really love Elixir!
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.
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.
This was by no means our intention. We just wanted to share our experience with the community.
Doesn't work if you are hiring locally. Finding one or two should be a degree easier than 10 compared to something more popular.
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!