Monday, September 3, 2012

Where to find all the great recruits?

Engineers I'd love to work with again

I've recently begun the recruiting process at bitly (where I'm looking for just about every type of engineer). To help focus my recruiting efforts, I decided to go through the top 25 engineers I've worked with in the past that I'd be most likely ask to work with me again (or that I have actually asked to work with me again).

The data for my top 25 seem to split in half along 2 major categories for inexperienced (< 3 years professionally) hires and experienced hires (> 3 years).

Inexperienced Hires

From the data on my top 25, the majority of inexperienced hires come from college recruiting with the remainder being internally developed. Internally developed hires are folks that were brought into the company to do some other job and later became engineers. Internally developing engineers requires time and effort from your more experienced folks, but I've seen it frequently pay off. For the cost of training time, you get engineers who you trained with your team's habits, and who have deep understanding of the business. We added 50% to the Knewton technology team by internally developing a couple of folks, at a time when the team only consisted of 4 people and we hadn't yet launched. If we could do it then, you can probably do it now. If you consider the time you spend recruiting candidates through most other means, the time spent training people you already know are great for the company is probably a wash.

College recruits mostly came from on-campus recruiting visits, and an email directly from a dean. I've had the most luck with CMU, but have had a surprising number of good engineers come out of the University of Chicago, Harvard and Cornell. The challenges of college recruiting are the schedule. You need to be ready to interview and get on-campus when the school has openings, you also need to be able to wait 3-5 months for your newly hired recruit to start work.

Experienced Hires

The experienced hires showed a similar nearly 50/50 split between referrals and internal recruiters. A referral is a recruit that someone already on your team recommended. The distinction between internal recruiters vs. recruiters or outside recruiters is that they are hired on-site and typically salaried. My top 25 is skewed towards internal recruiters, but that's most likely due to the fact that I primarily used internal recruiters throughout my career.

Experienced hires have the benefit of a track record of delivery and can usually start within 4 weeks of offer. The downside is that you'll often spend a lot more time going through interviews of people that almost meet your criteria.

A pie chart!

as embarrassing as this is ... I've included a pie chart (even better, made in excel).

What's this all mean? 

Here's what I'm recommending for myself:
  1. Ask every member of the team, all the time, if they know any great engineers we should speak with.
  2. Focus on college recruiting and intern hiring to build the pipeline for the spring.
  3. Improve the filtering process with recruiters to minimize time invested.
  4. Look for opportunities to develop team members outside the engineering team. 

How were the people you'd like to work with again recruited on to your team?

I'd love to hear other tips and tricks for finding great folks.


  1. Great writeup, Peter. I'd be curious to see a breakdown of your top 25 by amount of formal CS training.

  2. thanks, Luke. i'll take a crack at that in the near future. it's at least the 21% in the internally developed category and some of the referrals and recruited experience folks.

  3. I really like the idea of internally developing people into developers. You should always be developing people, here you are just starting from an earlier point.

    Did you somehow vet ahead of time that they are really interested in becoming developers, or that they have certain aptitudes for it?

    I suspect more people don't do it because there is a big risk of failure, so wondering what you've done to manage that risk.

  4. Hey Jean,

    Everyone that we internally developed needed to illustrate an interest outside of the job we were already paying them to do. For some this was test assignments, for others this was pairing with engineers on some tasks while handling project management.

    Here is what I'd recommend to mitigate both the failure and ensuring aptitudes:
    - interest and initiative outside of it being a job.
    - illustrating some proficiency on small, not risky tasks.
    - make sure it's clear that after putting in the effort they might not gain the skills it takes to become an engineer quickly enough, and that's ok.

    If you have someone who is smart, committed to your company, and interested in learning additional skills, it's really difficult for me to see any investment in them as being all that risky :-)

    Out of ~8 people I've seen go through this process, only have one person just really didn't work out as an engineer.

    I wrote this post as a set of pointers for folks looking to move on to software engineering from other disciplines or who are just getting started: