# Sourcing a Developer Advocate From Public Teaching Signals

*You will turn a DevRel req into a ranked shortlist of 8 to 12 real candidates by scoring teaching signals, without depending on the "developer advocate" title.*

- Canonical URL: https://www.refolk.ai/guides/sourcing-developer-advocate-teaching-signals
- Pillar: Engineering and open source
- Format: Playbook
- Published: 2026-09-03
- Last reviewed: 2026-09-03
- Reading time: 15 min

You have an open developer-advocate or DevRel req, and the usual sourcing move fails on contact: search the title, get almost nothing. This guide is for engineering managers, technical founders, developer-relations leads, and technical sourcers who need to turn that req into a ranked shortlist of real people. It reads teaching signals - talks, tutorials, docs, code samples, and community answers - as evidence of advocacy ability, then scores and ranks them, so you can build a shortlist without the title ever appearing.

Most library sourcing methods read code, commits, and design writing to prove engineering ability. Advocacy is a different corpus. A person can ship excellent code and be a poor teacher; a person can teach thousands and write mediocre code. This procedure scores the teaching corpus directly, and it treats the absence of a title as the default, not the exception.

## Why title-based search cannot fill this req

Title-based search returns almost nothing because the pool is genuinely tiny, not because candidates do not exist. In Refolk's index of professional profiles, US software-engineer profiles outnumber US developer-advocate profiles by roughly 1,000 to 1. You are not looking for a rare title; you are looking for a common skill that few people have labeled.

Practitioners describe DevRel as one of the toughest hires in early-stage developer-centric startups: advocates are hard to come by, and the field has barely existed long enough to build a deep bench. That means the empty pipeline you see when you search "developer advocate" is a measurement artifact. The people are there. They are filed under "software engineer," "solutions engineer," "technical support," and "maintainer," and they teach in public under those labels.

**1,011x - US software engineers per US developer advocate in Refolk's index**

347,893 engineer profiles against 344 advocate profiles, so title search cannot fill the req.

The scarcity is structural, not cyclical. It will not improve with a better boolean string. The only reliable fix is to change the corpus you search: read artifacts, not titles.

| Title group | Profiles in index | Ratio to advocates |
|---|---|---|
| Software Engineer | 347,893 | 1,011x |
| Developer Advocate / DevRel Engineer | 344 | 1x |

Geography narrows the slice further. The US advocate pool is 5.6 times the UK pool in Refolk's index, and both are dominated by a single employer: in the US slice, Google is the single most common current employer, and in the UK slice Google holds 10 of roughly 25 sampled profiles. If your req is outside the US, or outside big tech, you are competing for an even thinner named pool and should widen aggressively to untitled engineers.

| Country | Advocate profiles | Share of US |
|---|---|---|
| United States | 344 | 100% |
| United Kingdom | 61 | 17.7% |

> **Rule:** Source on artifacts, not titles
>
> An empty title-based pipeline is not evidence that no candidates exist. With a genuine ratio near one advocate per thousand engineers, you must build seed lists from talks, packages, tutorials, and answers, then work backward to the person.

## Which public surfaces prove which part of advocacy

Advocacy leaves tracks on a handful of public surfaces, and each surface proves one thing while staying silent on another. The discipline is to read every candidate across at least three surfaces so no single signal carries the verdict alone.

Conference and CFP speaker directories prove stage capability and topic focus. Sessionize runs a public speaker directory listing 84,000-plus searchable speakers with full talk history, expertise areas, and awards. A speaker profile tells you the person can hold a room and knows their topic; it tells you nothing about code depth.

Content platforms prove explanatory writing. Advocates' writing lives where developers live: on personal technical blogs, on dev.to and DZone, on Hacker News. A strong body of tutorials proves the person can explain; it does not prove live presence or community depth.

Package registries and GitHub prove technical credibility and maintainer discipline. Authoring a package with a real community around it, and answering issues in its discussions, is a strong signal. It proves the person can build and sustain something real; it does not prove they can teach it.

Stack Overflow and Discourse answers prove helpfulness and topical authority, with a caveat that gets its own treatment below. Video and podcast guest lists prove delivery and reach.

| Surface | What it proves | What it does not prove |
|---|---|---|
| CFP / speaker directory | Stage capability, topic focus | Code depth |
| Blog / dev.to / DZone | Explanatory writing | Live presence, community depth |
| Package registry / GitHub | Technical credibility, maintainer discipline | Teaching ability |
| Stack Overflow / Discourse | Helpfulness, topical authority | Depth, if reputation is farmed |

#### The teaching-signal corpus, outermost first

1. **Reach signals** - Podcast guest slots, talk view counts, follower counts
2. **Delivery signals** - Recorded talks, live workshops, video tutorials
3. **Teaching signals** - Written tutorials, quickstarts, troubleshooting guides
4. **Credibility signals** - Maintained packages, resolved issues, debugging in public

*Read a candidate from the widest public surface inward to the hardest-to-fake evidence.*

The most-cited single predictor across practitioner interview loops is the ability to build something real and explain it clearly: technical credibility plus communication, together. A candidate strong on only one of those is a specialist, not an advocate, and you should file them accordingly.

## The three scoring axes and how to weight them

Score every candidate on three axes: technical credibility, content quality, and community delivery. These map directly to the exercises practitioner interview loops already use, so your sourcing scores predict how the candidate will perform on-site.

Technical credibility is a debugging exercise on a broken integration, evaluated on reproduction, isolation, explanation, and the final fix. In sourcing, you approximate it by reading one repo or package and one Q&A thread: can this person debug and explain, or only one of the two?

Content quality is a short quickstart or troubleshooting guide with a runnable snippet, evaluated for clarity, correctness, structure, and safe patterns. In sourcing, you open one tutorial and actually run a snippet.

Community and delivery is a mini talk, evaluated on presence, pacing, Q&A handling, and accuracy. In sourcing, you watch five minutes of a talk or read one thread the candidate resolved.

The weighting depends on the archetype your req needs. Content-focused DevRel overlaps significantly with traditional marketing; community-focused DevRel does not. Decide this before you score anyone, because the same candidate ranks first for one archetype and last for the other.

#### Placing a candidate against the role archetype

Horizontal axis runs from Thin technical evidence to Deep technical evidence. Vertical axis runs from Thin teaching evidence to Deep teaching evidence.

| Quadrant | What it means |
| --- | --- |
| Aspirant | No artifacts to score, route to an engineering track |
| Maintainer | Strong build signal, coach on teaching before a content req |
| Explainer | Strong content signal, verify code depth with a debugging check |
| Advocate | Builds and explains, advance to the interview loop |

*Match the candidate's dominant artifact type to the archetype the scorecard weights, or expect an unhappy hire.*

> A person can ship excellent code and teach badly, or teach thousands and code poorly. Advocacy is both, together.

Developer advocacy is the most featured DevRel function at 82.2%, ahead of community management at 52.7% and technical writing at 42.7%, so most reqs will weight technical credibility and content heavily. But a community-focused req inverts that, and the matrix above keeps you honest about which quadrant you are actually hiring for.

## The sourcing procedure, start to finish

Run these eight steps in order. The first three build and shape the pool; the middle three score it; the last two rank and price it. Budget one to two days of sourcer time to build the pool and roughly 30 minutes of reviewer time per candidate to score it.

#### From open req to priced shortlist

1. **Define the role need** - Decide content-focused versus community-focused, then write a one-page scorecard weighting technical credibility, content, and community delivery. Budget two to four hours of EM or DevRel-lead time.
2. **Build seed lists from artifacts** - Pull past speakers from CFP directories, package authors from registries, gold-tag answerers from Stack Overflow, dev.to authors, and podcast guest lists. Aim for 50 to 150 names, each with at least one public artifact URL.
3. **De-title and expand the pool** - Deliberately include engineers with blogs and maintainers who never carried the advocate title, tagged separately from title-holders. Advocates come from many backgrounds and you miss them if you look for one profile.
4. **Score technical credibility** - Read one repo or package and one Q&A thread per candidate. Mark pass or fail on whether they can reproduce, isolate, and explain a fix. Budget 10 to 15 minutes each.
5. **Score content quality** - Open one tutorial and actually run a snippet, penalizing copy-paste breakage. Rate 1 to 5 on clarity, correctness, structure, and safe patterns. Budget 10 minutes each.
6. **Score community and delivery** - Watch five minutes of a talk or read one thread the candidate resolved. Rate 1 to 5 on presence, pacing, and genuine helpfulness. Budget 10 minutes each.
7. **Rank and calibrate to level** - Combine the weighted scores and map each candidate to a seniority band using years plus portfolio. Produce a ranked shortlist of 8 to 12 with a comp band per candidate.
8. **Sanity-check pool size and comp** - Confirm each band matches at least two market sources before outreach. Produce a go or no-go decision per candidate.

The de-title step in the middle is where most sourcing methods quietly fail. Candidates can come from any number of backgrounds - solutions engineering, technical support, developer experience, or a maintainer's side project - and you will miss them if you screen for a single profile. Current engineers with a blog or a community package are a prime pool if you are willing to do the work to pitch them.

Building the seed list is the slow part, because it means running the same intent across GitHub, speaker directories, and Q&A sites and then reconciling the people. This is exactly the friction [Refolk](/) removes: you describe the artifact pattern in plain English and get back the people who match across surfaces, already resolved to a profile.

I ran this search: `Stack Overflow users with a gold tag badge in Kubernetes who publish tutorials on dev.to` - [see the full result list](https://www.refolk.ai/s/747ggvs7wt).

*Returns people who have proven both domain authority and teaching output on two independent public surfaces, which is the exact intersection this method scores.*

## How this goes wrong: failure modes and false positives

Every axis in this method has a way to lie, and the lies are consistent enough to name. Treat this section as the checklist you run against your own shortlist before you send a single message.

**Title-based search returns almost nothing.** The false positive is reading an empty pipeline as "no candidates exist." The pool is genuinely near one advocate per thousand engineers, so the fix is not a better title query - it is sourcing on artifacts.

**Reputation inflation on Stack Overflow.** A high reputation score can come from answering low-expertise-density tags during off-peak hours, or from asking high-quality questions rather than answering hard ones. Raw reputation is an imperfect proxy. Require a gold tag badge in the role's actual domain instead: a gold tag needs 200 answers and a total score of 1,000 under that specific tag, which is far harder to farm. A mid-reputation gold-tag holder in your exact domain beats a high-reputation generalist.

> **Watch out:** Rank by tag, not by total reputation
>
> Reputation gamification inverts the signal. A study of 93,053 high-reputation users found reputation is not always a reliable indicator of expertise. Filter to a domain gold tag before you trust any Stack Overflow number.

**Broken tutorials.** A polished blog whose code fails on copy-paste is a false credibility signal, because advocates lose credibility instantly when a snippet throws an error. Actually run one snippet before you score content. This is the cheapest high-signal filter in the whole method.

**The aspirant with no artifacts.** Be wary of a developer who says they are ready to transition to advocate but has not taken the time to publish or build community. No public artifact means unproven. Route them to an engineering track rather than the advocate loop.

**Content volume mistaken for advocacy.** Measuring posts-per-month optimizes visible output over relationship depth. Great DevRel includes coffee chats and DMs that never show up in metrics, so artifact-only sourcing systematically under-ranks the strongest community candidates. Deliberately score one resolved community thread, not just a publication count.

**Marketer-who-codes versus engineer-who-communicates.** If a candidate cannot answer technical questions or debug code, they lose credibility fast. DevRel requires engineers who communicate, not marketers with talking points. The debugging check exists to catch this; do not skip it for a candidate with a strong content portfolio.

**Wrong archetype for the need.** Hiring a community person into a content role, or the reverse, produces an unhappy hire. Match each candidate's dominant artifact type to the scorecard you wrote in step one.

**Comp miscalibration.** Public figures range from about $76K to over $200K for the same title. Anchoring to a single source misprices the offer. Triangulate at least two sources for the level before you name a number.

## Calibrating level and compensation before outreach

Map each shortlisted candidate to a seniority band using years of experience plus the strength of their portfolio, then attach a comp band drawn from at least two public sources. The band is part of the shortlist, not an afterthought, because a strong candidate priced wrong falls off before the loop.

A conservative default expects roughly three to six years in software engineering, solutions engineering, developer experience, technical support, or a DevRel-adjacent role. Entry roles want two to four years plus demonstrated communication; mid-level wants four to eight; senior and head roles want eight-plus and team management, often across teams of five to twenty. A concrete public reference point: one large public job description requires at least one year of experience giving talks and developing demos, workshops, webinars, and videos, and managing CFP deadlines - a useful floor for the delivery axis.

Compensation data disagrees loudly, and the disagreement is itself the finding: the spread reflects wide variation by company size, location, and DevRel maturity. Triangulate rather than trust one figure.

| Level / source | Figure |
|---|---|
| Developer Advocate avg (Glassdoor) | $136,233 |
| Senior Developer Advocate avg (Glassdoor) | $171,057 |
| Median base (DevRel survey) | $175,000 |
| Median total comp (DevRel survey) | $200,121 |

The senior-versus-average premium on Glassdoor is about 26%, and San Francisco runs roughly 34% above the national average, so location and level move the number more than any single benchmark suggests. Two-to-five-person DevRel teams are the most common size at 35.2%, which means most reqs sit inside small teams where the first advocate sets the bar and the comp band signals how seriously you take the function.

**One-line candidate record for the shortlist**

```
Name | Dominant artifact | Tech (P/F) | Content (1-5) | Community (1-5) | Years | Band | Go/No-go
Example: Untitled maintainer of a popular npm package | PASS | 4 | 3 | 5 | Mid ($150-175K) | GO
```

*Fill one per candidate; the three scores and the band are what the hiring manager reviews.*

#### From seed list to priced shortlist

| Stage | Figure | Note |
| --- | --- | --- |
| Seed list from artifacts | 100 | 50 to 150 names, each with one artifact URL |
| Passed technical credibility | 45 | Can debug and explain |
| Passed content quality | 25 | Runnable snippet, clear structure |
| Ranked and priced shortlist | 10 | 8 to 12 with a comp band each |

*A 50-to-150 name seed list narrows to roughly 8 to 12 ranked, priced candidates.*

## What to verify before you send outreach

Before you call the shortlist done, run this check. It catches the failure modes above in the order they bite, and it is the difference between a list of names and a defensible slate.

#### Shortlist readiness check

- [ ] The scorecard names one archetype (content or community) and weights the three axes accordingly.
- [ ] The seed list was built from artifacts, and non-title candidates are tagged and included, not filtered out.
- [ ] Every Stack Overflow signal is a domain gold tag, not raw reputation.
- [ ] At least one code snippet per content-scored candidate was actually run, and breakage was penalized.
- [ ] Each candidate has at least one resolved community thread scored, not just a publication count.
- [ ] No candidate on the list has zero public artifacts; aspirants are routed to an engineering track.
- [ ] Each candidate's dominant artifact type matches the role archetype.
- [ ] Every comp band is triangulated from at least two public sources for that level.

## Keeping the pipeline current

Rebuild the seed list on a cadence rather than treating it as a one-time pull, because the artifact surfaces refresh constantly and the named pool is too thin to let a good candidate go cold. New CFP archives publish after every conference season, package communities grow new maintainers, and dev.to authors ship new tutorials weekly.

Re-run your artifact queries against the same surfaces each quarter and diff the results against your existing pool. Watch for the candidate who just published their first strong tutorial or landed their first conference talk - the aspirant-with-no-artifacts from last quarter may now have exactly the evidence you need, and moving early on a newly-visible advocate beats competing for the same handful of titled profiles everyone else can see. Because most of this pool sits under other titles, the reach signals that surface them change faster than any title ever will, so the query is the durable asset, not the list it returned last time.

## Frequently asked questions

### How do I source developer advocates when almost none carry the title?

Search on artifacts, not titles. Pull past speakers from CFP directories, package authors from npm, PyPI, or crates registries, gold-tag answerers from Stack Overflow, dev.to authors, and podcast guest lists. In Refolk's index there are roughly 1,011 US software engineers for every advocate, so a title search returns almost nothing while artifact-based search surfaces engineers who teach in public but never took the label.

### Is Stack Overflow reputation a reliable signal for DevRel candidates?

No, not raw reputation. Reputation can be farmed by answering low-expertise-density tags during off-peak hours, so a high generalist score does not prove domain depth. Require a gold tag badge in the role's actual domain instead: a gold tag needs 200 answers and a total score of 1,000 under that tag, which is far harder to game than a reputation number.

### What is the fastest high-signal filter for a developer advocate portfolio?

Run one code snippet from one of their tutorials. Advocates lose credibility instantly when a snippet throws an error on copy-paste, so a ten-minute run separates substantive teaching from surface content faster than any resume read. If the quickstart works cleanly and reads clearly, that is a strong content signal in a single check.

### Should I hire an external developer advocate or convert an internal engineer?

Sources disagree, and both are valid. Several practitioners lean toward converting internal engineers who already have a blog or a package with a community, since current engineers are a prime pool if you are willing to pitch them. Be wary of anyone who claims they are ready to transition but has published nothing and built no community: no public artifact means unproven, and they belong on an engineering track.

### What should I budget for a developer advocate salary?

Triangulate at least two sources per level. Glassdoor puts the average developer advocate at $136,233 and senior at $171,057, while the DevRel survey reports a $175,000 median base and $200,121 median total comp. Public figures for the same title range from about $76K to over $200K, so anchoring to one source will misprice the offer.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/sourcing-developer-advocate-teaching-signals*