# RealGreatDevs — full LLM context
> Hire software engineers by their actual code, not resumes. Search 2,000,000+ engineers with verified email by skill and country, see what they have actually built, and reach them directly.

Source index: https://www.realgreatdevs.com/llms.txt
Site: https://www.realgreatdevs.com

## Product brief

Plans are self-serve with a free account to start, billed per workspace with seats included and no per-hire or placement fee. Aggregate data like the skill and country pages is public and free to browse.

### Strengths
- Every profile is backed by public code you can read, not a self-reported skill list
- Filter on activity itself: contribution volume, repository count, language mix and country
- Self-serve, so you can evaluate it without a sales call or an annual commitment

### Limitations
- Engineering only. If you also hire sales, finance or design, you need something else alongside it
- Coverage depends on public code, so engineers who work only in private repositories are underrepresented
- Not an ATS or a CRM: it finds and contacts people, it does not manage them through a hiring process

### Competitor pages
- [RealGreatDevs vs SeekOut](https://www.realgreatdevs.com/compare/seekout): An enterprise talent intelligence platform with deep public-web enrichment, strong diversity analytics and ATS rediscovery.
- [RealGreatDevs vs hireEZ](https://www.realgreatdevs.com/compare/hireez): An outbound sourcing and engagement platform that aggregates candidate data from a wide set of open-web sources.
- [RealGreatDevs vs LinkedIn Recruiter](https://www.realgreatdevs.com/compare/linkedin-recruiter): The default sourcing tool for most recruiting teams, built on the largest professional network and its self-reported profile data.
- [RealGreatDevs vs Gem](https://www.realgreatdevs.com/compare/gem): A recruiting CRM and outreach platform focused on nurturing and converting candidates already in your pipeline.
- [RealGreatDevs vs Findem](https://www.realgreatdevs.com/compare/findem): A talent data platform built around 'attributes' derived from a candidate's career history rather than keyword matching.
- [RealGreatDevs vs AmazingHiring](https://www.realgreatdevs.com/compare/amazinghiring): A technical sourcing tool that aggregates engineer profiles from code hosts, professional networks and community sites.
- [RealGreatDevs vs Juicebox](https://www.realgreatdevs.com/compare/juicebox): A natural-language search tool over an aggregated candidate index, aimed at fast ad-hoc sourcing.
- [RealGreatDevs vs Entelo](https://www.realgreatdevs.com/compare/entelo): A long-established sourcing platform combining an aggregated candidate database with outreach tooling.
- [RealGreatDevs vs Fetcher](https://www.realgreatdevs.com/compare/fetcher): A managed sourcing service that combines software with a human team curating candidate batches.
- [RealGreatDevs vs Wellfound](https://www.realgreatdevs.com/compare/wellfound): A startup-focused job marketplace, formerly AngelList Talent, where candidates opt in to being hired.

## Articles

### Best Tools for Technical Recruiters in 2026

HTML: https://www.realgreatdevs.com/blog/best-tools-for-technical-recruiters
Markdown: https://www.realgreatdevs.com/blog/best-tools-for-technical-recruiters.md

# Best Tools for Technical Recruiters in 2026

> The best tools for technical recruiters — sourcing, screening, outreach and ATS — ranked for engineering hires rather than generic talent acquisition.

- Canonical: https://www.realgreatdevs.com/blog/best-tools-for-technical-recruiters
- Target query: best tools for technical recruiters
- Funnel: bottom
- Published: 2026-08-07
- Tags: technical recruiting, tools, comparison

Technical recruiters need a different stack than generalist TA. Keyword search on self-reported skills is not enough when the role is Rust infrastructure or a staff frontend hire who has to judge code quality.

This list is for people who fill engineering roles week in, week out. We build one of the tools below.

## The stack that actually shows up on a technical desk

| Job | Tool type | Strong options |
| --- | --- | --- |
| Find engineers by real work | Code-backed sourcing | RealGreatDevs, AmazingHiring, SeekOut |
| Find anyone / warm paths | Professional network | LinkedIn Recruiter |
| Sequence and nurture | Recruiting CRM | Gem |
| Track the process | ATS | Ashby, Greenhouse, Lever |
| Screen without wasting loops | GitHub + scorecard | Free + [screening checklist](/guides/how-to-screen-developers-on-github) |
| Comp context | Salary data | Levels.fyi, local surveys, your own closed offers |

## Sourcing: start with proof

**RealGreatDevs** — 2.5M engineers indexed from public GitHub. Filter on languages, contributions, repos, country. Self-serve. Best when the role is IC and technical depth matters. Skip if you hire mostly non-eng.

**AmazingHiring** — specialist aggregator for engineers; strong in some EU/CIS markets. Annual contract.

**SeekOut** — broad talent intelligence with GitHub/patent enrichment. Enterprise pricing ($10K–$30K/seat/yr common for teams). Worth it for compliance-heavy orgs; heavy for a single technical recruiter.

**LinkedIn Recruiter** — still mandatory for many desks because hiring managers live there and eng managers have thin GitHub profiles. Weak as your only technical source.

## Screening: do not outsource judgment to a score

Automated "coding score" products are optional. What is not optional is a repeatable human screen of public work — five minutes per profile using [this checklist](/guides/how-to-screen-developers-on-github). Pair with a short structured screen call.

Take-homes should have a deadline, a review SLA, and a scope under three hours. Endless take-homes are why your time-to-hire blows out — see [time to hire](/guides/time-to-hire-software-engineers).

## Outreach: quality over sequences

Gem (or hireEZ's sequencer) helps when volume is real. For most technical desks, twenty specific emails beat two hundred sequenced ones. Templates: [how to email developers](/guides/how-to-email-developers).

## ATS: pick for eng workflow, not feature count

Ashby and Greenhouse are common in eng-heavy companies because scorecards and structured feedback are first-class. The ATS does not find candidates. Buy it when process chaos is the bottleneck, not when the calendar is empty.

## A lean technical recruiter kit

**Solo / small company**

1. Free GitHub + Boolean ([guide](/guides/boolean-search-for-recruiters))
2. Self-serve eng sourcing when volume rises
3. Spreadsheet or lightweight ATS
4. Personal email

**In-house technical recruiter at a scale-up**

1. LinkedIn Recruiter (managers + mixed roles)
2. Eng specialist (RealGreatDevs / AmazingHiring / SeekOut)
3. Gem if nurture matters
4. Real ATS with scorecards

**Agency technical sourcer**

1. Specialist eng databases for delivery speed
2. LinkedIn for client-facing visibility
3. Strict Boolean + GitHub screen SOPs so juniors do not burn client brands

## What to stop paying for

- A second enterprise sourcing seat "just in case"
- AI writing tools that produce generic outreach
- Assessment platforms you never review the results from
- Job board boosts for roles that only hire passive talent

For category-wide comparisons see [best sourcing tools for recruiters](/blog/best-sourcing-tools-for-recruiters) and [candidate sourcing software](/blog/best-candidate-sourcing-software).


---

### Most In-Demand Programming Skills: What 2.5M Profiles Use

HTML: https://www.realgreatdevs.com/blog/most-in-demand-programming-skills
Markdown: https://www.realgreatdevs.com/blog/most-in-demand-programming-skills.md

# Most In-Demand Programming Skills: What 2.5M Profiles Use

> The most in-demand programming skills by real public usage across 2.5 million developer profiles — not survey hype — and how to hire against the list.

- Canonical: https://www.realgreatdevs.com/blog/most-in-demand-programming-skills
- Target query: most in demand programming skills
- Funnel: top
- Published: 2026-08-07
- Tags: data study, skills, hiring

"Most in-demand programming skills" lists are usually surveys of what employers *wish* they could find, or what course platforms want to sell. This one is different: it ranks skills by how many developers in a 2.5 million profile index actually show them in public work.

Demand in the job-market sense and supply in the public-code sense are not identical — but supply is what your sourcing filters hit first.

<Callout title="About the data">
Counts are developers with the skill in public GitHub activity, folded through a canonical taxonomy. Data as of August 2026. Browse live numbers on each [skill page](/hire-developers).
</Callout>

## Top skills by indexed developers

| Rank | Skill | Developers |
| --- | --- | --- |
| 1 | JavaScript | 1,336,934 |
| 2 | HTML | 1,202,938 |
| 3 | Python | 1,153,995 |
| 4 | TypeScript | 749,904 |
| 5 | Java | 743,885 |
| 6 | CSS | 684,048 |
| 7 | C++ | 510,023 |
| 8 | Jupyter | 433,818 |
| 9 | C | 387,193 |
| 10 | Bash / Shell | 367,495 |
| 11 | PHP | 360,706 |
| 12 | C# | 298,627 |
| 13 | Go | 255,927 |
| 14 | Ruby | 201,639 |
| 15 | Vue.js | 151,658 |
| 16 | Rust | 127,090 |
| 17 | Kotlin | 123,406 |
| 18 | Docker | 114,850 |
| 19 | Dart | 114,828 |
| 20 | Swift | 105,978 |

## How to read this as a hiring manager

**Large pool ≠ easy hire.** JavaScript and Python searches return more people than you can process. Your problem is ranking and outreach quality.

**Smaller pool ≠ "nobody exists."** Rust at ~127k is still a real market — but every message has to earn a reply, and geography matters more.

**HTML/CSS rank high because they co-occur with almost every web stack.** Do not open a "hire HTML developers" req unless you truly mean it; use them as secondary filters.

**TypeScript vs JavaScript.** TypeScript is smaller but the population is more deliberate (higher median contributions in our data). For serious frontend/Node roles, prefer TypeScript as the primary skill page.

## Skills that punch above their survey hype

**Go and Rust** sit below the Java/Python giants but hire like scarce specialties. Expect longer sourcing cycles and higher comp.

**Kotlin and Swift** are mobile-gated — pool size is country-sensitive. Check [skill × country](/hire-developers/kotlin) pages before you assume a global remote search will work.

**Docker** as a primary skill is a smell. It is usually a secondary filter on top of a language.

## Practical sourcing against this list

1. Pick **one primary skill** and at most two secondaries.
2. Open the [skill hub](/hire-developers/python) and note median activity — set filters relative to that median.
3. Add country only after the global shortlist is too large or timezone-constrained — [where developers live](/blog/where-software-developers-live).
4. Screen on proof, not on the skill tag alone — [GitHub screening](/guides/how-to-screen-developers-on-github).

## What surveys get wrong

Surveys overweight what CTOs plan to adopt next year (AI tooling, niche frameworks). Public code overweight what people already ship. For filling a seat *this quarter*, ship-weighted data is the better sourcing map. For planning a platform migration, surveys and internal architecture matter more than GitHub totals.

For the behavioural side of "who is strong," see [what makes a great developer](/blog/what-makes-a-great-developer).


---

### Outbound Recruiting Software: What Actually Moves Pipeline

HTML: https://www.realgreatdevs.com/blog/outbound-recruiting-software
Markdown: https://www.realgreatdevs.com/blog/outbound-recruiting-software.md

# Outbound Recruiting Software: What Actually Moves Pipeline

> Outbound recruiting software compared — sequencing, enrichment, sourcing databases and what to buy only after your message and ICP are clear.

- Canonical: https://www.realgreatdevs.com/blog/outbound-recruiting-software
- Target query: outbound recruiting software
- Funnel: bottom
- Published: 2026-08-07
- Tags: outbound, recruiting software, tools

Outbound recruiting software does not create a hiring strategy. It amplifies whatever strategy you already have — including a bad one. Buy tools after you can describe who you want, why they should care and what "good" looks like on a scorecard.

## What "outbound recruiting software" usually means

The category is a pile of four jobs:

1. **Find** people (sourcing / database).
2. **Enrich** contact data (email, sometimes phone).
3. **Sequence** outreach (email/LinkedIn steps).
4. **Track** replies and stage (lightweight ATS or CRM).

Some products do one job well. Some claim all four and do two poorly. Map your bottleneck before you buy.

## Buy for the bottleneck you have

| Bottleneck | Tool type | Do not buy |
| --- | --- | --- |
| Cannot find enough profiles | Sourcing database | Another sequencer |
| Find people, no emails | Enrichment | More LinkedIn seats alone |
| Emails, no replies | Message + ICP fix first | More volume tools |
| Replies, no process | ATS / stage tracking | Another scraper |
| Everything is manual chaos | Sequencer + CRM hygiene | Five overlapping apps |

Volume without a [message that works](/guides/how-to-email-developers) just burns domains.

## Stack patterns that work for eng hiring

### Lean (solo / small team)

- Sourcing: GitHub + one recruiter database **or** a GitHub-native product.
- Outreach: Gmail/Outlook + tracker spreadsheet, or a light sequencer.
- Pipeline: Notion / Airtable / simple ATS.

### Growth (multi-req, multi-recruiter)

- Dedicated sourcing tool with exports.
- Sequencer with deliverability controls.
- ATS that recruiters will actually update.
- Clear rules: who owns which req, who can send from which domain.

### Engineering-specialist overlay

For IC roles, add a layer that ranks by **code proof**, not only title. That is the gap most general outbound stacks miss — see also [best tools for technical recruiters](/blog/best-tools-for-technical-recruiters).

## Features that matter vs. demo theatre

**Matter**

- Accurate emails with clear confidence.
- Suppression / unsubscribe handling.
- Domain warmup and send limits.
- Export to your ATS.
- Filters that match eng reality (languages, location, seniority proxies).

**Theatre**

- AI that rewrites every email into the same beige blob.
- "Intent scores" with no transparent definition.
- Chrome extensions that break every week.
- Claims of unlimited LinkedIn automation (that is how accounts die).

## Compliance and deliverability (non-optional)

Outbound software makes it easy to spam. That is a legal and brand risk.

- Respect region-specific rules (GDPR, CAN-SPAM, etc.).
- Prefer work/personal emails only when your counsel agrees for your use case.
- Cap daily volume; warm domains; authenticate SPF/DKIM/DMARC.
- Include a real opt-out path.

No tool absolves you of this.

## How RealGreatDevs fits

[RealGreatDevs](https://www.realgreatdevs.com) is the **find + prioritize** layer for engineers: public GitHub signals, filters by skill and country, exportable shortlists. Pair it with whatever sequencer or ATS you already use — we are not trying to replace your entire GTM stack.

Start from [hire developers](/hire-developers) or a specific skill page once your scorecard exists.

## Buying checklist

1. What is the bottleneck this week?
2. Who will use the tool daily?
3. What does success look like in 30 days (replies? onsites? offers?)?
4. Can we export data if we leave?
5. Does it help us hire **engineers**, or only "people with titles"?

If you cannot answer those, pause the procurement call. Fix the scorecard and the first email first — then buy outbound recruiting software that amplifies a system that already works at small volume.


---

### How Startups Hire Engineers When They Can't Pay FAANG Comp

HTML: https://www.realgreatdevs.com/guides/how-startups-hire-engineers
Markdown: https://www.realgreatdevs.com/guides/how-startups-hire-engineers.md

# How Startups Hire Engineers When They Can't Pay FAANG Comp

> How startups hire engineers without FAANG budgets — sourcing channels, process design, equity honesty and what to stop doing from enterprise playbooks.

- Canonical: https://www.realgreatdevs.com/guides/how-startups-hire-engineers
- Target query: how startups hire engineers
- Funnel: middle
- Published: 2026-08-07
- Tags: startups, hiring, sourcing

Startups that copy enterprise hiring playbooks run out of money before they run out of interview loops. The companies that hire well early use unfair advantages they actually have: speed, scope, specificity and founder access — not a bigger LinkedIn seat count.

## What works at seed / Series A

### 1. Founder-led first closes

Your first 2–5 engineers should be able to ask the founder questions and get real answers the same day. Outsourced screening for early hires signals that nobody technical is in the building.

### 2. Scope instead of brand

You cannot win on brand. You can win on "you will own X end-to-end." Put that in the [job description](/guides/software-engineer-job-description) and the first email.

### 3. Speed as a feature

21 controllable days to offer is achievable — [time to hire breakdown](/guides/time-to-hire-software-engineers). Big companies often cannot move that fast. Use it.

### 4. Networks before databases

Angel investors, advisors, open-source collaborators, ex-colleagues. Warm paths convert better than any tool. Tools fill the gaps your network cannot.

### 5. Public work as the filter

You do not have a recruiting team to run twelve screens. Screen on GitHub proof first — [checklist](/guides/how-to-screen-developers-on-github) — then talk to humans.

## Channels ranked for early-stage

| Channel | When it works | Cost |
| --- | --- | --- |
| Founder network | Always try first | Time |
| Warm intros | Best close rate | Social capital |
| Wellfound / startup marketplaces | Active, startup-biased talent | Free–paid |
| GitHub + targeted email | Scarce IC skills | Time / small tools |
| LinkedIn Recruiter | If you already pay for it | High |
| Agencies | Single hard role, no time | 15–25% of salary |

Most seed teams overbuy LinkedIn and underuse GitHub. Reverse that for technical ICs — [LinkedIn vs GitHub](/guides/linkedin-vs-github-for-hiring).

## Comp without matching Big Tech cash

Be honest:

- Publish a cash range you can defend.
- Explain equity simply (percent or share count, pool, current raise context — not fairy dust).
- Offer meaningful scope and title accuracy (do not hand out "Staff" to close a mid-level hire).
- Consider contractor/EOR remote in markets that fit timezone and budget — [remote hiring guide](/guides/how-to-hire-remote-developers).

Candidates accept below-FAANG cash for ownership and pace. They do not accept below-FAANG cash plus vagueness plus a six-week process.

## Process that fits a five-person company

1. 30-minute founder/technical screen.
2. Paid or tightly scoped exercise (2–3 hours max) **or** deep code/architecture walkthrough of their public work.
3. Team round (culture + collaboration).
4. Offer.

Skip panel theatre. Skip unused take-homes that sit in someone's inbox for ten days.

## Mistakes that kill startup hiring

- Hiring a "recruiting lead" before a hiring plan exists.
- Requiring FAANG pedigree for a product that is still finding PMF.
- Ten must-haves on the JD.
- Ghosting candidates because "we're heads-down."
- Letting an agency become your only brain for what the role is.

## A 30-day plan for your next eng hire

| Week | Focus |
| --- | --- |
| 1 | Scorecard, band, JD, list of 20 warm targets |
| 2 | Warm outreach + 40 cold sourced profiles |
| 3 | Screens + exercise |
| 4 | Finals + offer |

Source cold candidates from a clear primary skill page — e.g. [React](/hire-developers/react) or [Node](/hire-developers/nodejs) — and write like a founder, not a sequence. Templates: [email developers](/guides/how-to-email-developers).

If you only have time to do one thing differently: **shorten the loop and put a real person in the first conversation.** Tools help after that, not before.


---

### How to Find Passive Candidates Who Still Reply

HTML: https://www.realgreatdevs.com/guides/how-to-find-passive-candidates
Markdown: https://www.realgreatdevs.com/guides/how-to-find-passive-candidates.md

# How to Find Passive Candidates Who Still Reply

> How to find passive candidates for engineering roles — where to look, how to filter for reachability, and outreach that does not feel like spam.

- Canonical: https://www.realgreatdevs.com/guides/how-to-find-passive-candidates
- Target query: how to find passive candidates
- Funnel: middle
- Published: 2026-08-07
- Tags: sourcing, passive candidates, outreach

Passive candidates are not "people who hate you." They are people who are not looking *right now*. Most great engineering hires are in that group. The mistake is treating them like active job seekers with a longer subject line.

## What "passive" means in practice

- Not marked Open to Work.
- Not applying to your job post.
- Still willing to hear a specific, well-paid, well-scoped opportunity.

If your pipeline is only inbound, you are competing for the small fraction of engineers who are actively shopping — often the most competed-over fraction.

## Where passive engineers actually are

**Public code hosts.** GitHub profiles with recent work and no job-hunt signal. Primary hunting ground for IC roles — [GitHub sourcing](/guides/github-sourcing-guide).

**Professional networks with quiet profiles.** LinkedIn without the green banner. Better for managers and people whose work is private.

**Communities.** Maintainers, conference speakers, Discord/Slack experts. High trust, low volume.

**Your own past pipeline.** Everyone who said "not now" six months ago. Cheapest passive source you already paid to find.

## A filter stack for passive ICs

1. **Skill proof** — language/framework in real repos, not only a skills list.
2. **Recency** — contributions in the last 12 months.
3. **Stability signal** — long tenure can mean happy where they are (still contact; adjust pitch). Job-hopping every six months is a different conversation.
4. **Reachability** — email on profile, personal site, or commit history.
5. **Fit constraints** — country/timezone you can hire in.

Indexes that expose activity filters (including [ours](/hire-developers)) exist because LinkedIn Boolean cannot express "committed this year" cleanly.

## Outreach that works on people who are not looking

Passive candidates delete anything that looks automated. Rules:

- Name a specific repo or talk.
- State salary range in message one.
- Explain why *them*, in one sentence.
- Offer an easy no and a referral ask.
- One follow-up max.

Full templates: [how to email developers](/guides/how-to-email-developers).

**Pitch angle for passive people:** the problem they would own and the level of impact — not "we have free snacks and a mission."

## Volume expectations

| Approach | Useful replies / 100 contacts (rule of thumb) |
| --- | --- |
| Generic sequence | 1–5 |
| Specific + salary + proof you looked | 15–40 |
| Warm intro from a peer | Much higher, tiny volume |

If you need 5 onsite loops, plan backwards: ~15–25 serious conversations → ~80–150 well-researched outreaches for a scarce role, less for a common stack.

## Passive ≠ uninterested forever

Track "not now" with a date and a reason. Revisit at 4–6 months with a *new* reason to talk (new role scope, new band, new product), not the same email resent.

## When job posts still help

Passive sourcing does not mean delete the careers page. Active candidates are cheaper when they appear. Run both: post for inbound, source for the roles inbound never fills (senior, scarce, niche stack).

Start a passive search from a [skill page](/hire-developers/typescript), cut with the [GitHub screen](/guides/how-to-screen-developers-on-github), then write like a human.


---

### How to Write a Software Engineer Job Description That Gets Replies

HTML: https://www.realgreatdevs.com/guides/software-engineer-job-description
Markdown: https://www.realgreatdevs.com/guides/software-engineer-job-description.md

# How to Write a Software Engineer Job Description That Gets Replies

> How to write a software engineer job description engineers will actually read — what to include, what to cut, and a template that supports sourcing and outreach.

- Canonical: https://www.realgreatdevs.com/guides/software-engineer-job-description
- Target query: software engineer job description
- Funnel: middle
- Published: 2026-08-07
- Tags: job descriptions, hiring, employer branding

Most software engineer job descriptions are written for the ATS, not for the candidate. They read like a legal dump of every tool the company has ever used. Engineers skim them in twenty seconds and bounce.

This is how to write one that supports both inbound applications and cold outreach.

## What engineers look for first

In order:

1. **Salary range** (or clear statement it is listed later — better to list it).
2. **Stack they would actually use** in the first six months.
3. **Seniority and scope** — IC vs lead, what they own.
4. **Location / remote rules** — timezone overlap, office days.
5. **Team size and product context** — one concrete paragraph.

Everything else is secondary. Benefits encyclopedias and "culture deck" adjectives do not compensate for a missing band.

## The structure that works

### Title

Use searchable, standard titles: `Senior Software Engineer, Backend` — not `Code Wizard` or `Full Stack Ninja`. Fancy titles hurt Boolean search and LinkedIn matching.

### One-paragraph mission

What the team builds and what this person will change in the first two quarters. No mission-statement poetry.

### Responsibilities (5–7 bullets)

Start each with a verb. Describe outcomes, not tools.

Good: "Own the billing API end-to-end, including on-call for that surface."
Bad: "Experience with REST, GraphQL, gRPC, SOAP, and event-driven architectures."

### Requirements (must vs nice)

Split ruthlessly.

**Must:** 3–5 items you would reject over.
**Nice:** everything else.

If your must-have list is twelve lines, you do not have a role — you have a wish list. That is how reqs stay open for six months.

### Stack

Name the primary language and the two systems they will touch weekly. Move the rest to nice-to-have. Primary skill should match a real sourcing page — e.g. [TypeScript](/hire-developers/typescript), [Python](/hire-developers/python).

### Comp and logistics

- Salary range (location-adjusted if needed)
- Equity one-liner if applicable
- Remote / hybrid / onsite + timezone
- Interview process length (e.g. "two interviews + paid exercise, under 2 weeks")

### How to apply

One clear CTA. If you also cold-source, the JD should match the email pitch so candidates do not feel bait-and-switched.

## Template

```markdown
# Senior Software Engineer, Backend

We're hiring a senior backend engineer to own [system] for [product].
In the first six months you'll [outcome 1] and [outcome 2].

## What you'll do
- ...
- ...

## Must have
- ...
- ...

## Nice to have
- ...

## Stack you'll use weekly
Primary: [language]
Also: [system], [system]

## Comp & logistics
[salary range] · [equity note] · [remote/timezone]
Process: [steps], typically [N] weeks.

## Apply
[link] or reply to this thread with a link to work you're proud of.
```

## Common failure modes

**Kitchen-sink requirements.** "10 years Kubernetes" for a CRUD app.

**Hidden band.** Especially fatal in remote outreach.

**Copy-pasted from a different role.** Frontend JD with Java must-haves.

**Unpaid 8-hour take-homes** advertised up front — many seniors self-select out before applying.

**DEI paragraph with contradictory must-haves** (e.g. "inclusive" + degree from three specific schools only). Be consistent.

## Using the JD for sourcing

A clear primary skill + seniority lets you:

1. Open the right [skill hub](/hire-developers).
2. Write Boolean strings without guessing — [boolean guide](/guides/boolean-search-for-recruiters).
3. Personalise outreach against the same scope — [email guide](/guides/how-to-email-developers).

If you cannot explain the role in six bullets, fix that before you buy another sourcing seat.

We also have a free [job description template](/job-template-optin) and [optimizer](/job-optimizer) if you want a structured starting point.


---

### Apps for Recruitment: Sourcing, ATS, CRM — Which Do You Need?

HTML: https://www.realgreatdevs.com/blog/apps-for-recruitment
Markdown: https://www.realgreatdevs.com/blog/apps-for-recruitment.md

# Apps for Recruitment: Sourcing, ATS, CRM — Which Do You Need?

> Apps for recruitment explained by category — sourcing, ATS, CRM and outreach — so you buy the tool that matches the problem instead of a bloated suite.

- Canonical: https://www.realgreatdevs.com/blog/apps-for-recruitment
- Target query: apps for recruitment
- Funnel: bottom
- Published: 2026-08-06
- Tags: recruiting tools, ATS, buying guide

"Apps for recruitment" is a search that usually returns a pile of unrelated products. An ATS, a sourcing database and a sequencing tool all show up in the same list, then buyers wonder why nothing improved.

This page separates the categories, names a strong option in each, and tells you which one to buy first.

## The four apps most teams actually need (in order)

### 1. Sourcing — if you cannot find people

**Job:** surface candidates who are not applying.

**Examples:** LinkedIn Recruiter, SeekOut, hireEZ, RealGreatDevs, AmazingHiring.

**Buy this first when** inbound is empty and job posts are not converting.

For engineering specifically, a code-backed index ([RealGreatDevs](/hire-developers)) beats a general network when the role is technical. For mixed-function hiring, LinkedIn is still the coverage king.

### 2. Outreach — if people do not reply

**Job:** get a response from a shortlist you already have.

**Examples:** Gem sequences, hireEZ outbound, plain email done well.

**Buy this when** your list is fine and your reply rate is not. Often the fix is copy, not software — see [how to email developers](/guides/how-to-email-developers).

### 3. ATS — if the process is chaos

**Job:** track candidates, stages, interviews and offers.

**Examples:** Greenhouse, Ashby, Lever, Workable.

**Buy this when** you are losing people in the pipeline, double-booking interviews, or cannot answer "where is this candidate?" An ATS does not find engineers. Do not buy one hoping it will.

### 4. CRM — if people enter and disappear

**Job:** nurture, rediscover and measure conversion by source.

**Examples:** Gem, Teamtailor CRM features, built-in ATS CRM modules.

**Buy this when** sourcing works and process works, but warm candidates go cold between stages.

## What not to buy yet

**A full "talent intelligence platform" on day one.** SeekOut-class tools are excellent and expensive. Validate that you will use the seats weekly before signing an annual deal.

**Four apps before one is dialled in.** Stacking Gem + SeekOut + LinkedIn + an ATS while nobody owns the workflow is how budgets vanish.

**Anything that requires a six-week implementation for a two-person team.** Prefer self-serve until hiring volume is durable.

## A starter stack by company stage

| Stage | Practical stack |
| --- | --- |
| Founder, first eng hires | Free GitHub sourcing + spreadsheet + email |
| Seed / Series A, eng-heavy | Self-serve engineering sourcing + lightweight ATS |
| Multi-function team | LinkedIn Recruiter + specialist eng tool + ATS |
| Enterprise TA | SeekOut or hireEZ + Gem + full ATS, negotiated annually |

## Pricing shape of the category

Sourcing and CRM tools in this space are usually **annual, quote-based**. Self-serve exceptions (including RealGreatDevs and some Juicebox/Gem tiers) matter for small teams precisely because you can leave.

ATS pricing is often per-employee or per-job; compare total cost over a year of planned hires, not the sticker seat price alone.

## Decision in one paragraph

If you cannot name the bottleneck, do not buy an app. Find people → sourcing. Get replies → outreach or better copy. Run a clean process → ATS. Stop losing warm candidates → CRM. For engineering discovery specifically, start from the [hire-developers hub](/hire-developers) or the [sourcing software comparison](/blog/best-candidate-sourcing-software).


---

### Best Sourcing Tools for Recruiters (What Actually Holds Up)

HTML: https://www.realgreatdevs.com/blog/best-sourcing-tools-for-recruiters
Markdown: https://www.realgreatdevs.com/blog/best-sourcing-tools-for-recruiters.md

# Best Sourcing Tools for Recruiters (What Actually Holds Up)

> The best sourcing tools for recruiters in 2026, filtered for what working sourcers actually keep — not affiliate rankings or vendor claims.

- Canonical: https://www.realgreatdevs.com/blog/best-sourcing-tools-for-recruiters
- Target query: best sourcing tools for recruiters
- Funnel: bottom
- Published: 2026-08-06
- Tags: sourcing tools, recruiting, comparison

Search "best sourcing tools for recruiters" and you get affiliate listicles. Search the same phrase with "reddit" and you get people who tried the tools and then cancelled. This page is closer to the second: what holds up after the trial, including where a competitor beats us.

We build RealGreatDevs. Weigh that.

## The tools sourcers still open weekly

| Tool | Kept for | Dropped when |
| --- | --- | --- |
| LinkedIn Recruiter | Coverage across every function | Engineering-only teams that need code proof |
| SeekOut | Diversity reporting, ATS rediscovery, deep web | Budget cannot support $10K+/seat/year |
| hireEZ | Search + sequences without two vendors | Credit overages inflate the bill |
| Gem | Pipeline conversion analytics | You still cannot fill the top of funnel |
| RealGreatDevs | Engineering search on public code | You hire outside engineering |
| AmazingHiring | Specialist technical markets | You need self-serve and a monthly plan |
| Juicebox | Fast ad-hoc natural-language search | You need reproducible, saved filters |
| Wellfound | Active, salary-transparent candidates | You need passive talent |

## What "best" means on Reddit vs on vendor pages

Vendor pages optimise for feature checklists. Recruiter threads optimise for regret avoidance. The recurring themes:

**Annual contracts are the main complaint.** Teams of one or two get locked into seat counts they outgrew or never needed.

**Two tools beat one.** A broad network (LinkedIn) plus a specialist beats expecting either to cover engineering alone.

**The message beats the database.** When reply rates collapse, upgrading the tool rarely fixes it — rewriting the email does. See [how to email developers](/guides/how-to-email-developers).

**Free still works at low volume.** GitHub search, Google X-ray and community lists are repeatedly recommended before paid seats. Full playbook: [source developers for free](/guides/how-to-source-developers-for-free).

## Quick picks by situation

**Solo recruiter / founder hiring engineers:** start free on GitHub, then a self-serve specialist ([RealGreatDevs](/compare/seekout) or Juicebox) before any annual enterprise deal.

**Agency or multi-function TA team:** LinkedIn Recruiter as the base; add SeekOut or hireEZ if volume and compliance justify it.

**Conversion is broken, sourcing is fine:** Gem — not another database.

**No time to source at all:** Fetcher or a contingency agency. Software nobody operates is worse than a managed batch.

## Pricing reality check (August 2026)

- **SeekOut:** Recruit Lite $149/mo; team plans commonly $10K–$30K per seat/year ([Vendr](https://www.vendr.com/marketplace/seekout)).
- **hireEZ:** from ~$169/seat/mo; median contract near $13K/year.
- **Gem:** free under 30 employees for six months; custom above.
- **LinkedIn Recruiter:** not published; negotiated.
- **RealGreatDevs:** self-serve subscription, free account to start, no placement fees.

Negotiate. Multi-year and prepaid deals routinely land 15–25% below list in this category.

## The honest ranking for engineering hires

1. **Discovery of engineers who ship in public:** RealGreatDevs or AmazingHiring.
2. **Discovery across all functions:** LinkedIn Recruiter.
3. **Enterprise intelligence + compliance:** SeekOut.
4. **Outbound volume with search attached:** hireEZ.
5. **Nurture and conversion:** Gem.
6. **Active candidates only:** Wellfound.

If you only remember one thing: buy for the bottleneck you have, not the category page you landed on. Deeper roundups live under [candidate sourcing software](/blog/best-candidate-sourcing-software) and [best sourcing platforms](/blog/best-sourcing-platforms).


---

### Where Software Developers Live: A Map of 1.1M Located Profiles

HTML: https://www.realgreatdevs.com/blog/where-software-developers-live
Markdown: https://www.realgreatdevs.com/blog/where-software-developers-live.md

# Where Software Developers Live: A Map of 1.1M Located Profiles

> Where software developers actually live, based on 1.1 million located profiles — top countries, surprising mid-tier markets, and what it means for remote hiring.

- Canonical: https://www.realgreatdevs.com/blog/where-software-developers-live
- Target query: where do software developers live
- Funnel: top
- Published: 2026-08-06
- Tags: data study, remote hiring, geography

Remote hiring changed the question from "who is in our city?" to "who is in a timezone we can work with?" The answers people give are still mostly vibes — US, India, Eastern Europe — which is incomplete enough to waste months.

We mapped 1,115,277 developer profiles with a resolvable country in a 2.5 million profile index. Here is where they actually are.

<Callout title="About the data">
Location comes from what developers state on public GitHub profiles. Not every profile has a country; these figures are the located subset. Data as of August 2026.
</Callout>

## The top 20 countries by indexed developers

| Rank | Country | Developers |
| --- | --- | --- |
| 1 | United States | 251,534 |
| 2 | India | 128,786 |
| 3 | China | 82,597 |
| 4 | Brazil | 65,199 |
| 5 | Germany | 37,907 |
| 6 | Canada | 36,692 |
| 7 | Australia | 30,950 |
| 8 | United Kingdom | 28,442 |
| 9 | Mexico | 26,363 |
| 10 | South Korea | 21,360 |
| 11 | Colombia | 19,878 |
| 12 | Russia | 19,568 |
| 13 | Argentina | 19,031 |
| 14 | France | 17,865 |
| 15 | Japan | 17,657 |
| 16 | Indonesia | 17,052 |
| 17 | Bangladesh | 16,621 |
| 18 | Pakistan | 13,457 |
| 19 | Spain | 13,209 |
| 20 | Netherlands | 12,262 |

The United States alone is about **23%** of located developers. The top three countries together are roughly **42%**.

## The mid-tier markets most teams skip

Colombia (19,878) sits ahead of France (17,865). Bangladesh (16,621) is close to Japan (17,657). Indonesia (17,052) is larger than Spain.

These are not obscure talent deserts. They are simply less saturated with the same five job posts every US company sends to London and Berlin. If your search returns too few people, widening geography usually beats lowering the bar.

Full country pages — skills, cities, activity — are free to browse under [/hire-developers-in](/hire-developers-in/united-states).

## What this means for remote hiring

**Timezone is the real constraint, not passport.** A strong engineer eight hours offset may be worse for your standup than a slightly less famous market with four hours of overlap.

**Competition concentrates.** Everyone fishes the US, UK, Germany, Canada and India. The next ten countries on this list are large enough to hire from and quieter.

**Skill mix varies by country.** A country hub that is huge overall may be thin in your stack. Always check the skill × country page (for example [TypeScript in Poland](/hire-developers/typescript) via the skill page’s country list) rather than assuming population equals fit.

**Public-code coverage is uneven.** Markets where more work happens in private enterprise repos will be undercounted here. Treat these numbers as a lower bound, not a census.

## Practical sourcing moves

1. Pick three countries with timezone overlap you can live with.
2. Open each [country page](/hire-developers-in/india) and check whether your stack appears in the top skills.
3. Run the same filters you would domestically — recency, language, activity — before you touch compensation assumptions.
4. Write outreach that acknowledges location and timezone instead of pretending everyone is local.

For the skill-side view of the same dataset, see [What Makes a Great Developer?](/blog/what-makes-a-great-developer) and the [hire-developers directory](/hire-developers).


---

### How to Hire Remote Developers Without Wasting Three Months

HTML: https://www.realgreatdevs.com/guides/how-to-hire-remote-developers
Markdown: https://www.realgreatdevs.com/guides/how-to-hire-remote-developers.md

# How to Hire Remote Developers Without Wasting Three Months

> How to hire remote developers: pick markets, set timezone rules, source from public work, and run a process that does not lose candidates to silence.

- Canonical: https://www.realgreatdevs.com/guides/how-to-hire-remote-developers
- Target query: how to hire remote developers
- Funnel: middle
- Published: 2026-08-06
- Tags: remote hiring, sourcing, process

Remote developer hiring fails in predictable ways: the search is too narrow, the process is too slow, or the offer assumes every market prices like San Francisco. This guide is the sequence that avoids those three.

## Step 1: Decide what "remote" means for you

Write it down before you source:

- **Timezone overlap required** (e.g. 4 hours with US Eastern).
- **Countries you will not hire in** (export controls, payroll, legal).
- **Employment model** — contractor, EOR, local entity.
- **Salary band as a range you will publish.**

If you cannot publish a range, expect reply rates to collapse. Engineers discard opaque remote outreach first.

## Step 2: Pick markets with data, not vibes

Do not default to "US + Western Europe" because that is where your last hire lived. Look at pool size and skill mix.

Of 1.1M+ located developers in our index, the US is ~23% and the next tier includes India, Brazil, Germany, Canada — but also Colombia, Argentina, Bangladesh and Indonesia at meaningful scale. See [where software developers live](/blog/where-software-developers-live).

For each candidate country:

1. Open the [country hub](/hire-developers-in/germany).
2. Check whether your stack appears among top skills.
3. Confirm timezone overlap with your team.
4. Check payroll/EOR feasibility once — not after you fall in love with a candidate.

## Step 3: Source from proof, then confirm biography

For IC engineering roles, start with public work:

- GitHub search or an index of it — [GitHub sourcing guide](/guides/github-sourcing-guide).
- Filter on recency and stack, not on follower vanity metrics.
- Cross-check LinkedIn for current employer and tenure.

For eng managers, reverse it: LinkedIn first, GitHub second. Details in [LinkedIn vs GitHub](/guides/linkedin-vs-github-for-hiring).

## Step 4: Run a remote-native process

Remote candidates disappear when you treat them like local onsite interviews with worse logistics.

**Async by default.** Take-homes with clear scopes beat five live rounds across timezones.

**Calendar honesty.** Offer two windows in *their* morning, not only yours.

**Decision speed.** Aim to go offer-ready in under three weeks of active process. Slow remote processes lose to local employers who move faster.

**One owner.** Someone answers questions within a business day in the candidate's timezone overlap.

## Step 5: Write outreach that is obviously remote-aware

Mention timezone, salary range and employment model in the first email. Template patterns: [how to email developers](/guides/how-to-email-developers).

Bad: "We're a global team looking for rockstars."
Good: "Fully remote, 4-hour overlap with CET, €90–110k, contractor via EOR."

## Step 6: Compensate for the market you are in

Do not paste a Bay Area band onto Bogotá and call it generous, or paste a Bogotá band onto Berlin and call it competitive. Use:

- Local market data where you have it.
- The candidate's current situation.
- The scarcity of the skill globally (Rust ≠ JavaScript).

Paying "global" rates for scarce skills and local-adjusted rates for common ones is a common compromise — just be consistent and transparent.

## A two-week remote hire sprint

| Day | Action |
| --- | --- |
| 1 | Lock scorecard, timezone rules, salary range |
| 2–3 | Source 40 profiles across 2–3 countries |
| 4 | Cut to 15 after repository review |
| 5–6 | Personal outreach |
| 7–10 | Screens + async exercise |
| 11–12 | Final interviews |
| 13–14 | Offer and references |

If day 14 arrives with an empty pipeline, the failure was almost always step 2 or 3 — market choice or sourcing quality — not "remote is hard."

## When to use an agency anyway

One senior hire, no time, unfamiliar country, or confidentiality requirements. The fee can be rational. Decision framework: [do you need a headhunter?](/guides/hire-developers-without-a-recruiter).

Otherwise, remote hiring is a sourcing and process problem you can run yourself — starting from the [developer index by country](/hire-developers-in/united-states).


---

### How to Screen Developers on GitHub Before the Interview

HTML: https://www.realgreatdevs.com/guides/how-to-screen-developers-on-github
Markdown: https://www.realgreatdevs.com/guides/how-to-screen-developers-on-github.md

# How to Screen Developers on GitHub Before the Interview

> How to screen developers on GitHub in minutes: which signals matter, which to ignore, and a repeatable checklist before you book a call.

- Canonical: https://www.realgreatdevs.com/guides/how-to-screen-developers-on-github
- Target query: how to screen developers on github
- Funnel: middle
- Published: 2026-08-06
- Tags: screening, github, technical recruiting

Screening on GitHub is not about becoming an engineer. It is about not wasting interviews on profiles that fall apart when you open a repository.

This is a recruiter-ready checklist you can run in two to five minutes per candidate.

## Set the bar to the population

Across large skill groups in our index, the median developer has about **24 public repos, 42 contributions in the last year, and 8 followers**. Daily-green graphs are not the norm.

If you reject everyone below "active every day," you are filtering for open-source lifestyle, not competence. Calibrate with the [GitHub sourcing guide](/guides/github-sourcing-guide) baselines.

## The five-minute screen

### 1. Recency (30 seconds)

Sort repositories by recently pushed. Look for activity in the last 6–12 months.

**Pass:** ongoing work in the stack you care about.
**Fail:** last meaningful push three years ago, unless the role is management-only.

### 2. Substance over count (60 seconds)

Ignore raw repo totals. Open the largest non-fork project with a real README.

**Pass:** describes what the project does and why; has structure.
**Fail:** dozens of empty tutorial repos named `my-first-react-app`.

### 3. Commit hygiene (60 seconds)

Skim recent commits on that project.

**Pass:** messages that explain intent; steady cadence.
**Fail:** 200 commits titled `update` on one weekend, then silence.

### 4. Code smell without being an expert (60 seconds)

Open two source files.

You are not grading algorithms. Check:

- Are names readable?
- Is there any test directory or CI config?
- Does it look copied wholesale from a course?

**Pass:** organised, intentional.
**Fail:** single 2,000-line file with no structure, or obvious homework dumps only.

### 5. Collaboration signal (60 seconds)

Click Issues or Pull requests they filed on *other* people's projects.

**Pass:** clear bug reports, constructive review comments.
**Fail:** only drive-by "thanks" comments, or hostile threads — note and probe in interview rather than auto-rejecting.

This fifth step is the one most screeners skip and the most predictive of how someone behaves on a team.

## What to ignore

**Follower count across languages.** C and Bash communities show higher medians than JavaScript. It is network shape, not talent.

**Stars on a viral toy.** Popularity ≠ production quality.

**Green squares alone.** Private monorepo workers look "inactive" and may be excellent.

**Long language lists.** Fourteen languages usually means tutorials. Prefer depth in the two you need.

## A simple scorecard

| Signal | Weight | Notes |
| --- | --- | --- |
| Recency in target stack | High | Last 12 months |
| One substantial repo | High | README + structure |
| Commit quality | Medium | Intent, not spam |
| Tests / CI present | Medium | Especially for senior IC |
| External PRs / issues | Medium | Collaboration proxy |
| Followers / stars | Low | Context only |

Decide "advance / hold / reject" from this table before you write the email. Do not invent new criteria mid-pipeline.

## After the screen

**Advance:** send a short, specific note naming the repo you liked — [email templates](/guides/how-to-email-developers).

**Hold:** good overall, wrong stack depth — keep for a different role.

**Reject:** no need to message. Spend the time on the next profile.

## When GitHub screening is the wrong tool

- Role is primarily people management with little coding expected.
- Candidate works in a regulated environment that forbids public code.
- You already have a strong work trial ahead; then screen lightly and let the trial decide.

Otherwise, five minutes here saves fifty minutes in a wasted interview. Pair with [Boolean search](/guides/boolean-search-for-recruiters) to build the list, then this checklist to cut it.


---

### Time to Hire Software Engineers: Where the Weeks Actually Go

HTML: https://www.realgreatdevs.com/guides/time-to-hire-software-engineers
Markdown: https://www.realgreatdevs.com/guides/time-to-hire-software-engineers.md

# Time to Hire Software Engineers: Where the Weeks Actually Go

> Where time to hire software engineers is lost — sourcing, scheduling, decision lag — and a practical timeline to cut weeks without lowering the bar.

- Canonical: https://www.realgreatdevs.com/guides/time-to-hire-software-engineers
- Target query: time to hire software engineer
- Funnel: middle
- Published: 2026-08-06
- Tags: hiring process, recruiting, operations

Ask a team their time-to-hire for engineers and you get a number that mixes "days since we opened the req" with "days since we started seriously looking." Those are different clocks. This guide splits the timeline so you can see which stage is actually burning weeks.

## A realistic breakdown

For a mid-level IC role with a working process:

| Stage | Healthy duration | Where it explodes |
| --- | --- | --- |
| Scorecard + salary lock | 1–2 days | Debating requirements for three weeks |
| Sourcing shortlist | 3–7 days | Searching without filters or proof |
| Outreach → first reply | 3–10 days | Generic emails, no salary |
| Screens | 3–5 days | Calendar chaos across timezones |
| Deep interviews / exercise | 5–10 days | Take-home with no deadline or review SLA |
| Decision + offer | 2–4 days | "Let's sync next week" loops |
| Notice period | 2–12 weeks | Not under your control |

If your "time to hire" is 90 days, notice period may be half of it. Fix the controllable middle first.

## The three leaks that add the most days

### 1. Sourcing without a scorecard

Starting outreach before you agree on must-haves produces the wrong shortlist, which produces restarts. Lock the scorecard first — stack, seniority, timezone, salary — then source. [Remote hiring sequence](/guides/how-to-hire-remote-developers) covers the same discipline.

### 2. Outreach that does not earn replies

Every day of silence is usually a copy problem, not a market problem. Specific, short, salary-transparent notes outperform sequences. Templates: [how to email developers](/guides/how-to-email-developers).

### 3. Decision lag after the last interview

The candidate is done; your team is "waiting for alignment." This is the most expensive delay because strong candidates are also talking to someone faster. Rule: same-day debrief, offer decision within 48 hours of the final round.

## A 21-day controllable target (excluding notice)

| Days | Milestone |
| --- | --- |
| 0–1 | Scorecard, range, interview panel locked |
| 2–6 | Source and screen 30–40 profiles on proof ([GitHub screen](/guides/how-to-screen-developers-on-github)) |
| 5–8 | Outreach wave 1 (15 people) |
| 8–12 | Screens + exercise sent |
| 12–18 | Final interviews |
| 18–21 | Offer out |

Miss the window? Restart sourcing in parallel on day 14 — do not wait for the first wave to fully die.

## What not to cut

**A real look at their work.** Skipping repository or work-sample review to "go faster" creates failed hires, which is the slowest outcome of all.

**Reference or background checks your company requires.** Compress calendar, not compliance.

**Candidate questions.** Slow answers here feel like disinterest and kill acceptance rates.

## Tooling that actually shortens the clock

- **Faster shortlists:** filters on activity and stack beat manual LinkedIn paging — start from [hire-developers](/hire-developers).
- **Fewer no-shows:** calendar links with timezone detection.
- **Fewer loop-backs:** written scorecards shared with every interviewer before the call.
- **Fewer stalled offers:** pre-approved bands so comp does not restart negotiation internally after the candidate expects an offer.

Buying another ATS will not fix a team that cannot decide. Buying sourcing help will not fix a three-week take-home nobody grades.

## How to measure it next quarter

Track separately:

1. **Days from scorecard-ready to first outbound.**
2. **Days from first outbound to first onsite/final.**
3. **Days from final to offer sent.**
4. **Days from offer to start** (includes notice).

Improve (1)–(3). Report (4) honestly so leadership stops blaming recruiting for resignation clocks.

If (1) is the problem, you have a sourcing issue — [free sourcing](/guides/how-to-source-developers-for-free) or a specialist tool. If (3) is the problem, you have a leadership issue — no software fixes that.


---

### Best Recruitment Apps in 2026: Ranked by the Job They Solve

HTML: https://www.realgreatdevs.com/blog/best-recruitment-apps
Markdown: https://www.realgreatdevs.com/blog/best-recruitment-apps.md

# Best Recruitment Apps in 2026: Ranked by the Job They Solve

> The best recruitment apps in 2026, ranked by whether you need sourcing, outreach, ATS or CRM — with honest trade-offs and sourced pricing.

- Canonical: https://www.realgreatdevs.com/blog/best-recruitment-apps
- Target query: best recruitment apps
- Funnel: bottom
- Published: 2026-08-05
- Tags: recruiting tools, apps, buying guide

Most "best recruitment apps" roundups dump every ATS, CRM and sourcing tool into one ranking. That is useless, because those apps solve different problems. This list is organised by the job you are stuck on.

We build a sourcing tool in this category, so weigh that when we appear below.

## Ranked by the problem, not by marketing spend

### 1. Best for finding engineers: RealGreatDevs

Indexes 2.5 million software engineers from public GitHub activity. You filter on what people have shipped — languages, contributions, repositories, country — rather than on a self-reported skill list.

**Pricing:** self-serve with a free account. No placement fees. Browse [skills](/hire-developers) and [countries](/hire-developers-in/united-states) for free.

**Not for you if** you hire sales, design or finance from the same seat.

### 2. Best for finding anyone: LinkedIn Recruiter

The broadest professional network. Every function is covered. For engineering alone it is weaker than a specialist, because profiles are self-reported and many engineers keep them minimal.

**Pricing:** not published; negotiated per contract.

### 3. Best enterprise sourcing stack: SeekOut

Talent intelligence with diversity analytics, ATS rediscovery and deep public-web enrichment. Priced for a dedicated talent function.

**Pricing:** Recruit Lite $149/mo; team plans commonly $10K–$30K per seat/year. ([Vendr](https://www.vendr.com/marketplace/seekout), August 2026.)

### 4. Best search + outreach combo: hireEZ

Sourcing and sequencing in one product, aggregated from 45-plus sources. Cheaper entry than SeekOut for small teams.

**Pricing:** from ~$169/seat/mo; median contract near $13K/year.

### 5. Best for converting your pipeline: Gem

A recruiting CRM, not a search tool. Best pipeline analytics in the category. Use it when people enter and drop out — not when you cannot find anyone.

**Pricing:** free under 30 employees for six months; custom above.

### 6. Best managed option: Fetcher

A human team delivers curated candidate batches. Right when you have no sourcing capacity and would rather buy the outcome.

**Pricing:** quote-based subscription.

### 7. Best for active startup candidates: Wellfound

Candidates opt in, state salary expectations and are open to work. High response rates, small pool, startup-skewed.

**Pricing:** free tier to start.

### 8. Best lightweight AI search: Juicebox

Natural-language search over an aggregated index. Fast to trial, less reproducible than explicit filters.

## Apps recruiters regret buying

From the pattern of complaints in recruiter communities:

**An ATS when the problem was sourcing.** An applicant tracker does not invent candidates.

**An annual seat for a two-person team.** Volume rarely justifies the commitment in year one.

**A "sourcing" tool that is actually a CRM.** Gem and similar products manage relationships; they do not replace discovery.

**Anything that cannot be trialled without a sales call.** If you cannot test it on a real open role first, you are guessing.

## A simple decision rule

1. Can you find enough people? If no → search tool.
2. Do people reply? If no → fix the message before buying outreach software.
3. Do people enter then vanish? → CRM.
4. Is the process a mess? → ATS.

Only buy the next layer when the current one is working. Stacking four apps before any of them is dialled in is how recruitment software budgets get wasted.

For deeper comparisons see [candidate sourcing software](/blog/best-candidate-sourcing-software) and the [tool-by-tool pages](/compare).


---

### Best Sourcing Platforms for Recruiters in 2026

HTML: https://www.realgreatdevs.com/blog/best-sourcing-platforms
Markdown: https://www.realgreatdevs.com/blog/best-sourcing-platforms.md

# Best Sourcing Platforms for Recruiters in 2026

> An honest comparison of the best sourcing platforms for recruiters, covering pricing, data quality and which tools actually win for engineering hires.

- Canonical: https://www.realgreatdevs.com/blog/best-sourcing-platforms
- Target query: best sourcing platforms
- Funnel: bottom
- Published: 2026-08-05
- Tags: sourcing tools, comparison, recruiting

"Best sourcing platforms" lists usually rank tools by affiliate commission. This one ranks them by the job they actually do, with sourced pricing and cases where a competitor is the better pick — including over us.

We build one of the platforms below. Read accordingly.

## What "sourcing platform" means in practice

Three products get sold under one label:

**Search platforms** answer "who exists?" SeekOut, hireEZ, AmazingHiring, RealGreatDevs.

**Engagement platforms** answer "how do I convert them?" Gem is the clearest example.

**Marketplaces** answer "who is looking?" Wellfound, and to a lesser extent LinkedIn Easy Apply pools.

If your bottleneck is discovery, a CRM will not fix it. If people enter the pipeline and vanish, a bigger database will not either. Diagnose before you buy.

## The short list

| Platform | Best for | Entry pricing |
| --- | --- | --- |
| LinkedIn Recruiter | Hiring across every function | Not published; negotiated |
| SeekOut | Enterprise talent intelligence | From $149/mo; team plans $10K–$30K/seat/yr |
| hireEZ | Search + outbound in one tool | From ~$169/seat/mo |
| Gem | Converting candidates you already have | Free under 30 employees; custom above |
| RealGreatDevs | Engineering sourcing from public code | Self-serve, free account to start |
| AmazingHiring | Specialist technical sourcing | Annual contract, not published |
| Juicebox | Fast natural-language search | Self-serve subscription |
| Wellfound | Active startup candidates | Free tier available |

## LinkedIn Recruiter

Still the default for most teams. Coverage is unmatched across functions, and InMail reaches people where they already are.

For engineering specifically, profiles are self-reported and many engineers keep them thin. You are searching descriptions of work rather than work. Fine as a base layer; weak as the only engineering tool.

**Pricing:** not published. Recruiter Lite is widely reported in the low thousands per seat per year; Corporate is higher and negotiated.

## SeekOut

Deep public-web enrichment (GitHub, patents, publications), the strongest diversity reporting in the category, and ATS rediscovery that surfaces candidates you already paid for.

**Pricing:** Recruit Lite at $149/mo billed annually. Team plans are custom; independent data puts real contracts at $10,000–$30,000 per seat per year. ([Vendr](https://www.vendr.com/marketplace/seekout), checked August 2026.)

**Skip it if** you are a founder or a team of two. This is priced for a dedicated TA function.

## hireEZ

Aggregates 45-plus sources and includes outbound sequencing. The usual first stop for teams that want SeekOut-like capability at a lower entry point.

**Pricing:** entry around $169 per seat per month; median contract near $13,000/year. ([Glozo](https://www.glozo.com/blog/seekout-vs-hireez), checked August 2026.)

## Gem

Not primarily a sourcing platform. It is a recruiting CRM: sequences, nurture and pipeline analytics. If candidates enter and drop out, Gem is the right answer. If you cannot find anyone, it is not.

**Pricing:** free for companies under 30 employees for six months, then discounted; self-serve startup pricing from around $130/seat/mo. ([Glozo](https://www.glozo.com/blog/seekout-vs-gem), checked August 2026.)

## RealGreatDevs

Ours. Indexes 2.5 million engineers from public GitHub activity and lets you filter on contribution history, languages, repositories and location. Self-serve, no annual commitment, no placement fees. Aggregate data by [skill](/hire-developers) and [country](/hire-developers-in/united-states) is free to browse.

**Skip it if** you hire outside engineering, or if your candidates work only in private repositories.

## AmazingHiring, Juicebox and Wellfound

**AmazingHiring** is a specialist technical tool with strong Eastern European coverage — annual contract, no self-serve. **Juicebox** is the fastest natural-language entry point for small teams. **Wellfound** reaches active, startup-inclined candidates with stated salary expectations, which is a different (and smaller) pool.

## What Reddit threads usually conclude

Across r/recruiting and related threads, the recurring consensus is:

1. No single platform covers engineering well enough alone.
2. Annual contracts are the main regret for small teams.
3. The message matters more than the tool.
4. Free GitHub and X-ray search outperform paid tools when volume is low.

That last point is why our [free sourcing guide](/guides/how-to-source-developers-for-free) exists.

## How to choose

**Only hiring engineers, small team:** start free on GitHub, then add a specialist tool once volume justifies it.

**Hiring across functions:** LinkedIn Recruiter as the base, plus a specialist for the hardest function.

**Enterprise with compliance needs:** SeekOut, and negotiate — 15–25% below list is normal.

**Conversion is the bottleneck:** Gem, not another search tool.

Full head-to-heads are in our [comparisons](/compare). Switching cases are under [alternatives](/alternatives).


---

### Great Developers: What 2.5M Profiles Actually Look Like

HTML: https://www.realgreatdevs.com/blog/great-developers
Markdown: https://www.realgreatdevs.com/blog/great-developers.md

# Great Developers: What 2.5M Profiles Actually Look Like

> What great developers look like in public data — medians, outliers and the signals that matter when you are hiring, drawn from 2.5 million profiles.

- Canonical: https://www.realgreatdevs.com/blog/great-developers
- Target query: great developers
- Funnel: top
- Published: 2026-08-05
- Tags: data study, hiring, engineering

"Great developers" is a phrase people use when they mean "I will know it when I see it." That is fine for a gut check after an interview. It is useless as a sourcing filter.

So we looked at the opposite question: what does the public record of 2.5 million developers actually show about activity, geography and skill mix — and which of those numbers are worth using when you hire?

This is a companion to [What Makes a Great Developer?](/blog/what-makes-a-great-developer). That piece challenges the usual myths. This one is the field guide: what the population looks like, so your bar is calibrated to reality.

<Callout title="About the data">
Figures come from an index of public GitHub activity covering 2.5 million developer profiles, of which 1,115,277 have a resolvable country. Data as of August 2026.
</Callout>

## The middle of the market is quieter than LinkedIn suggests

Across the largest skill populations, a typical developer has roughly:

- **24 public repositories**
- **42 contributions in the last year**
- **8 followers**

That is the median, not the left tail. If your mental model of a "great developer" requires a green contribution graph every day, you have defined greatness as "works in the open" — which correlates with employer policy and career stage more than with ability.

| Skill | Median contributions | Median repos | Median followers |
| --- | --- | --- | --- |
| JavaScript | 42 | 24 | 8 |
| Python | 44 | 22 | 8 |
| TypeScript | 69 | 27 | 9 |
| Java | 39 | 25 | 8 |
| C++ | 43 | 28 | 10 |

TypeScript sits higher on contributions (69) than most languages. That is selection, not proof of superiority: people who adopt TypeScript deliberately tend to be more engaged with tooling. Always compare within a population.

## Where the great ones actually cluster

The largest skill populations are not where scarcity lives:

1. JavaScript — 1,336,934
2. HTML — 1,202,938
3. Python — 1,153,995
4. TypeScript — 749,904
5. Java — 743,885

Rust (127,090), Kotlin (123,406) and Swift (105,978) are an order of magnitude smaller. A "great JavaScript developer" search is a ranking problem. A "great Rust developer" search is a response-rate problem. Treating them the same stalls the hire.

Geography is similarly skewed. Of located developers:

| Country | Developers |
| --- | --- |
| United States | 251,534 |
| India | 128,786 |
| China | 82,597 |
| Brazil | 65,199 |
| Germany | 37,907 |

The US alone is about 23% of located profiles. Colombia sits ahead of France. Bangladesh is close to Japan. If you only search the markets you already know, you are fishing where everyone else is fishing.

Browse the full breakdown on the [skill](/hire-developers) and [country](/hire-developers-in/united-states) hubs.

## Signals that separate useful profiles from noise

**Recency over volume.** Forty contributions spread across twelve months beats four hundred in one burst two years ago.

**Depth over breadth.** Sustained work in two languages is more legible than fourteen tutorial repos.

**Relative scores over absolute ones.** Sixty contributions is unremarkable in TypeScript and strong in Java.

**Public disagreement in issues.** How someone behaves in another maintainer's repository is the best free collaboration signal available.

None of these prove greatness. They narrow two million people to a shortlist worth talking to — which is the only thing public data is good for.

## What the data cannot tell you

How someone reasons about a problem they have not seen. How they handle disagreement in a team. Whether they can explain a technical decision to a non-engineer. Those still require a conversation.

Any tool — including ours — that claims otherwise is overselling.

## Practical takeaway

Calibrate your filters to the population you are hiring from. Widen geography before you lower the bar. Read repositories, not graphs. And when you find someone who looks strong on paper, talk to them — the public record is the start of the evaluation, not the end.

Every figure here comes from the same index you can search. Start with the [free skill pages](/hire-developers), or go deeper with the [full data study](/blog/what-makes-a-great-developer).


---

### Boolean Search for Recruiters: The Operators That Still Work

HTML: https://www.realgreatdevs.com/guides/boolean-search-for-recruiters
Markdown: https://www.realgreatdevs.com/guides/boolean-search-for-recruiters.md

# Boolean Search for Recruiters: The Operators That Still Work

> Boolean search operators for recruiters on LinkedIn, Google and GitHub — with copy-paste examples for engineering roles that return usable shortlists.

- Canonical: https://www.realgreatdevs.com/guides/boolean-search-for-recruiters
- Target query: boolean search for recruiters
- Funnel: middle
- Published: 2026-08-05
- Tags: sourcing, boolean search, recruiting

Boolean search is still the fastest free way to cut a huge candidate pool down to something you can act on. Most recruiter Boolean strings fail because they are either too clever or too vague — not because the operators stopped working.

This guide covers the operators that matter, copy-paste patterns for engineering roles, and where Boolean search hits a wall.

## The operators you actually need

| Operator | Meaning | Example |
| --- | --- | --- |
| `AND` | Both terms required | `python AND django` |
| `OR` | Either term | `react OR "react.js"` |
| `NOT` / `-` | Exclude | `java NOT javascript` |
| `"quotes"` | Exact phrase | `"staff engineer"` |
| `()` | Group logic | `(go OR golang) AND kubernetes` |
| `site:` | Limit to a domain (Google) | `site:github.com` |
| `intitle:` | Words in the page title | `intitle:resume python` |

Most tools accept the same core set. LinkedIn Recruiter, Google and GitHub each have quirks — covered below.

## LinkedIn Boolean that works for engineers

LinkedIn’s search is noisy because titles are invented. Prefer skills and past employers over exact titles.

```
("software engineer" OR "software developer" OR "backend engineer")
AND (python OR django OR fastapi)
AND NOT (intern OR student OR "looking for internship")
```

For a senior hire:

```
("senior software engineer" OR "staff engineer" OR "principal engineer")
AND (typescript OR "node.js")
AND (aws OR gcp OR kubernetes)
```

Tips that save hours:

- Put alternate spellings in an `OR` group: `(react OR "react.js" OR reactjs)`.
- Exclude agencies and job posts with `NOT ("we're hiring" OR "open role" OR recruiter)`.
- Location filters in the UI are more reliable than typing city names into Boolean.

## Google X-ray for profiles LinkedIn misses

X-ray means searching a site through Google, which often returns cleaner results than the site’s own search.

GitHub users:

```
site:github.com "senior engineer" python location poland -inurl:repositories
```

Personal sites and portfolios:

```
site:*.dev ("software engineer" OR "backend engineer") (golang OR go) -jobs
```

Resumes on the open web (use carefully, and respect privacy norms):

```
intitle:resume OR intitle:cv ("software engineer") (rust OR golang) filetype:pdf
```

Conference speakers — chronically underused:

```
"speaker" "kubernetes" (2024 OR 2025 OR 2026) conference -site:linkedin.com
```

## GitHub’s own search syntax

GitHub user search is more structured. Useful operators:

```
language:typescript location:berlin followers:>50 repos:>15 type:user
```

```
language:rust created:<2019-01-01 location:portugal type:user
```

Limits to know:

- Results cap at 1,000. Split with `created:` ranges.
- `location:` is free text — run "Berlin", "Berlin, Germany" and "🇩🇪 Berlin" separately.
- There is no "contributed in the last six months" filter. That is the biggest gap versus a dedicated index.

Full walkthrough: [GitHub sourcing guide](/guides/github-sourcing-guide).

## A reusable engineering Boolean template

Swap the bracketed parts:

```
("[title1]" OR "[title2]" OR "[title3]")
AND ([skill1] OR [skill2] OR "[skill alias]")
AND ([cloud] OR [framework])
AND NOT (intern OR student OR "bootcamp graduate" OR recruiter)
```

Example for a mid-level React hire:

```
("frontend engineer" OR "software engineer" OR "web developer")
AND (react OR "react.js" OR next.js)
AND (typescript OR javascript)
AND NOT (intern OR student OR recruiter)
```

## Where Boolean search stops being enough

**No activity filter on LinkedIn or GitHub user search** for “committed recently.” You will email people who left engineering two years ago.

**No dedupe across sources.** The same person appears under three identities.

**Location spelling multiplies work.** Every country and city needs variants.

**Contact lookup is still manual.** A shortlist is not an inbox.

When you hit those walls, a tool that indexes activity directly — like [filtering the same public data with recency and country](/hire-developers) — is usually faster than inventing more clever Boolean.

## A one-hour workflow

1. Write one Boolean string for LinkedIn and one X-ray for GitHub.
2. Save 30 plausible profiles with a note on why each looked interesting.
3. Cut to 15 after two minutes on each person’s best repository or recent role.
4. Find emails; write individually. Twenty specific messages beat two hundred generic ones.

For the free end-to-end version of this workflow, see [How to Source Developers for Free](/guides/how-to-source-developers-for-free).


---

### How to Email Developers So They Actually Reply

HTML: https://www.realgreatdevs.com/guides/how-to-email-developers
Markdown: https://www.realgreatdevs.com/guides/how-to-email-developers.md

# How to Email Developers So They Actually Reply

> A practical guide to cold emailing software engineers: subject lines, length, salary transparency and templates that get replies without sounding like spam.

- Canonical: https://www.realgreatdevs.com/guides/how-to-email-developers
- Target query: how to email developers
- Funnel: middle
- Published: 2026-08-05
- Tags: outreach, sourcing, email

Most outreach to engineers fails before the first sentence is finished. Not because developers hate recruiters — because the average message could have been sent to a thousand people, and they can tell.

This guide covers what to write, what to leave out, and a few templates that consistently outperform volume blasts.

## What engineers say they ignore

Across public threads and what we hear from candidates:

1. **No salary range.** Discarded immediately by a large share of senior engineers.
2. **Wrong stack.** "We need a React rockstar" sent to a Rust maintainer.
3. **Vague company.** "A fast-growing startup in the [space] space."
4. **Fake personalisation.** "I loved your work on [repo]" when the repo is a fork they have not touched in years.
5. **Long emails.** Anything past ~150 words gets skimmed or skipped.

Fix those five and you are already ahead of most sequences.

## The structure that works

**Subject line:** specific and short. Name the repo, the role, or the company — not "Exciting opportunity!!"

Good:
- `Your work on [repo]`
- `[Company] — [role], [salary range]`
- `Quick question about [specific project]`

Bad:
- `Opportunity for a talented engineer`
- `Are you open to new roles?`
- `We're hiring!`

**First line:** prove you looked. One concrete observation. No compliments you cannot defend.

**Second block:** the role in one or two sentences — what they would own, not a list of requirements.

**Third:** money, location/remote, and a clear ask.

**Close:** an easy no, plus a referral ask. Engineers who are not looking often know someone who is.

## A template that gets replies

```
Subject: Your work on [repo]

Hi [name] — I came across [repo] while looking at [specific thing].
[One sentence on what you actually noticed.]

We're building [one line] at [company]. Looking for someone to own
[area]. It's [salary range], [location or remote policy].

Worth a conversation? Equally happy to hear it's a no, or to be
pointed at someone you rate.

[Your name]
```

Keep the whole thing under 150 words. If you need a paragraph about benefits, put it on a page and link it.

## Subject lines worth testing

| Pattern | Example |
| --- | --- |
| Repo reference | `Your parser in [repo]` |
| Mutual context | `[Conference] talk → [Company] role` |
| Direct role + money | `Staff eng, $180–210k, remote EU` |
| Referral framing | `Who should I talk to about [problem]?` |

Avoid urgency theatre ("only open for 48 hours") unless it is true. Engineers treat fake urgency as a filter for bad employers.

## Personalisation that is real vs fake

**Real:** you opened their most recent substantial repository, named a design choice, and tied it to the role.

**Fake:** you mail-merged `{{top_repo}}` and praised a tutorial they pushed during a bootcamp.

Two minutes of reading beats any enrichment tool. If you cannot spare two minutes, do not send the email.

## Follow-up without becoming spam

One follow-up after five to seven days is enough. Shorter than the first email. No guilt.

```
Subject: Re: Your work on [repo]

Hi [name] — bumping once in case this got buried.
Happy to close the loop if timing's wrong.

[Your name]
```

Then stop. A third email rarely converts and often burns the domain reputation for your whole team.

## Where to find the address

1. Listed on their GitHub profile or personal site.
2. Commit author email on a public repository (`git log`).
3. Company page or conference bio.

Commit emails are public, but people do not expect bulk sequences there. Use the address for a single, relevant note — never a drip campaign.

## When the message is not the problem

If replies are still near zero after specific, short, salary-transparent emails:

- **Wrong pool.** You are emailing inactive or mismatched profiles. Tighten filters — see the [GitHub sourcing guide](/guides/github-sourcing-guide).
- **Wrong market.** Comp or remote policy is off for that country. Check [country pages](/hire-developers-in/united-states) for pool size before blaming copy.
- **Brand unknown and role unremarkable.** Lead with the problem they would solve, not the company adjective list.

Sourcing and messaging are different jobs. [Finding people](/guides/how-to-source-developers-for-free) does not fix a bad email, and a great email does not fix a bad list.


---

### LinkedIn vs GitHub for Hiring Engineers: When to Use Each

HTML: https://www.realgreatdevs.com/guides/linkedin-vs-github-for-hiring
Markdown: https://www.realgreatdevs.com/guides/linkedin-vs-github-for-hiring.md

# LinkedIn vs GitHub for Hiring Engineers: When to Use Each

> LinkedIn vs GitHub for hiring software engineers — what each source is good for, where each fails, and a practical workflow that uses both.

- Canonical: https://www.realgreatdevs.com/guides/linkedin-vs-github-for-hiring
- Target query: linkedin vs github hiring
- Funnel: middle
- Published: 2026-08-05
- Tags: sourcing, linkedin, github

LinkedIn and GitHub answer different questions about the same person. Using only one is how teams either drown in unverified profiles or miss engineers who never maintained a public portfolio.

This guide is the decision rule for when to start on each, and how to combine them without doubling the work.

## What each source actually tells you

| | LinkedIn | GitHub |
| --- | --- | --- |
| **Primary signal** | What someone says they do | What someone has published |
| **Coverage** | Nearly every professional | Engineers who work in the open |
| **Skill proof** | Self-reported | Repositories and contributions |
| **Contact norms** | InMail, established | Email / social, colder |
| **Non-engineering roles** | Excellent | Almost none |
| **Activity freshness** | Job changes, posts | Commits and PRs |

LinkedIn is a directory of claims. GitHub is a partial record of work. Great hiring uses claims to find people and work to filter them — or the reverse, depending on the role.

## When to start on LinkedIn

**You hire across functions.** Sales, product and engineering from one seat. Nothing else matches coverage.

**The role is management-heavy.** Engineering managers and directors often have thin public repos and rich LinkedIn histories.

**You need warm paths.** Shared connections, alumni networks and InMail still matter for passive senior candidates.

**The stack is common and the market is flooded.** For a generic React role in a major city, LinkedIn’s problem is ranking, not finding — and title search is good enough to start.

## When to start on GitHub

**The role is deeply technical.** Compilers, infrastructure, security, data systems — public code separates practitioners from keyword collectors.

**You are hiring for a scarce skill.** Rust, Zig, niche ML stacks. The LinkedIn pool is full of aspirational skill tags; GitHub shows who ships.

**Resumes have been unreliable.** If your last three hires looked perfect on LinkedIn and weak in a take-home, flip the order: code first, biography second.

**You want filters LinkedIn cannot express.** Contribution recency, repository count, language mix as primary sort keys. See the [GitHub sourcing guide](/guides/github-sourcing-guide).

## Where each one fails

**LinkedIn fails on verification.** Anyone can list Kubernetes. Nothing checks it.

**LinkedIn fails on engineer engagement.** Many strong engineers update LinkedIn only when they change jobs.

**GitHub fails on private work.** Excellent engineers at banks, defence and big tech may show almost nothing public.

**GitHub fails on soft context.** You will not see that someone led a 40-person org or prefers management track.

**Both fail on contact quality** if you spray generic messages. The [outreach guide](/guides/how-to-email-developers) matters more than the source.

## A workflow that uses both

**Path A — GitHub first (specialist IC roles)**

1. Search GitHub (or an index of it) for skill + activity + country.
2. Shortlist 20 people whose repositories look real.
3. Cross-check LinkedIn for current employer, tenure and whether they are open to work.
4. Email the ones who still fit, referencing the work you saw.

**Path B — LinkedIn first (mixed or leadership roles)**

1. Boolean search LinkedIn for title + stack + location.
2. For each promising profile, find their GitHub (bio link, Google `site:github.com "Full Name"`).
3. Drop anyone with no public trail *if* the role requires hands-on depth; keep them if it is primarily leadership.
4. Personalise outreach from whichever source had the stronger signal.

**Path C — marketplace when speed beats depth**

If you need someone who is already looking, [Wellfound](/blog/best-candidate-sourcing-software) or LinkedIn Open to Work beats cold outbound. Trade-off: smaller, more competed pool.

## Cost comparison in plain terms

LinkedIn Recruiter is an annual seat licence, price not published, typically thousands per seat per year. GitHub search is free and capped. Indexes built on public GitHub data (including [ours](/hire-developers)) sit in between: self-serve subscriptions without placement fees.

For a single hire, free GitHub + careful LinkedIn cross-check is often enough. For ongoing hiring, paying for one broad tool and one engineering-specialist tool usually beats expecting either to cover everything.

## The short answer

| Situation | Start with |
| --- | --- |
| Specialist IC, scarce skill | GitHub |
| Eng manager / director | LinkedIn |
| High-volume common stack | LinkedIn, verify on GitHub |
| Multi-function recruiting team | LinkedIn + specialist for eng |
| Zero budget | GitHub + [free sourcing playbook](/guides/how-to-source-developers-for-free) |

You do not have to pick a winner. You have to pick an order. Start where the signal matches the role, then use the other source to confirm — not the other way around.


---

### Which App Is Best for Recruiting New Talent? 8 Compared

HTML: https://www.realgreatdevs.com/blog/best-apps-for-recruiters
Markdown: https://www.realgreatdevs.com/blog/best-apps-for-recruiters.md

# Which App Is Best for Recruiting New Talent? 8 Compared

> A practical rundown of recruiting apps in 2026, organised by the job you are hiring for rather than by vendor marketing, with sourced pricing for each.

- Canonical: https://www.realgreatdevs.com/blog/best-apps-for-recruiters
- Target query: apps for recruiters
- Funnel: bottom
- Published: 2026-08-04
- Tags: recruiting tools, comparison, buying guide

"Which app is best for recruiting new talent" has no single answer, because recruiting is four different jobs and no app is best at all of them. The useful version of the question is which app is best for the job you are stuck on.

This page is organised that way: by the problem, not the vendor. We build one of the tools mentioned, and we have tried to be specific about where it does not fit.

## First, work out which job you are stuck on

**Finding people.** You need candidates who do not know your company exists. Sourcing tools.

**Reaching them.** You have a list and need replies. Outreach and sequencing tools.

**Managing them.** People are in your pipeline and things are falling through. An applicant tracking system.

**Converting them.** People enter the pipeline and drop out. CRM and analytics.

Buying an app for the wrong job is the most common way recruiting software disappoints. An ATS will not find you candidates. A sourcing tool will not stop your process leaking. Diagnose first.

## For finding engineers specifically

### RealGreatDevs

Ours, so weigh accordingly. It indexes 2.5 million software engineers from public GitHub activity and lets you filter on what they have actually built — languages, repository count, contribution recency, country — rather than on a self-reported skill list.

The reason it exists: engineers are the hardest group to evaluate from a profile, because profiles describe work rather than showing it. Public code shows it.

**Pricing:** self-serve with a free account to start, no annual commitment or placement fees. Aggregate data by [skill](/hire-developers) and [country](/hire-developers-in/united-states) is free to browse.

**Not for you if** you hire outside engineering. It covers nothing else.

### AmazingHiring

A specialist technical sourcing tool aggregating engineer profiles from 50-plus sources including GitHub and Stack Overflow, with strong coverage in Eastern European and CIS markets. Merges multiple online identities into a single profile, which saves real time.

**Pricing:** not published; annual per-seat contract, so evaluating it means a sales conversation.

## For finding candidates across every function

### LinkedIn Recruiter

Still the broadest coverage available. Effectively every professional has a profile, and InMail reaches people where they already are.

For engineering specifically, the weakness is that profiles are self-reported and engineers are among the least active groups on the network. For every other function, it is hard to beat.

**Pricing:** not published. Reported figures put Recruiter Lite in the low thousands per seat per year, with Recruiter Corporate negotiated per contract.

### SeekOut

Talent intelligence with the deepest compliance and diversity reporting in the category, plus ATS rediscovery that surfaces candidates you already paid to source.

**Pricing:** Recruit Lite at $149 per month billed annually. Team plans are custom; independent procurement data puts real contracts at $10,000–$30,000 per seat per year. ([Vendr](https://www.vendr.com/marketplace/seekout), checked August 2026.)

**Not for you if** you are a small team. This is priced for a dedicated talent function.

### hireEZ

Search plus outbound automation in one product, aggregating from 45-plus sources. The usual choice for teams wanting SeekOut-style capability at a lower entry point.

**Pricing:** entry tier reported around $169 per seat per month, median contract near $13,000 a year. ([Glozo](https://www.glozo.com/blog/seekout-vs-hireez), checked August 2026.)

## For reaching and converting candidates

### Gem

A recruiting CRM with the strongest pipeline analytics in the category — conversion by source, stage-by-stage drop-off, the numbers that tell you where your process actually leaks. Sequencing and nurture are more mature than in most sourcing tools.

**Pricing:** custom by company size. Under 30 employees gets All-in-One free for six months plus a discounted first paid year; self-serve startup pricing reported from around $130 per seat per month billed annually. ([Glozo](https://www.glozo.com/blog/seekout-vs-gem), checked August 2026.)

**Not for you if** your problem is finding candidates. Gem manages relationships with people you have already found.

### Fetcher

A managed sourcing service rather than an app you operate. A human team curates candidate batches and delivers them. The right call if you have no sourcing capacity and would rather buy the outcome.

**Pricing:** quote-based subscription priced per batch.

## For candidates who are already looking

### Wellfound

Formerly AngelList Talent. Candidates opt in, state salary expectations up front, and are actively open to work, so response rates far exceed cold outbound.

The pool is limited to active candidates and skews strongly toward startups — but it is free to start, which makes it an easy addition rather than a replacement.

## What recruiters on Reddit actually recommend

The recurring themes in r/recruiting and r/recruitinghell discussions, which are worth more than most vendor comparisons:

**Free sourcing works better than people expect.** GitHub search, Google X-ray syntax and community Slack groups cost nothing and are frequently the highest-response channels. Our [free sourcing guide](/guides/how-to-source-developers-for-free) covers the syntax.

**The message matters more than the tool.** The most consistent complaint from engineers is generic outreach. A specific, short, evidently researched message outperforms volume regardless of which app sent it.

**Annual contracts are the main regret.** The most common frustration is being locked into a seat count that no longer matches the team. Prefer monthly or self-serve until you know the volume is durable.

**Two tools usually beat one.** Different indexes surface different people. Teams reporting the best results generally run one broad tool and one specialist rather than expecting either to cover everything.

## The honest recommendation

**Hiring only engineers, small team:** start with free GitHub sourcing to learn what your market looks like, then add a specialist tool once volume justifies it.

**Hiring across functions:** LinkedIn Recruiter as the base, plus a specialist for whichever function is hardest.

**Enterprise with a compliance mandate:** SeekOut, and negotiate — 15–25% below list is normal for annual prepayment.

**No sourcing capacity at all:** a managed service like Fetcher will beat software nobody has time to operate.

Detailed head-to-head breakdowns are in our [comparisons](/compare), and [alternatives](/alternatives) covers the switching case for each tool.


---

### The Best Candidate Sourcing Software in 2026, Honestly Compared

HTML: https://www.realgreatdevs.com/blog/best-candidate-sourcing-software
Markdown: https://www.realgreatdevs.com/blog/best-candidate-sourcing-software.md

# The Best Candidate Sourcing Software in 2026, Honestly Compared

> A working comparison of the main candidate sourcing platforms in 2026, with sourced pricing, what each tool is genuinely good at, and which ones are wrong for a small team.

- Canonical: https://www.realgreatdevs.com/blog/best-candidate-sourcing-software
- Target query: candidate sourcing software
- Funnel: bottom
- Published: 2026-08-04
- Tags: sourcing tools, comparison, buying guide

Most "best sourcing software" lists are affiliate pages with the ranking sold to the highest bidder. This one names a specific buyer for each tool, states pricing with sources, and says plainly when a product is the wrong choice — including ours.

We build one of the tools listed here, so read accordingly. What we can offer in exchange is that every pricing figure below carries a source and a date, which is more than most lists manage.

## The short version

| Tool | Best for | Entry pricing |
| --- | --- | --- |
| LinkedIn Recruiter | Teams hiring across every function | Not published; negotiated per contract |
| SeekOut | Enterprise teams with a compliance mandate | $149/mo self-serve; team plans $10K–$30K per seat/yr |
| hireEZ | Sourcing plus outreach in one tool | From ~$169 per seat/mo, annual |
| Gem | Converting candidates you already have | Free under 30 employees; custom above |
| RealGreatDevs | Engineering-only sourcing from public code | Self-serve, free account to start |
| AmazingHiring | Technical recruiters wanting a specialist tool | Not published; annual contract |
| Fetcher | Teams with no sourcing capacity at all | Quote-based subscription |
| Wellfound | Startups hiring engineers who are already looking | Free tier available |

Detail and sources follow.

## What "sourcing software" actually means

The category is muddled, and buying the wrong sub-category is the most expensive mistake in this process. Three distinct things get sold under one label:

**Search tools** answer "who exists that I could hire?" You search an index of candidate profiles and get a list. SeekOut, hireEZ, AmazingHiring and RealGreatDevs are search tools.

**Engagement tools** answer "how do I convert the people I have already found?" Sequences, nurture, pipeline analytics. Gem is the clearest example.

**Marketplaces** answer "who is looking right now?" Candidates opt in. Wellfound is the example here.

If your problem is that nobody replies, a better search tool will not fix it. If your problem is that you cannot find anyone to email in the first place, a CRM will not fix that either. Diagnose which of the three you actually have before you look at a single pricing page.

## LinkedIn Recruiter

**Best for:** teams hiring across many functions who need one tool covering all of them.

The default, and defaults exist for reasons. Effectively every professional has a profile, InMail reaches people where they already are, and response norms are established. If you hire engineers, salespeople and finance staff from one seat, nothing else comes close on coverage.

The weakness for technical hiring specifically is that profiles are self-reported. Nothing verifies a claimed skill, and engineers are among the least active groups on the network — many maintain a minimal profile they last touched when they changed jobs. You are searching descriptions of work rather than work.

**Pricing:** LinkedIn does not publish Recruiter pricing. Reported figures put Recruiter Lite in the low thousands per seat per year and Recruiter Corporate substantially higher, negotiated per contract.

## SeekOut

**Best for:** enterprise talent teams with a compliance mandate and budget for a full talent intelligence stack.

SeekOut goes deeper than most on public-web enrichment, pulling in GitHub, patents and academic publications, which makes it genuinely useful for research and hardware roles that other tools handle poorly. Its diversity and compliance reporting is the most developed in the category, and talent rediscovery against your existing ATS regularly surfaces candidates you already paid to source.

The catch is the commitment. Annual contracts with no monthly option, and renewal escalation clauses are common unless capped at signing.

**Pricing:** a self-serve Recruit Lite tier at $149 per month billed annually. Team plans are custom with a minimum seat count; independent procurement data puts real contracts in the $10,000–$30,000 per seat per year band, averaging near $27,000. ([Vendr](https://www.vendr.com/marketplace/seekout), [SyncGTM review](https://syncgtm.com/blog/seekout-review-2026), checked August 2026.)

**Skip it if** you are a founder or a team of two. This is priced for a dedicated talent acquisition function.

## hireEZ

**Best for:** recruiting teams that want search and outreach sequencing in the same product.

hireEZ aggregates from 45-plus open-web sources and leans hard into outbound automation. It starts meaningfully cheaper than SeekOut and behaves more like normal SaaS at the low end, which makes it the usual first stop for teams that want SeekOut-like capability without the SeekOut bill.

The trade-off of broad aggregation is inconsistency: profile freshness varies with the underlying source, and engineering-specific signal is shallower than a code-first index.

**Pricing:** not fully published. Third-party data reports an entry tier around $169 per seat per month and a median contract near $13,000 a year. Credit overage fees can inflate the effective price. ([Glozo](https://www.glozo.com/blog/seekout-vs-hireez), checked August 2026.)

## Gem

**Best for:** teams whose bottleneck is conversion, not discovery.

Worth being precise about, because Gem appears on every sourcing list and is not primarily a sourcing tool. It is a recruiting CRM: sequences, nurture, and the best pipeline analytics in the category, including conversion by source. If candidates are entering your pipeline and dropping out, Gem is the right answer.

If you cannot find candidates in the first place, Gem does not solve that problem.

**Pricing:** custom, based on company size. Companies under 30 employees are offered All-in-One free for six months plus a discounted first paid year. Self-serve startup pricing is reported from around $130 per seat per month billed annually. ([Glozo](https://www.glozo.com/blog/seekout-vs-gem), checked August 2026.)

## RealGreatDevs

**Best for:** teams hiring engineers who want to judge candidates on shipped code.

Ours. It indexes 2.5 million engineers from public GitHub activity — repositories, languages, contribution history, location — and lets you filter on that activity directly rather than on a self-reported skill list. Self-serve, so you can evaluate it without a sales call or an annual commitment, and the aggregate data by [skill](/hire-developers) and [country](/hire-developers-in/united-states) is free to browse before you sign up.

**Skip it if** you hire outside engineering, since it covers nothing else, or if your candidates work exclusively in private repositories, since public code is the entire basis of the index. It is also not an ATS: it finds and contacts people, it does not manage them through a process.

## AmazingHiring

**Best for:** technical recruiters who want a specialist tool and can accept an annual contract.

Genuinely engineering-focused rather than a general tool with a technical filter bolted on. Aggregates from 50-plus sources including GitHub and Stack Overflow, merges multiple identities for the same person into one profile, and has a long-established presence in Eastern European and CIS markets.

**Pricing:** not published; sold per seat on an annual contract, which means a sales cycle before you can evaluate it.

## Fetcher

**Best for:** teams with no sourcing capacity who would rather buy the outcome than the tool.

A managed service: a human team curates batches of candidates and delivers them to you. Least hands-on option available, and human curation catches nuance automated filters miss.

The cost is control. You cannot search the index yourself, so exploring a market or iterating on requirements is slow, and throughput is bounded by the service rather than by your own effort.

**Pricing:** quote-based subscription, priced per batch of sourced candidates.

## Wellfound

**Best for:** startups hiring engineers who are already looking.

Formerly AngelList Talent. Candidates opt in, state salary expectations up front, and are actively open to work — so response rates are far higher than cold outbound and a whole negotiation round disappears.

The limitation is structural: it only reaches active candidates, which is a small fraction of the engineering market, and it skews heavily toward startup-inclined people.

**Pricing:** free tier for posting roles, with paid recruiting products above it.

## How to actually choose

**Diagnose the bottleneck first.** Cannot find anyone: search tool. People do not reply: the message is the problem, not the tool. People reply then vanish: CRM.

**Match the tool to the roles.** Hiring only engineers, use a specialist. Hiring across functions, a specialist becomes a second subscription rather than a replacement.

**Trial before committing.** Anything requiring an annual contract to evaluate deserves scepticism. The tools with self-serve entry — RealGreatDevs, Juicebox, hireEZ's lower tiers — let you test on a real open role first.

**Negotiate.** Independent data shows vendors in this category routinely closing 15–25% below list for annual prepayment or multi-year terms. A competing quote is the single most effective lever you have.

More detail on any specific pairing is in our [tool comparisons](/compare).


---

### What Makes a Great Developer? What 2.5M Public Profiles Show

HTML: https://www.realgreatdevs.com/blog/what-makes-a-great-developer
Markdown: https://www.realgreatdevs.com/blog/what-makes-a-great-developer.md

# What Makes a Great Developer? What 2.5M Public Profiles Show

> We analysed 2.5 million public developer profiles to test the usual assumptions about what separates strong engineers. Most of them do not survive contact with the data.

- Canonical: https://www.realgreatdevs.com/blog/what-makes-a-great-developer
- Target query: what makes a great developer
- Funnel: top
- Published: 2026-08-04
- Tags: data study, hiring, engineering

Ask ten engineering leaders what makes a great developer and you will get ten answers, most of them about attitude. Curiosity. Ownership. Communication. All plausible, all unfalsifiable, and none of them much use at four o'clock on a Tuesday when you are staring at a list of two hundred candidates.

So we went the other way. We took the aggregate activity data behind 2.5 million public developer profiles and asked a narrower question: which observable signals actually vary between developers, and which ones only look like they do?

This is not a claim to have measured greatness. Public code is a partial view — plenty of excellent engineers work almost entirely in private repositories, and the data says nothing about how someone behaves in a code review or handles a production incident. But it does let us test a few widely repeated beliefs against something other than intuition.

<Callout title="About the data">
Figures come from an index of public GitHub activity covering 2.5 million developer profiles, of which 1,115,277 have a resolvable country. Skill counts reflect developers with public repositories in a given language or technology. Data as of August 2026.
</Callout>

## The median developer is far less prolific than you think

Start with the baseline, because almost everyone gets it wrong.

Across the largest skill populations, the median developer has around **24 public repositories, 42 contributions in the last year, and 8 followers**. Not 300 commits a month. Not a starred side project. Twenty-four repositories, most of them dormant, and roughly one public contribution every nine days.

| Skill | Median contributions | Median repos | Median followers |
| --- | --- | --- | --- |
| JavaScript | 42 | 24 | 8 |
| Python | 44 | 22 | 8 |
| TypeScript | 69 | 27 | 9 |
| Java | 39 | 25 | 8 |
| C++ | 43 | 28 | 10 |
| Bash / Shell | 47 | 35 | 15 |

This matters more than it sounds. If your mental model of a strong candidate is someone with a busy contribution graph, you have set a bar that the median engineer in every major language fails to clear — including a large share of the people currently doing excellent work at companies you admire.

The practical version: **contribution volume is a terrible primary filter**. It is fine as a tiebreaker between two otherwise similar profiles. As a screen, it mostly selects for people who happen to work in the open, which correlates with employer policy and career stage far more than with skill.

## Where signals actually separate

The interesting result is not the medians. It is which numbers move when you change the population.

Contributions barely budge across languages — 39 to 47 across most of the table above. But two things do move.

**Followers move with language age and community.** C developers show a median of 12 followers and Bash developers 15, against 8 for JavaScript and Python. That is not a statement about ability. It reflects smaller, older, more tightly networked communities where the same people keep showing up. Reading follower count as a proxy for reputation works within a community and breaks completely across them.

**TypeScript is the outlier on contributions**, at 69 against a field of roughly 42. The likely explanation is selection rather than diligence: TypeScript adoption skews toward developers who deliberately chose it over JavaScript, and deliberate tooling choices correlate with the kind of engineer who is engaged enough with their craft to make them.

That is the pattern worth internalising. **The signal is rarely the number. It is the number relative to the population the person actually belongs to.** A developer with 60 contributions is unremarkable in TypeScript and well above median in Java. Comparing the raw figure across the two tells you nothing.

## Popular is not the same as employable

The largest skill populations in the index:

1. JavaScript — 1,336,934 developers
2. HTML — 1,202,938
3. Python — 1,153,995
4. TypeScript — 749,904
5. Java — 743,885
6. CSS — 684,048
7. C++ — 510,023

Then the tail drops sharply. Rust has 127,090. Kotlin has 123,406. Swift has 105,978.

The gap between JavaScript and Rust is roughly ten to one, and it inverts the difficulty of hiring. There is no shortage of JavaScript developers in absolute terms, which means a JavaScript search returns more results than you can act on and your real problem is ranking. A Rust search returns a pool small enough to read end to end, and your real problem is response rate.

These are different jobs requiring different tactics, and treating them the same is one of the more common ways a sourcing effort stalls. For a large pool, invest in filters. For a small one, invest in the message.

## Geography is more concentrated than the remote-work narrative suggests

Of developers with a resolvable location, the top ten countries:

| Country | Developers |
| --- | --- |
| United States | 251,534 |
| India | 128,786 |
| China | 82,597 |
| Brazil | 65,199 |
| Germany | 37,907 |
| Canada | 36,692 |
| Australia | 30,950 |
| United Kingdom | 28,442 |
| Mexico | 26,363 |
| South Korea | 21,360 |

The United States alone accounts for about 23% of located developers, and the top three countries together account for roughly 42%.

The more useful reading is further down. Colombia (19,878) sits ahead of France (17,865). Bangladesh (16,621) is close behind Japan (17,657). If you are hiring remotely and searching only the markets you already know, you are ignoring pools that are competitive on size and considerably less contested — most companies sourcing internationally are all fishing in the same four or five countries.

## So what does correlate with being good?

Honestly: nothing in this dataset, taken alone. That is the finding, and it is worth stating plainly rather than dressing up.

What the data supports is narrower and more useful:

**Recency beats volume.** Someone with 40 contributions spread across the last twelve months is telling you something different from someone with 400 concentrated in a single month two years ago. The first is a working engineer. The second is a bootcamp graduate or a burst of open-source enthusiasm that ended.

**Depth beats breadth.** A developer with four languages and sustained activity in two is a more legible profile than one listing fourteen. The second pattern usually means tutorial repositories, which inflate every count without indicating anything.

**Context beats the raw number, always.** Every figure above is only interpretable against its population — language, country, and career stage.

**And the things that most predict a good hire are not in this data at all.** How someone reasons about a problem they have not seen before. How they handle disagreement. Whether they can explain a technical decision to someone who does not share their assumptions. No amount of public activity substitutes for a conversation, and any tool claiming otherwise — including ours — is overselling.

What the data is genuinely good for is the step before that conversation: narrowing two million people to twenty worth talking to, based on evidence you can inspect instead of a self-reported skill list.

## How to use this when you are actually sourcing

1. **Set thresholds per population, not globally.** Look at the median for the specific skill and country you are searching, then filter relative to it.
2. **Filter on recency first.** Activity in the last twelve months eliminates more noise than any other single criterion.
3. **Read the repositories, not the graph.** Two minutes in someone's most substantial repository tells you more than any aggregate on this page.
4. **Widen the geography before you lower the bar.** If a search returns too few people, the constraint is usually the country list, not the requirements.

Every figure here is drawn from the same index you can search. The [skill pages](/hire-developers) break the numbers down by technology, and the [country pages](/hire-developers-in/united-states) do the same by location, both free to browse.


---

### How to Source Developers on GitHub: A Recruiter's Guide

HTML: https://www.realgreatdevs.com/guides/github-sourcing-guide
Markdown: https://www.realgreatdevs.com/guides/github-sourcing-guide.md

# How to Source Developers on GitHub: A Recruiter's Guide

> How to read a GitHub profile like an engineer would, which signals actually mean something, and the search techniques that surface people other recruiters miss.

- Canonical: https://www.realgreatdevs.com/guides/github-sourcing-guide
- Target query: how to source developers on github
- Funnel: middle
- Published: 2026-08-04
- Tags: sourcing, github, technical recruiting

GitHub is the closest thing to a portfolio that most engineers have, and it is badly misread by almost everyone sourcing from it. The green contribution squares are the most visible thing on a profile and among the least informative.

This guide covers what the signals actually mean, and how to search in a way that surfaces people other recruiters do not reach.

## Set your baseline first

The single biggest mistake is assuming a strong developer has a busy profile. Across the largest skill populations in our index, the median developer has around **24 public repositories, 42 contributions in the last year, and 8 followers**.

That is the middle of the market, not the bottom. If you are filtering for daily commits, you are excluding most working engineers — including a large share of the strongest ones, who write their best code in private repositories for their employer.

Medians also vary by population:

| Skill | Median contributions | Median repos | Median followers |
| --- | --- | --- | --- |
| JavaScript | 42 | 24 | 8 |
| Python | 44 | 22 | 8 |
| TypeScript | 69 | 27 | 9 |
| Java | 39 | 25 | 8 |
| C | 42 | 30 | 12 |
| Bash / Shell | 47 | 35 | 15 |

Sixty contributions is unremarkable for a TypeScript developer and well above median for a Java one. Always compare within the population, never across.

## What each signal actually means

**Contribution graph.** Shows consistency, not quality, and only for public work. Someone with a sparse graph may be committing daily to a private monorepo. **Read it for recency, not volume** — activity in the last six months tells you they are still actively coding, which is the genuinely useful part.

**Repository count.** Weak on its own. Many accounts are inflated by forks and tutorial projects. Filter to original repositories with actual commits before this number means anything.

**Followers.** A reputation signal *within a community*, not across them. C and Bash developers show medians of 12 and 15 against 8 for JavaScript, reflecting smaller and more tightly networked communities rather than greater ability. Comparing follower counts across languages is meaningless.

**Stars received.** Popularity of a project, which correlates with marketing as much as engineering. A widely-starred tutorial repository says less than an unstarred library with careful tests.

**Account age.** A reasonable proxy for experience. `created:<2018-01-01` is a rough filter for at least several years in the field, though plenty of senior engineers made accounts late.

**Language breakdown.** Derived from bytes of code, so a single large vendored file can skew it. Treat as a hint, then verify by opening a repository.

## Reading a profile in two minutes

A workable routine that catches most of what matters:

1. **Sort repositories by recently updated.** Ignore the pinned ones — those are curated, and you want the working reality.
2. **Open the most substantial recent repository** that is not a fork.
3. **Read the README.** Can they explain what the thing does and why? This is the closest free proxy for communication skill you will find.
4. **Look at the commit history.** Meaningful messages or 200 commits titled "update"? Steady work or one weekend?
5. **Open two or three source files.** You do not need to be an engineer for this. Is there structure? Are things named sensibly? Are there tests?
6. **Check issues and pull requests they have filed on other projects.** How someone behaves in another maintainer's repository is the single best free signal about how they will behave on your team.

Step 6 is the one almost nobody does, and it is the most predictive. Public disagreement in an issue thread reveals more about collaboration than any interview question.

## Search techniques that surface hidden people

Everyone runs `language:python location:london`. Here is what they do not.

**Search contributor lists of libraries you depend on.** Open the insights page of any dependency and read the contributor graph. These people already understand your problem domain and are almost never sourced.

**Search by dependency rather than language.** Finding repositories using a specific framework, then looking at who wrote them, identifies practitioners rather than people who once listed it.

**Use `created:` ranges to defeat the result cap.** GitHub caps user search at 1,000 results, so a broad query truncates silently. Splitting one search into several by account creation year gets you the whole market instead of an arbitrary slice.

**Run every spelling of a location.** `location:` is free text. "NYC", "New York", "New York City" and "Brooklyn" are four separate searches, and skipping three of them is how you miss most of a city.

**Read the followers of engineers you already rate.** People follow others working on similar things. One excellent candidate's follower list is a curated pool of similar people.

**Look at who starred a niche repository.** Anyone who starred a specialist library has at minimum evaluated it.

## Where GitHub search runs out

Worth knowing the ceiling before you invest a week in it:

- **The 1,000-result cap** truncates without telling you.
- **No recency filter.** You cannot express "contributed in the last six months", which is the most useful filter in sourcing.
- **No cross-source dedupe.** The same person under multiple identities looks like several people.
- **Location is unstructured and often empty.**
- **No contact information in results.** You look each one up manually, at a few minutes each.

Our [free sourcing guide](/guides/how-to-source-developers-for-free) covers workarounds. Past two or three concurrent roles the manual approach stops being the cheaper option, and [our index](/hire-developers) covers the same public data with the activity and location filters GitHub search cannot express.

## Contacting people you find on GitHub

Engineers are contacted constantly and have short patience for generic outreach. What works:

**Name the specific repository and say what you noticed.** The whole point of sourcing from GitHub is that you can see the work. Demonstrating you looked is the entire advantage — waste it and you are just another recruiter.

**Do not compliment code you have not read.** Engineers detect this instantly and it is worse than saying nothing.

**Keep it short and include the salary range.** Under 150 words, with a number.

**Use their listed email, or the one in commit metadata.** Both are public. Never add either to a bulk sequence.

**Accept a no gracefully and ask for a referral.** Engineers who are not looking frequently know someone who is, and referrals from respected engineers convert better than anything you will source cold.

To size a market before you start, the [skill pages](/hire-developers) show developer counts by technology and the [country pages](/hire-developers-in/united-states) break them down by location, both free to browse.


---

### Do You Need a Headhunter to Hire Developers? An Honest Answer

HTML: https://www.realgreatdevs.com/guides/hire-developers-without-a-recruiter
Markdown: https://www.realgreatdevs.com/guides/hire-developers-without-a-recruiter.md

# Do You Need a Headhunter to Hire Developers? An Honest Answer

> When a headhunter or agency is worth 20% of first-year salary, when it is not, and how to run the same process yourself if you decide against it.

- Canonical: https://www.realgreatdevs.com/guides/hire-developers-without-a-recruiter
- Target query: find a headhunter app
- Funnel: middle
- Published: 2026-08-04
- Tags: hiring, recruiting, agencies

Agency recruiters typically charge 15% to 25% of first-year salary. On a $150,000 engineering role that is $22,500 to $37,500 for one hire. Whether that is expensive depends entirely on what it replaces, and the answer is genuinely not always "do it yourself".

This guide covers when an agency earns the fee, when it does not, and what running the process yourself actually involves.

## When a headhunter is worth it

**You are hiring one senior person and have no time.** Founders hiring a first engineering lead while also running the company are the clearest case. The fee buys back weeks you do not have, on a role where a bad hire is catastrophic.

**The role is genuinely rare.** Specific compiler, embedded, or niche domain expertise where the qualified pool is in the hundreds globally. A good specialist recruiter already knows those people personally, and that network is not something you can build in a quarter.

**You need discretion.** Replacing someone who is still in the seat, or hiring against a confidential product line. You cannot run that search yourself without it becoming visible.

**You are hiring in an unfamiliar market.** Opening in a country you have never hired in, where you do not know the salary norms, notice periods or which companies are shedding people. Local knowledge is worth paying for.

## When it is not

**You are hiring several engineers into similar roles.** Three backend hires at $150,000 each is $67,500 to $112,500 in fees. That is more than a year of a full-time internal recruiter, who will also build a pipeline you keep.

**The role is well-supplied.** For common stacks the pool is large and the constraint is filtering, not finding. A JavaScript search returns more qualified people than you can process; you are paying an agency to do work a tool does faster.

**You want to build hiring capability.** Every agency hire teaches you nothing about your own market. Six months in you are exactly as dependent as when you started.

**Your budget is tight and your time is not.** If you have hours available and $30,000 you do not, the arithmetic is straightforward.

## What agencies actually do for the fee

Worth understanding, because it clarifies what you are replicating:

1. **Search** their existing database plus LinkedIn and public sources.
2. **Screen** by phone against your requirements.
3. **Sell** the role, which is the part most companies underrate. A good recruiter changes minds about opportunities candidates would otherwise dismiss.
4. **Coordinate** scheduling, feedback and the process generally.
5. **Negotiate** the offer, and handle the counter-offer conversation.

Steps 3 and 5 are where the value concentrates. Search is the commoditised part, and it is the part software has largely absorbed.

## Running it yourself: what it takes

**Time.** Realistically 15 to 25 hours per role: sourcing, writing outreach, screening calls, coordination. Concentrated in the first two weeks.

**A written role definition.** Not a job description — an honest list of what the person will do in their first six months and what they must already know. Most failed searches trace back to never having done this.

**A salary range you will actually publish.** Refusing to state one costs you replies and wastes everyone's time on candidates you cannot afford.

**A process you have agreed in advance.** How many interviews, who runs them, what each is testing, and how fast you commit to moving. Deciding this while candidates are in flight is how you lose them.

**A sourcing method.** Either free searching, covered in our [free sourcing guide](/guides/how-to-source-developers-for-free), or a self-serve tool. For engineering roles the [skill pages](/hire-developers) show what the pool looks like by technology and country before you commit.

## The realistic hybrid

Most teams that get this right do not choose one or the other.

**Source yourself, hire an agency for the hard roles.** Run your own process for common positions where the pool is large, and pay for the one genuinely rare search a year.

**Negotiate the fee.** Agency fees are more negotiable than advertised, particularly for multiple roles or exclusivity. 15% for a committed set of three hires is a very different number from 25% for one speculative search.

**Ask for a contingency structure you can live with.** Contingent search costs nothing up front but gets deprioritised against retained work. Retained gets attention but you pay regardless of outcome. For a role you must fill, retained usually wins; for a nice-to-have, contingent.

**Keep the candidates.** Whatever you pay for, ensure you retain the pipeline. The people who were interesting but not right this time are the cheapest source of your next hire, and that asset should not live in an agency's database.

## A rough decision rule

Multiply your fully-loaded hourly cost by 20 hours. If that number is comfortably below the agency fee, and you have the 20 hours available in the next fortnight, run it yourself.

If you do not have the hours, or the role is rare enough that you would not know where to start, the fee is buying something real.

For engineering roles specifically, the search half of the work has got considerably cheaper. [Browse the market by skill and country](/hire-developers) for free before deciding — knowing whether your pool is 500 people or 50,000 changes the answer.


---

### How to Source Developers for Free (Without Paid Tools)

HTML: https://www.realgreatdevs.com/guides/how-to-source-developers-for-free
Markdown: https://www.realgreatdevs.com/guides/how-to-source-developers-for-free.md

# How to Source Developers for Free (Without Paid Tools)

> The search syntax, free tools and workflows that let you source engineers without paying for sourcing software, plus honest limits on how far free gets you.

- Canonical: https://www.realgreatdevs.com/guides/how-to-source-developers-for-free
- Target query: how to source candidates for free
- Funnel: middle
- Published: 2026-08-04
- Tags: sourcing, github, boolean search

You can source engineers without paying for anything. It takes longer, it does not scale past a handful of roles, and it is genuinely effective — plenty of good hires come from an afternoon of GitHub search and a well-written email.

This guide covers the syntax that works, the free tools worth knowing, and where free stops being the cheaper option.

## GitHub search: the core syntax

GitHub's search covers users directly. The operators that matter:

```
language:rust location:portugal followers:>50
```

That is the basic shape. Useful modifiers:

| Operator | Example | What it does |
| --- | --- | --- |
| `language:` | `language:go` | Developers whose repositories are primarily in that language |
| `location:` | `location:berlin` | Matches the free-text location field |
| `followers:` | `followers:>100` | Follower count above a threshold |
| `repos:` | `repos:>20` | Public repository count |
| `created:` | `created:<2018-01-01` | Account age, a rough proxy for experience |
| `type:user` | `type:user` | Excludes organisations from results |

Combined into something realistic:

```
language:typescript location:spain repos:>15 created:<2020-01-01 type:user
```

Two things to know before you rely on this. **`location:` is free text**, so "Berlin", "Berlin, Germany" and "🇩🇪 Berlin" are three different searches and you need to run all of them. And **GitHub caps user search results at 1,000**, so a broad query silently truncates. Narrow with `created:` ranges and run several passes rather than one wide query.

## Google X-ray search

X-ray searching means using Google to search a site more flexibly than the site's own search allows.

```
site:github.com "rust" "berlin" -inurl:repositories
```

For personal sites and portfolios, which surface engineers who never appear in recruiting tools:

```
site:*.dev "senior engineer" "golang" -site:jobs.*
```

For conference speakers, a consistently underused pool:

```
"speaker" "kubernetes" 2025 conference -site:linkedin.com
```

The advantage over GitHub's own search is that Google indexes README files, personal sites and bios, so you can search for context that GitHub's structured filters do not expose.

## Free sources beyond GitHub

**Stack Overflow.** The developer story feature is gone, but user profiles still show tags, reputation and location. High reputation in a narrow tag is a strong specialist signal.

**Conference talk archives.** Speaker lists from the last few years of any conference in your stack are a curated list of people who both know the subject and can explain it. Almost nobody sources from them.

**Open-source contributor lists.** Pick a library your team depends on and read its contributor graph. These people already understand your problem domain.

**Community Slack and Discord groups.** Language and framework communities usually have one. Participating for a few weeks before posting anything is the price of entry, and it is worth it.

**Our public skill pages.** [Aggregate developer counts by skill](/hire-developers) and [by country](/hire-developers-in/united-states) are free to browse without an account. Useful for sizing a market before you commit to a search strategy.

## Finding contact details

Having a shortlist is not having an inbox. In order of reliability:

1. **The GitHub profile itself.** Many developers list an email or personal site directly.
2. **Commit metadata.** `git log` on any repository they have contributed to exposes the author email on every commit — public information, and usually the address they actually read.
3. **Personal site.** Check `/about` and `/contact`.
4. **Their other profiles.** Many link Twitter, Mastodon or a blog from their GitHub bio.

<Callout title="On commit emails">
Commit emails are public, but people rarely expect to be contacted at them. Use the address, keep the message short and relevant, and never add it to a bulk sequence. This is the fastest way to get a reputation as someone worth ignoring.
</Callout>

## Writing an email that gets a reply

Free sourcing succeeds or fails here. The pool is the same one paid tools search; the difference is entirely your message.

**Reference something specific.** Name the repository. Say what you noticed. Anything that could have been sent to a thousand people will be treated as if it was.

**Keep it under 150 words.** Every additional paragraph reduces the reply rate.

**State the money.** Engineers overwhelmingly report discarding messages without a range. Omitting it does not preserve negotiating room, it just costs you replies.

**Give an easy no.** "Not looking, but happy to point you at someone" converts far better than a hard ask, and referrals from uninterested engineers are one of the best channels there is.

A workable template:

```
Subject: Your work on [repo]

Hi [name] — I came across [repo] while looking at [specific thing].
[One sentence on what you actually noticed.]

We're building [one line] at [company], and looking for someone
to own [area]. It's [salary range], [location or remote policy].

Worth a conversation? Equally happy to hear it's a no, or to be
pointed at someone you rate.

[Your name]
```

## Where free stops being cheaper

Free sourcing costs time instead of money, and past a certain volume the trade goes the wrong way.

**The 1,000-result cap** means broad searches truncate silently. You cannot tell whether you saw the market or a fifth of it.

**No dedupe.** The same person appears under different identities across sources and you will contact them twice.

**No activity filtering.** GitHub search cannot express "contributed in the last six months", which is the single most useful filter in sourcing.

**Location is unreliable.** Free text means "SF", "San Francisco" and "Bay Area" all need separate searches, and many people leave it blank entirely.

**Manual contact lookup** runs a few minutes per candidate. At fifty candidates that is most of a working day.

The rough breakpoint: **free works well for one or two roles at a time.** Past three concurrent roles, or a second hiring round in the same market, the hours spent exceed what a self-serve tool costs.

## A realistic workflow

1. Size the market first on the [free skill and country pages](/hire-developers) so you know whether you are searching a pool of 500 or 50,000.
2. Run four or five GitHub searches with different location spellings and `created:` ranges.
3. Save every plausible profile to a spreadsheet with the repository that caught your attention.
4. Spend two minutes per profile reading their most substantial repository. Cut aggressively.
5. Find contact details for the survivors.
6. Write individually to each. Twenty personal emails beat two hundred generic ones.
7. Follow up once after a week. Once, not three times.

Expect a reply rate somewhere between 15% and 40% if the messages are genuinely specific — considerably better than most automated sequencing achieves, because almost nobody does this properly.

When manual searching stops scaling, [our index](/hire-developers) covers the same public data with the activity filters GitHub search cannot express, and you can start on a free account.


---