In an earlier post I talked about what I think the problems are with some common approaches to recruiting software developers. I didn't mention hiring because at Polyfill we only care about recruiting. Many Hacker News commenters replied with their solutions, but I noticed that most of them were either conflating recruiting and hiring, or talking only about hiring. Some of them appeared to just be talking about other stuff they needed to get off their chest. I liked those comments the best.

Many commenters disagreed with one another on how best to hire developers, despite having had success with their respective approaches. This is because hiring is hard to generalize and nearly everyone’s experience with it is anecdotal. Also, it’s a necessarily subjective thing:

1. Companies/teams have different cultures
2. Different problems need different problem solvers
3. Different developers have different work preferences

Developers even differ on what they are willing to do to get a job in the first place: some of us like live programming exercises, others prefer take-homes, nobody likes talking about themselves, everybody loves reversing a btree while they’re trying to finish a sandwich.

Why separate recruiting and hiring?

Thinking about recruiting and hiring as two separate components of your growth process lets you tune them individually according to their needs. I think that recruiting — the process of attracting the right developers to your company — is more easily generalized and delegated, while hiring — the evaluation and interview process — is a specific process best handled by the hiring manager and the team the candidate would be joining.

Hiring is (probably) bespoke

Every time I'm responsible for hiring at a new company or team, I adapt the hiring process from my last job. I'm always surprised at how much I have to change it. I've made several attempts to generalize hiring, but I've failed to do it enough times that I decided to put my energy elsewhere. Instead, I try to figure out how to figure out what our hiring process should be. The goal is for it to fit our needs and to take less time to figure out next time.

It's also very costly to get hiring wrong, which means I have to spend more time on the hiring part — specifically, the interview process and the interviews themselves. I still have the rest of my job to do, so I need recruiting to take less time while still complementing the hiring process.

At Polyfill, we're interested in working on the recruiting problem, not hiring. Maybe hiring can be generalized, or derived from some structured definition of a company’s key attributes. I’m not confident that a software tool can solve that problem, but I don’t know, so I’m not going to talk about it.

Recruiting

Recruiting is the part of the process where you attract the right developers to your company. It’s everything that you do to get them interested in you, up until they express enough interest to enter whatever your hiring process is. Recruiting is going well when you want to interview almost everyone who applies, and when applications are coming in at a rate you can handle.

If you don't attract the right people, you can't hire the right people. If you attract too many of the wrong people, you'll overwhelm yourself and your team with irrelevant candidates. Filtering is least expensive at the beginning of the process (the recruiting step) and becomes increasingly expensive as you progress through the hiring stages.

Recruiting can be generalized and delegated, but hiring can't?

The costs of a poor recruiting process are:

1. The time you wasted reading applications from candidates you could have filtered out
2. The money wasted attracting inadequate candidates
3. The missed opportunities of not receiving applications from candidates you'd like

Obviously these are bad, but the good news is that there's some slack in this system. Reading the occasional bad resume or missing out on a couple of good candidates is not the end of the world. But if this is happening all the time, well, it's also not the end of the world, but it is the end of you making a good hire. Recruiting needs to be good, but it's okay if it's not perfect.

(Ideally, the relationship between your criteria and the candidates you see should be as close to deterministic as possible, but that topic deserves its own post.)

The costs of a bad hire are:

1. The money you pay them
2. The time and attention you and your team spend onboarding and working with them
3. Their impact on your culture and customers
4. The absence of all of the positive effects of a good hire

Sometimes you make a hire so bad that your best people quit and your company implodes. Nobody has ever read a cover letter so bad it made their company disappear. Except once, in 2008, when Bear Stearns collapsed after reviewing an application for a summer internship submitted by Merlin (the wizard).

You need to get them both right

If your recruiting is bad you’ll spend too much time reading resumes from meteorologists for your cloud engineer position and interviewing candidates you know you won’t hire because “we need to hire someone and this guy is a person who applied”.

Hiring out of desperation is not recommended: the chickens from the “you’ll do” school of hiring usually come home to roost in fun ways, like with 3 months of being annoying to work with, insisting on writing weird javascript, then dropping a production database, all followed by an abrupt exit right after the recruiter, their buddy, gets paid.

If your hiring is bad, your recruiting won’t matter. You’ll be wasting good recruiting and eventually you’ll undermine it. And you might tank your whole company while you're at it!

Polyfill only cares about improving recruiting

Ryan and I are not interested in trying to solve the hiring problem. It seems difficult, in a tedious way, to try to generalize a solution to such a broad problem that probably varies by company, if not by team. The enormous variety in preferences across employers and developers makes it hard enough, but I think the most difficult aspect is evaluating a candidate on behalf of a company or team for which you yourself don’t work.

Instead, we want to provide a way for developers to say what they want, and to introduce employers and developers to one another when they want the same things. We want to cut down on the time wasted on both sides of the recruiting process.

Once employers and developers have been introduced, it’s up to them.

Good luck. Don’t bungle it up!