How do you write a recruiting email that a developer will actually respond to?

The short answer: reference something they actually built. Not the job title or years of experience listed on their profile, but a specific repository, a PR they merged, a problem they solved in public code. Everything else (subject lines, timing, follow-up cadence) matters less than whether the first sentence proves you read their work.

Here's why this is harder than it sounds, and how to do it well.

The average response rate for cold developer outreach sits around 4-8% across the industry. Campaigns that include genuine code references (a named repository, a specific technical decision) consistently reach 15-20%, according to data from Gem's recruiting benchmarks. That's not a marginal improvement. It's the difference between a sourcing pipeline that fills roles and one that generates silence.

The gap exists because most recruiting messages don't actually reference what the developer does. They reference what the developer lists: job titles, skill keywords, years of experience. Those signals come from the resume layer of a person's career, not from the work itself.

Why do most recruiting emails to engineers fail?

A 2024 TalentBoard survey found that 86% of candidates ignore generic recruiter messages. For engineers specifically, the failure modes are well-documented. Only 15% of software engineers believe recruiters understand their technical work. Roughly 67% rate recruiters' respect for their time at zero to two out of five.

That's not cynicism for its own sake. It reflects experience. Engineers who are any good receive outreach constantly. The messages are often for the wrong stack, the wrong seniority level, or roles at companies that clearly didn't look at what they actually ship. When the third message in a week opens with "I came across your impressive background," the developer stops reading after the first word.

The problem isn't that developers don't want new opportunities. It's that most outreach provides no evidence that the recruiter has done any actual work. A message that proves you read someone's code is genuinely rare. When it arrives, it reads differently.

What should you look at before writing the email?

If you have a GitHub profile to work with, don't start with the pinned repositories. Start with the activity graph and recent commits. (Not sure what to look for? See our guide on GitHub seniority signals.)

Pinned repos are curated. They're what the developer chose to show. You want to know what they're working on right now, what they care enough about to commit to on a Tuesday night, and what kinds of problems show up in their PR history. That's where you find something worth mentioning.

Specifically, here's what to look for.

Start with a recent repository they actually maintain, not one with 2,000 stars they touched twice. Look for recent commit activity, open issues, and closed PRs. Active maintenance is evidence they care about it.

Then read a PR that solved a non-obvious problem. If there's a description, read it. If they removed 400 lines to make something faster, or refactored something that clearly was a mess, that's a window into how they think.

Review comments on other people's code are underused as a source for outreach material. A developer who explains the reasoning behind a suggested change, rather than just flagging style issues, is showing you how they work with others. It's also specific enough to reference credibly without sounding generic.

Last, look at the stack that actually shows up in their commits over the past year, not the skills section on their profile. The two often diverge more than you'd expect.

Tools like riem.ai index this kind of contribution data across tens of millions of GitHub events, which makes it possible to find and reference specific signals at scale rather than manually clicking through profiles one by one.

How should the email be structured?

Keep it under 150 words. This is not a guideline; it's a structural requirement. Developers decide whether to respond within the first two sentences. Longer emails signal that the recruiter cares more about saying things than about the developer's time.

Subject line: Specific, not clever. Reference the repo name or the language. "Your work on [repo]" works. "Quick question about your Rust experience" works. "Exciting opportunity at a Series B startup" does not work.

Opening sentence: The code reference goes here. Not in sentence three after you've introduced yourself and explained your company. Right here. "I read through your recent PRs on [project], particularly the refactor in [file], and the way you handled [specific thing] caught my attention."

One sentence connecting that to the role. Not a job description. A single thread: why does what they built connect to what you need? "We're building something similar at [company] and have been looking for someone who's already solved this class of problem."

The ask. Low friction. "Would you be open to a 15-minute call to see if this is worth exploring?" is much better than "Please submit your resume via our portal."

That's the whole email.

What should you avoid?

Skip the company boilerplate in the opening message. The developer doesn't need to know your company's mission, growth stage, or how many engineers are on the team before they've decided whether to respond. Save that for the call.

Don't describe the role in the first message. A job description is something you send to someone who has already expressed interest. Leading with it is backwards; it assumes the outcome before you've established the connection.

Avoid referencing things that are publicly visible on their profile header. If your "personalization" amounts to "I saw you work with Python at [company]," that's not personalization. That's reading a headline. Engineers can tell the difference.

Don't use the word "opportunity." It's become a marker of templated outreach and causes most developers to stop reading.

What does a good email actually look like?

Here's a concrete version:

That's 110 words. It takes longer to write than a template, but it gets a response.

The underlying problem with volume-based sourcing

Most cold recruiting to developers fails because it's built around sending more, not writing better. When a message takes 30 seconds to compose, the only way to get responses is to send hundreds of them. When you write something that takes ten minutes because it required reading actual code, you send fewer, but the conversion rate goes up enough that the math still works.

The developers worth hiring are usually the ones receiving the most outreach. They've trained themselves to filter it. A message that proves you read their work doesn't just get a response. It starts the conversation on different terms.

Frequently asked questions

What is a good response rate for recruiting emails to engineers?

The average response rate for developer recruiting outreach is around 4-8%. Highly personalized campaigns (where the message references specific code, projects, or contributions) consistently hit 15-20%. Generic messages sent at volume typically land below 5%.

How do I personalize a recruiting email to a software engineer?

Reference something specific from their actual work: a repository they maintain, a PR they merged, a bug they fixed. Name the project, describe what impressed you about the approach, and connect it directly to the role you're hiring for. Avoid restating things visible on their profile headline, which signals you copied from a template.

Why do developers ignore recruiting emails?

A 2024 TalentBoard survey found 86% of candidates ignore generic recruiter messages. Developers cite three main reasons: the role doesn't match their actual skills, the message is clearly templated, and the recruiter shows no understanding of what the candidate actually does. Only 15% of engineers believe recruiters understand their technical work.

What should I include in a subject line for a recruiting email to a developer?

The most effective subject lines for engineering outreach are short and specific: reference a project name, a language or framework they work in, or a concrete role detail. Examples that work: "Your work on [repo name]" or "Rust role, saw your [project]." Avoid generic subject lines like "Exciting opportunity" or "Quick question"; engineers filter these automatically.

How do I find open source developers to recruit?

Search GitHub by language, topic tags, or recent commit activity in repositories related to your tech stack. Look for contributors with consistent commit history across 6-12 months, not just stars or follower counts. Tools like riem.ai analyze 30M+ GitHub events to surface engineers by their actual contribution patterns, which is more useful than keyword searches on LinkedIn.

How long should a cold recruiting email to an engineer be?

Keep it under 150 words. Developers receive high volumes of outreach and decide quickly whether to read or delete. Lead with the specific reference to their work, follow with one concrete reason the role connects to it, and make a low-friction ask: a 15-minute call, not a formal application. Longer emails almost always hurt response rates.