How to recruit great developers

I believe there are 3 ways of recruiting when it comes to technology and startups (ignoring agencies and freelancers):

 Nr 1 or the common way: Non-organic recruiting through cold calls and direct search

The “standard” way to do recruiting which probably never works out well for anybody.
Unless you are looking for interns, juniors or freelancers (no offense intended, that’s just the way it is).

There are many reasons why this approach does not work:

 Nr. 2: Organic recruiting through team culture

A great way to recruit - it means that your team culture is so great that great developers apply proactively. Great developers rarely have to apply for a job, so this means a lot already (quite a few of them don’t even have a CV because they never had to apply anywhere).

This also means that your team culture is so strong, that your team members proactively start looking for other great team players because they are so convinced of what you’re doing.

Please note that this is not the same thing like “I’m looking in my network because my employer has a ‘refer a friend’ program”, this is something much stronger, since people are not motivated by money, but by passion.

Ok, sounds great, so how do we get there?

Be polyglot

A lot of companies are focused on one language only. E.g. you started out with Ruby and now you are doomed to write Ruby forever. This deters good developers. Nobody wants to be locked in the golden ruby cage forever.
You should drop the “we are doing Ruby and you have to know Ruby” restriction completely and embrace all modern, sexy languages.
Not to mention that you then can tap into the huge reservoir of great developers out there who haven’t written a single line of Ruby in their life.
But in order to do that, you need the appropriate technical architecture. Having a microservice architecture allows you to be polyglot since every microservice is completely independent from each other. Having one monolithic app would probably not work.
Of course this still needs to be at least loosely monitored since certain technologies probably don’t make sense for you (e.g. Java Enterprise when you’re a start-up) or are outdated in the sense that most good developers moved to a different eco system years ago like PHP or Perl (I love Perl, but let’s face it, Perl 6 put the final nail in the coffin).
And of course the teams must commit to maintain and operate it.

Organize user groups

User groups are a very informal developer meetup.

Normally all you need is:

You can either create a user group that hasn’t existed before in your area. Depending on where you are, this might be pretty hard. E.g. in Berlin there are a gazillion of user groups already with all kind of technical topics.
If that doesn’t work, go to existing user groups. Immerse yourself. At one point, people will know and trust you and they might be open to host the next user group at your place.

Organize internal tech talks

Kind of self-explanatory - your developers get together and talk about tech.
Those talks have more great side effects than I could enumerate here. You increase team spirit. You increase “world knowledge” since those tech talk of revolve around work related problems. You create synergies between teams you hadn’t even thought about before. I could go on and on, but I’ll stop here.

Watch conference videos together

Establish a culture where it is considered “normal” to sit together for lunch and watch talks from literally any conference. Can be tech-oriented, but can also be about yoga, sleeping better or how to ride a unicorn on a rainbow.

Create a world class office

Sleeping pods, showers, gym and most important: an up-to-date library Zappos style. That includes encouraging people to read as well.
Ask your team what they want to have in the office.
Some ideas are more of a joke but there will be a lot of good ideas as well ranging from very cheap (“order a new book shelf”) to rather expensive (“A gaming room would be cool”).

Have open source days

That would be days were people can hack on open source software. This is kind of a difficult thing to get right and warrants a separate blog post later.

Attend conferences

Developers want to go to conferences. That’s just something they expect. You should not only grant those requests, but rather encourage people to go there.
Yes, it’s probably not cheap and yes, it might be during working days.

What you get out of this:

Establish a mentor program

Seniors mentor juniors. Veterans mentor newbies so that they don’t feel lost and can get productive as fast as possible. This doesn’t mean that juniors can just abuse seniors to get the job done. It’s more of a “ok, when I am totally stuck with something i can at least ask my mentor for an idea” thing. In most cases they don’t even ask anything, but just to know that they can already has an incredible positive effect on them.

Make recruiting a top priority for every team member

How google works has some great thoughts on how to do that. And more important, how to not do that.

One thing that I love to do is a trial day or two for candidates. After that, both sides know if this will work.
Don’t invite everybody but only people that passed an initial screening. Reject developers who can’t show source code with their application right away, which already weeds out the bad ones.
Include the teams in the decision process. After all, a hire would be good for nothing if you think he / she is a good addition but the team he’d work with rejected him.

 Nr 3: Recruiting on steroids through active participation in the tech scene

The best way in my mind but that requires a lot more of effort.

Speak at conferences

First of all, its important to understand that those conferences are very different from what a lot people would expect: They are very informal, the agenda is sometimes unclear even days before or changed ad hoc and they often feel more like a meeting with friends. They are mostly non-commercial (in the sense that they only have fees to pay their expenses) and you can’t just buy a speaker slot. You sometimes can buy a slot for a 5 minute lightning talk , but never for a full talk (you have to submit a proposal and this proposal gets reviewed by the organizers if it is interesting enough for the attendees).
Talks must be authentic so you can’t just have a talk about something that somebody else did since most people will notice right away.

Organize workshops that are free for non-employees

This is basically how a company here in Berlin recruited rare Erlang programmers (Erlang is very popular in northern Europe): They invited Erlang icons, paid them to do workshops and invited every Erlang dev in Berlin to take part. For free (or almost for free).
There are so many idols out there that travel the world and can be booked for workshops. Corey Haines, Eric Ries, Sandi Metz, Yehuda Katz….the list is long.

Organize Hackathons

Organize a hackathon, give participants an interesting challenge that also solves one of our problems, have some fancy prices and ensure good press coverage.

This is a complicated topic and would require thoughtful planning. I have seen quite a few of those events fail horribly because people thought that providing a room and prize money would be enough.

 Wrapping it up

I believe that getting your team culture right should be paramount. Invest some money. Probably a lot. And try to build up the best team possible.
Early google, twitter and Zappos and many many more can serve role models. And then we can go beyond what they did.

And finally, the recruiting problem will solve itself.


Now read this

Lessons learned from some of the best Ruby codebases out there (part 1)

(Important note: This was originally published on the Blacklane dev blog - I’m just putting this up here as kind of mirror) I recently started looking into Mutant and related gems for an upcoming presentation about abstract syntax trees... Continue →