Hacker News Reader

Comment by 737maxtw | Hacker News Reader

Does it?

I mean, if I see a good developer who is interested in learning F#, that means I have found a good developer who is interested in learning something off the beaten path.

For certain organizations that is exactly what they need.

View on HN

I think that you're missing my point about the statistical nature of engineering talent hiring. My argument is that you will have higher chances to "see a good developer" in the first place, if relevant pool of potential candidates is larger (of course, under other equal conditions).

Another aspect of that: do not do functional programming then. There are statistics for .NET which surely also apply to most languages: 10 million C# devs, 1 million VB.NET devs and 100k F# devs. By requiring functional programming the candidate pool shrunk by a factor of 100.

There is certainly a higher factor of high talent in FP capable programmers but at the same time the risk for bad hires due to lacking people skills or overly dogmatic work style increases.

Good points. Thank you for bringing them up.

But if you hire "programmers" and train them in F# on the job instead of looking specifically for "F# programmers" you sidestep that problem.

My organisations job ad is looking for people with "several years of programming experience by the way we do things in C# and F# but do not expect you to have".

Then we weed out the huge majority by issuing a tiny take-home code test (think a few fizzbuzz-style questions) that applicants can complete in whatever language or environment they want.

So far, we've received positive feedback on the approach, but also very few truly talented applicants. I think the latter is because we're extremely picky, but I don't know.

What I do know is that we wouldn't get better or more qualified applicants by limiting our search to a few languages. Some of the best so far have come with a language we would never have thought to list.

Thank you for sharing your feedback. Your approach certainly makes sense and I'm also not a fan of listing specific programming languages (as well as stacks, frameworks, platforms or products) as strict requirements. However, in my book, it makes sense only for mature companies and later-stage startups. Early-stage (especially, bootstrapped, small and non-VC-backed) startups simply cannot afford to spend time for training on the job.

Very good point regards training on the job. Indeed a factor to consider in discussion about early stage recruiting!!!

Thank you!

I think with the right, bright people, they'll train themselves in no time. But sure, that shifts the problem from getting "people who know F#" to "people who are very intelligent and experienced", which might be equally hard if not more so.

I believe it's worth it, but have no data to back it up.

Fair enough.

There's another point of view: that by targeting people who either know, or are interested in learning F#, or any other less popular language (like Rust, Erlang, Julia, etc.), you massively increase the quality of your applicant pool.

Developers that just want to pay the bills learn the popular languages: Python, javascript, Java, C#, Swift, etc. Developers who plays with (or maybe find little projects to do with) the like of F# are statistically more likely to care about their craft, even if they don't necessarily have the possibility to use these at their current jobs.

If someone contact you specifically because they want to use an FP language, but they can't at their current job, it's a very good sign. Of course if you limit yourself to something like: 5 years of experience writing F# in insert field of interest here, it's going to be very tough to hire anyone...

Generally, I agree with you, except for the argument that developers who play with (or do projects using) less popular languages "are statistically more likely to care about their craft" (do you have any data supporting this claim?). Being curious, while certainly a valuable trait, is not equivalent to "being caring" about some craft - it is a nice addition to the package. However, it is a bit more nuanced than that. For example, success or failure in using this strategy depends on startup's stage, funding, roadmap, team size, engineering culture as well as current or potential use of microservices architecture, which gives us much greater flexibility in a relevant technology stack selection.

Reply on news.ycombinator.com