Triplebyte Magnet - Hire skilled engineers without sending recruiting emails | Product Hunt

You’re the CTO of a 10-person startup. Or you’re the sole recruiter at a company of 40 people. You have to hire five engineers in the next month.

Can you do it with the tools you have?

Probably not.

Hiring needs are spiky, but the size of a recruiting team is not. If one recruiter just barely satisfies your recruiting needs most of the time, it isn’t enough when you need to hire quickly. On the other hand, if your recruiting team can handle these spikes, the team is sitting idle and. burning precious runway during times of more normal load (which is particularly bad in, say, an unstable economy and the most hostile fundraising environment in many years).

Technically-minded readers may recall that this was once the state of affairs in computing. Rewind time 25 years, back to the days of the dot-com bubble. AWS doesn’t exist yet. Neither do Azure or Google Cloud or any of the platforms that sit on top of them. Everyone’s hosting on their own purchased or rented hardware, shoved in a room in an office building somewhere. You can’t easily scale your site to handle spikes of traffic, and you have idle compute power sitting around at off-peak times.

A chart showing how a spiky graph leaves lots of space under a fixed capacity, but still spikes over the line sometimes.

No one, even at the time, thought this was a good state of affairs. But there just wasn’t an obvious way to make sure you had the capacity to handle times of high load without buying more than you needed, at least not without complicated agreements that weren’t accessible to smaller companies.

Today, all you need is a card on file. Tell AWS to add some extra server capacity, and voila!, you have the equivalent of an extra server room seconds later. This is so much better for most use cases that nearly everything today is hosted on one cloud provider or another.

Right now, recruiting isn’t responsive the way cloud computing is. We think we’ve built a tool that can change that. It’s called Magnet.

So, briefly, what is Magnet?

At its core, Magnet is an automated sourcing tool (for those unfamiliar with the term, “sourcing” - as distinct from “recruiting” more broadly - is the process of finding people worth initially talking to at the top of your interview funnel).

Companies hiring engineers give us a structured list of requirements, and Magnet reaches out to engineers on their behalf and asks if they’re interested in the role. Anyone who says “yes, I’m interested" is added to a short-list queue for review by companies, who can move forward with the ones they’re interested in. You can think of it as sort of an intermediate between applications and manual messages, with higher signal-to-noise ratio than applications for candidates but much less effort than manual messaging for companies.

A graphic showing Magnet collecting requirements, messaging candidates, and returning candidates who accept into a short queue.

At first, this sounds neither new nor particularly related to the idea of scaling. We’ll get to the issue of scaling in a moment, but no, the idea of automated sourcing is not new. It has been tried before. In a broad sense, it is sort of how most recruiting is done - a major open secret in the recruiting space is that mass-message campaigns with fill-in-the-blank templates are in fact a standard part of most recruiters’ workflows. Since tech recruiting is in a bad place right now, existing approaches clearly aren’t doing very well.

You’d be right to view this with a grain of salt, is what I’m saying.

But we’re writing this blog now, rather than a few months ago, because we have the receipts. This isn’t the story of a hypothetical thing we want to build that will totally work no really you guys, it’s the story of a thing we already built that has been in the wild for a while and seems to be working well.

Magnet works where previous approaches didn’t for three main reasons.

One, we just do a better job matchmaking because we have richer, domain-specific data along with technical assessment scores for most candidates. When a candidate says they’re interested in a role, they’re moved forward about one third of the time. That is much better than competing approaches, and, from a candidate perspective, it’s better than even the best-matched applications. From a candidate perspective, accepting a Magnet message is kind of like submitting an application, except it’s going into a high-quality queue where you can expect much more consideration than the (typically extremely noisy) standard application queue.

Two, because we’re running Magnet on a platform where we have complete visibility, we can manage how messages are distributed. We’re planning a longer blog post on this topic soon, but one of the most important factors in Magnet’s message targeting is that it limits how much it will reach out to any one engineer. Instead, it distributes messages across the candidate pool much more evenly than human recruiters do.

Here’s a chart showing how messages are distributed by Magnet (green) versus human recruiters (blue). Recruiters overfocus to an extreme degree on a few people despite there being many good - and much more hireable - matches out there. This isn't intentional. Recruiters don't want to compete with dozens of other recruiters for a candidate. But the usual structure of recruiting sites doesn't give them a good way to avoid it.

And three, Magnet works because it’s high-signal enough that candidates don’t ignore it. Anyone receiving these messages knows that they’re automated and can unsubscribe with a single click, but very few people actually do. Less than 1% of candidates who get these messages have unsubscribed.

Why? Because we go out of our way to make things friendly to candidates. We set a hard floor on match quality, so you never get a message about a role they’re totally unqualified for. We stop sending messages if a company seems to have stopped interacting with the role. And we include the exact criteria under which each message was sent, so engineers know exactly why they were good fits for a particular job in a way that gets at real preferences and not just claimed ones.

A message showing the criteria under which an engineer was messaged.

Internally, it’s the company-acceptance rate and the candidate-unsubscribe and candidate-accept rates we pay the most attention to. They’re the signals that tell us that everyone involved here thinks it’s worth their time. In principle, an experience that is “like applying with a higher accept rate and less spammy competition” or “sourcing but with guaranteed responses” is obviously better. In practice, you don't know anything until you have hard data.

But we started this post by talking about scaling. What does any of this have to do with AWS?

Well, let’s return to the question of hiring five engineers in a month. The main reason it’s so difficult to do so isn’t just that you can’t do enough interviews. Five hires requires about fifty onsites, or around two per workday; that’s a manageable-if-heavy load even for a small team. The handful of phone screens needed for each of those onsites isn’t too bad, either.

No, the problem is sourcing. To do two interviews a day, you need to send many hundreds of outbound sourcing messages. And a small team simply cannot do that. This sourcing load is why small companies have to hire recruiters in the first place. A CTO can handle interviewing, but they’ll spend half their time sourcing to make one hire. And it’s why recruiting teams have to scale headcount. One recruiter could handle one engineering hire a month, two in a pinch, but not five.

Sourcing, in short, is the bottleneck. If you can freely scale sourcing, you can freely scale hiring. You can’t do that right now because scaling sourcing means increasing headcount. But headcount is a commitment, a commitment you don’t want to make when your need is spiky and temporary, and especially a commitment you don’t want to make during a downturn when runway is precious.

You could contract out a third party recruiter. But there are two problems with that. The first is that engineers hate that kind of recruiting. Third-party recruiters are incentivized to be extremely spammy, and the extra degree of separation from the role means they tend to give engineers less useful information. And the second, and arguably more important from the perspective of a small company trying to hire, is that they charge contingency fees per hire. Paying per hire means you’re trading limits on speed for limits on volume, and you don’t want to do that when you’re trying to grow.

In short, sourcing is like on-prem hosting: you can scale your servers, or you can make big and expensive commitments to hosting providers, but neither really solves the problem.

Instead, let’s see what hiring five engineers in a month looks like with Magnet.

Instead of increasing headcount, or trying to find third-party sourcers charging contingency fees per hire, you scale up your Magnet volume for the month. In other words, you scale it up the same way you scale up your cloud deployments - by just  deciding to, not by having to build something new. (For the moment, this is manual; we haven't built Terraform for recruiting yet!) Magnet is billed monthly, so this doesn’t commit you to anything: you can run 5x volume this month and 1x next month and 3x the month after that. In essence, you can “spin up an extra sourcer” on demand, and spin them down as soon as you don’t need the capacity.

Magnet saves almost all (about 90%) of the manual work of sourcing, so the huge volume of candidates produced by this increased Magnet volume is manageable by a single recruiter. They can manage the volume with enough time left to book five hires’ worth of interviews. A lone CTO might not have enough time for five, but they can do two hires’ worth of interviews - and still be spending less time sourcing and more time coding.

Then, once the hires are made, you scale your Magnet volume back down. That’s it. You’re not stuck with extra recruiting headcount you didn’t need to add. And if you have another spike later on, you can scale it back up as needed.

This is a fundamentally new way to hire. It freely converts cash into candidates, on demand, and without making longer-term commitments.

It means you can hire faster, because you’re not constrained by sourcing resources. It means you can hire cheaper, because you don’t have to add headcount. It means CTOs and heads of engineering can handle hiring themselves for longer before a first recruiting hire, without burning critical development time. And it removes the least fun part of most recruiters’ jobs.

We think this is how hiring should look for small companies. Putting hiring in the hands of engineers in the early stages of a company helps identify technical talent more efficiently. And once you do have a recruiter, that recruiter should be focusing on the “human” part of their job. Recruiting should be about relationships and candidate experience, not grinding through an endless list of samey messages for half the workday (messages recruiters hate sending just as much as engineers hate receiving them).

Give Magnet a try. We think you’ll like it.

Categories
Share Article

How we made recruiting scale like a cloud deployment

How we made recruiting scale like a cloud deployment
Key Results

Sourcing engineers is the bottleneck to hiring. Headcount is a commitment and third-party recruiters are expensive, so you can't scale it. We tried a different approach.

Introduction

,

You’re the CTO of a 10-person startup. Or you’re the sole recruiter at a company of 40 people. You have to hire five engineers in the next month.

Can you do it with the tools you have?

Probably not.

Hiring needs are spiky, but the size of a recruiting team is not. If one recruiter just barely satisfies your recruiting needs most of the time, it isn’t enough when you need to hire quickly. On the other hand, if your recruiting team can handle these spikes, the team is sitting idle and. burning precious runway during times of more normal load (which is particularly bad in, say, an unstable economy and the most hostile fundraising environment in many years).

Technically-minded readers may recall that this was once the state of affairs in computing. Rewind time 25 years, back to the days of the dot-com bubble. AWS doesn’t exist yet. Neither do Azure or Google Cloud or any of the platforms that sit on top of them. Everyone’s hosting on their own purchased or rented hardware, shoved in a room in an office building somewhere. You can’t easily scale your site to handle spikes of traffic, and you have idle compute power sitting around at off-peak times.

A chart showing how a spiky graph leaves lots of space under a fixed capacity, but still spikes over the line sometimes.

No one, even at the time, thought this was a good state of affairs. But there just wasn’t an obvious way to make sure you had the capacity to handle times of high load without buying more than you needed, at least not without complicated agreements that weren’t accessible to smaller companies.

Today, all you need is a card on file. Tell AWS to add some extra server capacity, and voila!, you have the equivalent of an extra server room seconds later. This is so much better for most use cases that nearly everything today is hosted on one cloud provider or another.

Right now, recruiting isn’t responsive the way cloud computing is. We think we’ve built a tool that can change that. It’s called Magnet.

So, briefly, what is Magnet?

At its core, Magnet is an automated sourcing tool (for those unfamiliar with the term, “sourcing” - as distinct from “recruiting” more broadly - is the process of finding people worth initially talking to at the top of your interview funnel).

Companies hiring engineers give us a structured list of requirements, and Magnet reaches out to engineers on their behalf and asks if they’re interested in the role. Anyone who says “yes, I’m interested" is added to a short-list queue for review by companies, who can move forward with the ones they’re interested in. You can think of it as sort of an intermediate between applications and manual messages, with higher signal-to-noise ratio than applications for candidates but much less effort than manual messaging for companies.

A graphic showing Magnet collecting requirements, messaging candidates, and returning candidates who accept into a short queue.

At first, this sounds neither new nor particularly related to the idea of scaling. We’ll get to the issue of scaling in a moment, but no, the idea of automated sourcing is not new. It has been tried before. In a broad sense, it is sort of how most recruiting is done - a major open secret in the recruiting space is that mass-message campaigns with fill-in-the-blank templates are in fact a standard part of most recruiters’ workflows. Since tech recruiting is in a bad place right now, existing approaches clearly aren’t doing very well.

You’d be right to view this with a grain of salt, is what I’m saying.

But we’re writing this blog now, rather than a few months ago, because we have the receipts. This isn’t the story of a hypothetical thing we want to build that will totally work no really you guys, it’s the story of a thing we already built that has been in the wild for a while and seems to be working well.

Magnet works where previous approaches didn’t for three main reasons.

One, we just do a better job matchmaking because we have richer, domain-specific data along with technical assessment scores for most candidates. When a candidate says they’re interested in a role, they’re moved forward about one third of the time. That is much better than competing approaches, and, from a candidate perspective, it’s better than even the best-matched applications. From a candidate perspective, accepting a Magnet message is kind of like submitting an application, except it’s going into a high-quality queue where you can expect much more consideration than the (typically extremely noisy) standard application queue.

Two, because we’re running Magnet on a platform where we have complete visibility, we can manage how messages are distributed. We’re planning a longer blog post on this topic soon, but one of the most important factors in Magnet’s message targeting is that it limits how much it will reach out to any one engineer. Instead, it distributes messages across the candidate pool much more evenly than human recruiters do.

Here’s a chart showing how messages are distributed by Magnet (green) versus human recruiters (blue). Recruiters overfocus to an extreme degree on a few people despite there being many good - and much more hireable - matches out there. This isn't intentional. Recruiters don't want to compete with dozens of other recruiters for a candidate. But the usual structure of recruiting sites doesn't give them a good way to avoid it.

And three, Magnet works because it’s high-signal enough that candidates don’t ignore it. Anyone receiving these messages knows that they’re automated and can unsubscribe with a single click, but very few people actually do. Less than 1% of candidates who get these messages have unsubscribed.

Why? Because we go out of our way to make things friendly to candidates. We set a hard floor on match quality, so you never get a message about a role they’re totally unqualified for. We stop sending messages if a company seems to have stopped interacting with the role. And we include the exact criteria under which each message was sent, so engineers know exactly why they were good fits for a particular job in a way that gets at real preferences and not just claimed ones.

A message showing the criteria under which an engineer was messaged.

Internally, it’s the company-acceptance rate and the candidate-unsubscribe and candidate-accept rates we pay the most attention to. They’re the signals that tell us that everyone involved here thinks it’s worth their time. In principle, an experience that is “like applying with a higher accept rate and less spammy competition” or “sourcing but with guaranteed responses” is obviously better. In practice, you don't know anything until you have hard data.

But we started this post by talking about scaling. What does any of this have to do with AWS?

Well, let’s return to the question of hiring five engineers in a month. The main reason it’s so difficult to do so isn’t just that you can’t do enough interviews. Five hires requires about fifty onsites, or around two per workday; that’s a manageable-if-heavy load even for a small team. The handful of phone screens needed for each of those onsites isn’t too bad, either.

No, the problem is sourcing. To do two interviews a day, you need to send many hundreds of outbound sourcing messages. And a small team simply cannot do that. This sourcing load is why small companies have to hire recruiters in the first place. A CTO can handle interviewing, but they’ll spend half their time sourcing to make one hire. And it’s why recruiting teams have to scale headcount. One recruiter could handle one engineering hire a month, two in a pinch, but not five.

Sourcing, in short, is the bottleneck. If you can freely scale sourcing, you can freely scale hiring. You can’t do that right now because scaling sourcing means increasing headcount. But headcount is a commitment, a commitment you don’t want to make when your need is spiky and temporary, and especially a commitment you don’t want to make during a downturn when runway is precious.

You could contract out a third party recruiter. But there are two problems with that. The first is that engineers hate that kind of recruiting. Third-party recruiters are incentivized to be extremely spammy, and the extra degree of separation from the role means they tend to give engineers less useful information. And the second, and arguably more important from the perspective of a small company trying to hire, is that they charge contingency fees per hire. Paying per hire means you’re trading limits on speed for limits on volume, and you don’t want to do that when you’re trying to grow.

In short, sourcing is like on-prem hosting: you can scale your servers, or you can make big and expensive commitments to hosting providers, but neither really solves the problem.

Instead, let’s see what hiring five engineers in a month looks like with Magnet.

Instead of increasing headcount, or trying to find third-party sourcers charging contingency fees per hire, you scale up your Magnet volume for the month. In other words, you scale it up the same way you scale up your cloud deployments - by just  deciding to, not by having to build something new. (For the moment, this is manual; we haven't built Terraform for recruiting yet!) Magnet is billed monthly, so this doesn’t commit you to anything: you can run 5x volume this month and 1x next month and 3x the month after that. In essence, you can “spin up an extra sourcer” on demand, and spin them down as soon as you don’t need the capacity.

Magnet saves almost all (about 90%) of the manual work of sourcing, so the huge volume of candidates produced by this increased Magnet volume is manageable by a single recruiter. They can manage the volume with enough time left to book five hires’ worth of interviews. A lone CTO might not have enough time for five, but they can do two hires’ worth of interviews - and still be spending less time sourcing and more time coding.

Then, once the hires are made, you scale your Magnet volume back down. That’s it. You’re not stuck with extra recruiting headcount you didn’t need to add. And if you have another spike later on, you can scale it back up as needed.

This is a fundamentally new way to hire. It freely converts cash into candidates, on demand, and without making longer-term commitments.

It means you can hire faster, because you’re not constrained by sourcing resources. It means you can hire cheaper, because you don’t have to add headcount. It means CTOs and heads of engineering can handle hiring themselves for longer before a first recruiting hire, without burning critical development time. And it removes the least fun part of most recruiters’ jobs.

We think this is how hiring should look for small companies. Putting hiring in the hands of engineers in the early stages of a company helps identify technical talent more efficiently. And once you do have a recruiter, that recruiter should be focusing on the “human” part of their job. Recruiting should be about relationships and candidate experience, not grinding through an endless list of samey messages for half the workday (messages recruiters hate sending just as much as engineers hate receiving them).

Give Magnet a try. We think you’ll like it.

Book a demo to start reviewing top engineering candidates today.

Get started hiring great software engineers with Triplebyte now

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

By subscribing you agree to Triplebyte's Terms , Privacy and Data Policy, including Cookie use. You also agree to receive potential subsequent email, SMS and third-party communications, which you may opt out of at any time. Visit our Privacy Center.