As a company that only uses F# for day-to-day development, and having gone through the hiring process more than once in the last year, I decided to document our experiences and thoughts on what we look for, what difficulties we face and what has worked well for us.
We also have a permanent careers page here which developers can submit to.
This list is aimed specifically at hiring for F# roles, rather than generally hiring developers.
1. Don't be afraid
Many organisations we speak with are nervous about adopting F# because they're afraid that they won't be able to find developers. In our experience this has been an unnecessary concern.
This is especially true if you're willing to hire remotely. There are plenty of developers out there who are interested in F# roles. Nearly all remote responders we have spoken with in the past have a decent amount of F# experience, so would be able to hit the ground running. In our case, we were explicitly looking for developers to join our London office, which ruled these candidates out. Nonetheless, once we had worked on our job spec and used the right channels to get it out there, we were able to get a regular stream of candidates.
Conversely, if you're happy to upskill and invest into developers yourself (and thinking about it, which IT organisation would say that they don't want to invest in their staff!), you will find many developers from non-F# backgrounds who are happy and interested in cross-training into F#. I would say that a C# developer with .NET experience would require much less time to be productive in F# than, say, a Java developer. Even so, we've seen people and teams successfully upskill into F# from backgrounds such as C#, Python, JavaScript and PHP.
Don't be afraid of F#. No matter what the background of your new starter and the technologies you use, there is always a period of onboarding; F# is simply another element of that.
2. Identify the qualities you think are required
Be clear as to what qualities you're looking for in a developer, and especially an F# developer. You should be happy to hire candidates that don't have F# experience in order to widen the net, so think carefully about what will make a happy and productive F# developer. Every team and organisation is different, so I'm not going to state explicitly what we look for - look at your team and think about what they have in common that makes F# "click" for them and why it makes sense for them.
Similarly, think about what traits or qualities are "no-go" areas for you, whether this is specific technologies the candidates have enjoyed working with that you feel are mutually exclusive with enjoying working in F#, or if it's a specific characteristic or behaviour.
3. Work on your job spec
Make sure that your job spec clearly states how much involvement with F# the candidate will have on a day-to-day basis. They may be suspicious of whether you're "really" doing F#, or simply writing C# with a tiny amount of F# in. Be honest here, otherwise you may find that the developer is disappointed when they find out the truth - something we've observed in the past with some organisations! Another way to allay their fears is to show them real F# code that your company are working on - this has worked well with us in the past.
For candidates that have little or no F# experience, make sure you explain whether pre-requisite knowledge of F# is required - often, candidates simply assume that it is and will stop at the first hurdle. Likewise, if it's a full-time F# role, make sure you make this clear up-front, and that they won't be able to "fall back" into the comfort zone of their previous lnaugage, e.g. C#. This is something we make very, very clear to candidates: that we have total belief in F# as a general-purpose programming language, and if you need to do something in another language or platform, there needs to be a very good reason why.
Make sure your job spec explains clearly how you're applying F# in your team. Are you using it for back-end processes? Full stack web development? Writing unit tests? Many developers out there, even those in the .NET space, don't know what F# is or have misunderstandings as to what you can do with it. Indeed, we've interviewed F# developers in the past who didn't know that you can write great web applications using SAFE Stack or similar.
4. Find the right recruiter
If you're working with a recruiter, make sure you find the right one. You should have a good relationship with them and make sure that they know and understand what you're hiring for. Give them the facts to answer questions from candidates such as what is F# and to allay any inital fears that they may have. Also, explain clearly the qualities that you've identified that you're looking for. A good recruiter will look for these attributes when speaking with candidates and will weed out the ones that don't make the cut.
For example, we expect that a candidate looking to join our team to be interested and enthusiastic about F# and/or functional programming, even if they have no practical experience in it. Furthermore, they should be able to explain why F# interests them - or at least why they are not happy with their current language. Do these factors fit well with working in F#?
A good recruiter will understand these sorts of characteristics and be able to push candidates to you that either have experience or the qualities required to fit with how you're using F#. A bad recruiter - as we've experienced in the past - may at best simply understand that F# runs on .NET and chuck any candidates to you that have WebForms experience on their CV.
5. Use other hiring resources
Recruiters may have a lot of success in reaching developers that don't have a strong social media presence - the so-called "dark matter" developers. Nonetheless there are a wide variety of other social channels out there that you can use to widen the net, of which we had more success with than others.
- Twitter: If you have a decent social media reach, Twitter can be an effective way to raise awareness of a role. However, due to the nature of Twitter, you may have to repost on a regular basis or pin the tweet in order to get good coverage. Remember to use the
#fsharphashtag to quickly get through to the F# community! - LinkedIn: As per Twitter, you can reach another set of potential candidates. However, our experience with the paid LinkedIn recruitment service was not especially positive - for example, it wasn't able to stop candidates applying that didn't have the right to work in the UK, yet expects you to pay for each application regardless.
- Slack: The F# Slack site contains a jobs channel, which is another way to gain outreach within the F# community.
- User groups: Consider attending and even speaking at a local user group, whether F#-specific or not.
6. Give candidates the best opportunity to show what their hands-on dev capabilities are
We've hired and interviewed candidates who both have and don't have F# experience and have learned some great lessons on what to do and what not to do when faced with trying to test them in terms of hands-on technical tests.
For candidates coming from non-F# backgrounds, the absolute worst thing you can do is sit them in front of a keyboard and expect them to do write F# code. This won't show them at their best. Instead, consider letting them write code in a language that they are comfortable in - look at how they model a solution, what kind of problem solving mechanisms they gravitate towards and if they can demonstrate an awareness of the solution vis-a-vis functional programming. If they're using C#, can they explain what LINQ is? Do they understand what composition is? Can they compare and contrast expressions and statements?
Also consider tooling: If they're coming from a C# background (and this is no criticism, but something that you should be aware of nonetheless) are they reliant on something like Resharper? Would they be happy giving this up?
Other candidates we've interviewed had no production experience in F# but were doing it in their spare time. Do they have Github repos demonstrating their F#? Can they talk through the code that they've written to you in a cogent manner? Can they see some code that you've written and understand it?
7. Have an onboarding plan
In all honesty, training people up in F# doesn't take long. I would estimate that within 2 weeks they should have a basic understanding of the language and within 4-8 weeks they'll have confidence and experience of working on codebases.
For candidates that don't have F# experience, make sure that you have a learning plan for them of some kind. This might be working alongside another developer or ensuring they work through a study plan (perhaps using a book as guidance!). Importantly, make sure that they can get their hands dirty with F# on a day-to-day basis, and review their progress regularly. There are many things that you may take for granted that those coming to F# simply have never seen before.
For candidates with F# experience, even though F# seems to have developed a natural style in the community, spend some time to show them the kind of F# that you write. If they come from a Haskell background, they may approach F# very differently to someone that comes from a C# background.
Summary
Whilst there are definitely best practices that you should follow regardless of what role and programming language you're recruiting for, the unique positioning of F# as a relatively small island of developers within the larger .NET ecosystem means that slightly different practices may be required to make an effective hire. Follow these tips to avoid making common mistakes - and most importantly, don't be afraid.
Have (fun _ -> ())!
Isaac
