Live data from Hacker News

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

blog.agentrisk.com

21–30 of 32 posts

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

#21

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 p…

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.

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

#22

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…

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

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

#23
post #7

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 p…

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

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

#24
post #22

Earlier quoted context omitted.

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…

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

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

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

#25
post #23
post #7

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 p…

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

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

#27
post #7

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 p…

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.

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

#28

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…

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

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

#29
post #22

Earlier quoted context omitted.

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

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

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

#30

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.

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.
Post reply on HN