I believe there are 3 ways of recruiting when it comes to technology and startups (ignoring agencies and freelancers):
1.) The HR 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:
I mean, why wouldn’t he, both positions have the word “java” in it!
- Good developers normally don’t respond to contact requests from xing and linkedin since their inboxes are already flooded with messages
- It’s hard for a non-technical person to assess the quality of a developer since the CV is useless in most cases. Or rather all cases.
I have seen great developers with shitty CVs and lame developers with great CVs. The only thing that should matter for a developer is code.
Oh, and team culture and stuff. But I’ll get to that later
2.) Organic recruiting through team culture
The best 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 (trust me, I’m the biggest ruby fanboy out there, and even I am convinced of that).
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:
- a room with a beamer (easy)
- couple of beers (easy)
- people who have a topic they are passionate about (hard to find)
- a network of great people to invite (see above)
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.
* Create a world class office
Sleeping pods, showers, gym and most important: an up-to-date library (Zappos style. Check it out). 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 to 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:
- Motivated developers
- New ideas how to solve existing problems
- New impulses
- A bigger network of talented people
* 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.
3.) Recruiting on steroids through active participation in the tech scene
Even better but 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.
Get your team culture right. Invest some money. Probably a lot. Build up the best team possible.
Take (early) google, twitter and Zappos as role models. And then go beyond what they did.
And then your recruiting problem will solve itself.