How to Hire Clojure Developers

How to Hire Clojure Developers
Photo by Clem Onojeghuo / Unsplash

This odd thing keeps happening to me where companies reach out to ask if I know of any Clojure developers they can hire instead of just hiring me. I understand why they do this. I am not interested in full-time position, after all. I think most people would bitterly look at this as if the company were asking for free labour. In some cases, I agree with this sentiment. However, when it comes to Clojure developers, I can empathize as I was something of a hiring manager once. The pipeline doesn't exist.

Do you really need a full-time dev?

You should think hard about this question. We're in the midst of a recession, so people with existing Clojure jobs or experience will probably be reluctant to jump ship from their current job since the job market has begun to dry up (for now). If you're sinking an unreasonable amount of time into searching for a full-time Clojure(script) developer, why not consider a contractor or agency? If Clojure/Conj 2023 was anything to go by, most Clojure developers are self-employed, or at least, most of the people I met are. This is compounded by the fact that most of the Clojure/Conj 2023 sponsors and tables were agencies specializing in Clojure.

Sure, there are plenty of people in the #available-for-jobs channel in on the Clojurians slack looking for full-time work right now. Because full-time positions typically can't cross nationalities (not without legal), a company's nationality rarely intersects with the people in the channel. I did a quick search for a Canadian in the channel, and there was only explicitly one Canadian in there. Companies could use a service like remote.com to hire Clojure developers around the world, but that creates two problems: They might not be a remote first company (I know, I know), or they might not want to spin up a managed subsidiary in a different country or whatever.

According to the StackOverflow developer survey, Clojure developers are some of the highest paid in the world. If you want to command the forty to sixty hours per week of a Clojure developer's time, you better be willing to pay for it. I see plenty of companies offering paltry pay because developers get to use Clojure.

One tactic I've seen in the past is to hire functional programmers from other developer backgrounds, or just hire some functional-curious developers, and train them to use Clojure. Easier said than done, but it might be worth considering if you're wasting too much time or money searching for a Clojure developer to hire. Either way there are ways to evaluate the Clojure, functional programmer, and functional-curious developer in an interview.

Functional Programming Interview

As a base, A functional programming interview should evaluate the use of higher-order functions, function composition, polymorphism, reducers, persistent data structures, idiomatic things, and testing. Huge bonus points if they know how to design software with them.

On top of that, it would be wise to see how familiar the interviewee is with the Clojure ecosystem. For example, do they know the current state-of-affairs for http router, webserver, database, frontend combos? Can they build and push jars to Github Packages or Clojars? Can they deploy a Clojure project to something? Do they know how to contribute to a Clojure library without creating a major version change? I know you may not use what's "standard", so your mileage may vary on this one.

For senior (and higher) level Clojure developers, You may want to evaluate whether candidates understand performance characteristics like transients, transducers, or inlining, and at this level you're probably looking for more application of Software Engineering principles. For example, you could ask questions like "By which mechanisms can you decouple parts of Clojure code with?", "How would you architect an event-driven architecture with only Clojure (no cloud/IaaS)?" or just ask them to do the take home project and look for design decisions.

A full-stack re-frame frontend and ring backend with XTDB or PostgreSQL might be a good jumping off point. An instagram clone, for example. What's the schema look like? What concerns are being separated, and how is the interviewee choosing to separate them? How did they choose to structure their re-frame events, co-effects, and effects namespaces? Should this regular function call actually be a higher-order function passed as an argument? The list goes on.

Unfortunately, there's a class of people I've included that might have higher failure rates: the functional-curious. Pick these battles on a case-by-case basis. Often less experienced folks will do Clojure faux pas without knowing. For example, using the for macro for iteration, or worse, side-effects. Other Clojure faux pas' to look out for are: using macros when not needed; state when not needed; not using core.async when doing concurrency; or not understanding the difference between atoms, agents, and refs.

Finally the best tip I can give is to see if interviewees read Clojure.core source code for a better understanding of how things work under the hood. One can gain a lot of understanding from this, half of what I know about Clojure has come from reading the Clojure.core source code on Github.

Conclusion

I think companies pursue full-time employees without really thinking about what they want out of employment. Usually, companies want full-time employees because of warped notions of work and management. I think companies hiring Clojure developers should at least consider a freelancer or agency (at the risk of sounding like an ad for my own consulting services). The 'hiring pipeline' doesn't really exist for Clojure developers. The companies that seem to be actually executing on their vision are not afraid to spend the scratch on good freelancers or an agency. At the end of the day, employment is a service-based role (developers), and results are results. There are no results if you're wasting all your time trying to hire people who aren't there.

Thanks for reading. Subscribe for the next one or follow me on twitter @janetacarr , or don't ¯\_(ツ)_/¯ . You can also join the discussion about this post on hackernews or reddit if you think I'm wrong.

Subscribe to Janet A. Carr

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe