There's a story that I think I read in The Passionate Programmer, although I could be wrong about the source... anyway, the author was trying to recruit a team in India. He had a thousand basically identical resumes. How do you triage that? So he added Ruby as a requirement. It wasn't really a requirement, but it self-selected the resumes for those who take an active interest in programming, not a passive career approach. That got them down to a few dozen resumes to dig through.

I haven't had to hire for myself, but I've done plenty of technical interviewing over the years, and worked with countless programmers. Most just aren't the kind of material I would want to hire. The ones I would want to hire, even if they haven't used Clojure, would be excited about the idea and at least conversant in the advantages (and disadvantages) of functional languages relative to OO languages.

So it's making the job harder, but also easier.

> The ones I would want to hire, even if they haven't used Clojure, would be excited about the idea and at least conversant in the advantages (and disadvantages) of functional languages relative to OO languages.

The problem isn't necessarily sorting through resumes or giving good interviews. It's that all of the developers you want to hire have satisfying and rewarding jobs.

That's a problem anyway. :/

Here's my thinking, and I'd love some feedback on this. I live in Minneapolis, home of more Fortune 500 companies per capita than anywhere else on Earth (really!). These giants are full of very smart engineers that are frustrated and stifled by the nature of the beast they work in. I want to try to poach talent out of the giants by, among other things, offering a chance to work with technology that wasn't chosen by two years of committee meetings. And of course the speed, clarity of purpose, and control over their own destinies that comes with a startup.

This gets to another value of mine, and is going to play into my hiring. I want to hire people who have real-world experience in mainstream enterprise programming/ops. I'm building a product targeted at simplifying the lives of enterprise engineers, and I think it's very important that I hire people who have felt the customer's pain directly. I could get kids fresh out of school, but they won't have that experience.

I couldn't find your question. What exactly did you want feedback on?

It's similar to the idea of pg in The Python paradox (http://www.paulgraham.com/pypar.html) when Python was not as mainstream as now.

Really? I've found that it's easy as pie to find extremely highly skilled developers from my local Clojure meetup and get them interested at well below market salaries.

I must admit that I was looking for a bootstrapping co-founder instead and even 50% market rate didn't make sense in that context so I don't know if they would've followed through, but it sure as hell didn't feel like a tough sell.

so you were trying to hire 1 person? And from that you conclude that it's easy to find many good people at below market rates?

For a startup, you don't need "many". You need a handful. If I'm trying to hire three programmers and they are make-or-break for the success of my company, I'd much rather be picky. I'll leave the hordes of generic Java coders to the people who have to hire a hundred at once.

You are vastly underestimating the difficulty of finding good engineers who you can work with. Sprinkling clojure in your job postings isn't magic. A world of difference exists between people saying "thats cool" and "I will work for you for 50% under market rates".

> Sprinkling clojure in your job postings isn't magic.

If you're trying to find these developers through job postings I don't think you're going to have much success.

Your target market is developers passionate about Clojure so if you want to hire those you need to go to where they are; which most likely isn't Monsterboard.

Sure, if you only need to hire 1 or 2 people then good people aren't terribly hard to find.

Once you get to 10 it's a very different ballgame.

Some would argue that a Lisp like Clojure means you don't need 10 people...

I have no doubt about a tenfold variance across different people, but I'm highly skeptical of any claims that a particular language will make you 10 times more productive over the long haul.

People always doubt this, and then new languages always come along that improve developer efficiency. It was a lot easier to write a program in C than assembler, Perl than C, and Python than Perl, at least for me. I've seen some amazingly sweet code in some of the functional languages like Clojure and Haskell. My current main language is Ruby, and while it is not perfect, I would never trade it as a general-purpose language for assembly. I'm sure I'm well over 10x more effective than I would be if it was all assembly, all the time -- assuming I wasn't allowed to invent a new language as part of the solution.

So why doubt this same thing can happen again? It's like doubting that MD5 will ever be broken, or questioning whether something like Roman numerals can be improved upon. Of course it can, and will.

Clojure is not a 10x improve to over java, full stop. It's not even close, and I've done a project at my day job in clojure, it's my favorite language.

Any new niche language always sing the same song to market themselves.

Unfortunately the song doesn't "keep it real".

Lisp is hardly a new language, it's the second oldest high-level programming language in the world.

Let me revised my wording: Any niche language ... ;)

I wasn't drawing any conclusions; just sharing an anecdote and the impression it left on me.

At Clojure meetups there's a palpable sense of eagerness in everyone I talk with that isn't using it on a daily basis yet though and I would find it hard to believe if that didn't have a significant monetary effect.

As far as recruitment goes, especially in large numbers, I will definitely concede that it will be hard to scale up to large numbers without using traditional hiring channels and that those channels will most certainly fail you when recruiting this specific a skill-set.

True. But what is hard is hiring good developers, not hiring developers that know Clojure. I found that any smart developer will have no problem adjusting to Clojure, especially given a history of any of #{Haskell, Erlang, Scala, Ocaml, SML}.

Still really rough. I have shipped two large production Erlang apps, smaller scale F# and Haskell apps. It is tough in three ways: (1) Just finding people who can do it, (2) finding people INTERESTED in using it, (3) affording people who fulfill the first two.