devrel-hiring

{
  "skill_name": "devrel-hiring",
  "evals": [
    {
      "id": 1,
      "prompt": "I'm Priya, cofounder at Lattice Fold. We're pre-seed, 7 people, raised $1.4M, building a build-cache service for WASM toolchains. I spent six years at a big cloud vendor and I still have the Developer Advocate II job description we used there - it was anchored to our L4 engineering level, asked for sustained conference output in one lane (the candidate had to show two years of consistent talk history on a single technology), and offered $185k base plus stock plus a $20k annual travel budget. Can you adapt that doc for our first DevRel hire? We can pay about $110k plus 0.6% equity and we have maybe $4k for travel for the whole year. Sales are founder-led right now and what we really need is for developers to find us and get to a working build without talking to us.",
      "expected_output": "A scorecard and posting rebuilt from the early-startup company-type row rather than an edit of the big-tech description: generalist-across-four-pillars framing, a named funding driver in the mission line, quantified ranked outcomes sized to a $4k travel budget, weighted competencies, and a founder round added to the loop.",
      "files": [],
      "expectations": [
        "Rejects adapting the big-tech job description text and rebuilds the scorecard from the early-startup company-type row instead",
        "States the role is a generalist across all four pillars (advocacy, marketing, enablement, community) and self-directed, rather than deep in one lane",
        "Notes that levelling anchored to a big-tech engineering ladder does not transfer, and that 'senior' at this stage means founding generalist",
        "Sets the portfolio bar as breadth plus at least one end-to-end outcome the candidate owned alone, not sustained high-volume output in a single lane",
        "Names a funding driver explicitly in the mission line (for example developer adoption or developer enablement) rather than a generic 'grow the community' purpose",
        "Flags the $4k annual travel budget as incompatible with any conference-heavy outcome carried over from the big-tech description",
        "Produces between 3 and 8 outcomes, each quantified with a number and a time window, and ranked by importance",
        "Produces between 5 and 7 competencies, weighted for this company type and sub-role",
        "Adds a founder or exec round to the interview loop because this is an early-startup hire",
        "States the coding-depth bar at this stage is high because the same person builds the demos and the docs"
      ]
    },
    {
      "id": 2,
      "prompt": "Can you tighten up this job ad before I post it? Company is Helix Relay, we do event-stream tooling.\n\n'Developer Advocate (Associate) - $72,000\nRequirements: 5+ years shipping production systems in Go, Rust, TypeScript and Python. Demonstrated open-source contributions to a CNCF project. A published technical writing portfolio. Experience organising a conference track or meetup series. 10k+ combined social following across X, LinkedIn and YouTube. You'll write blog posts, speak at events, run our Discord, answer support questions and help sales on technical calls.'\n\nMostly I want the wording to sound warmer and less corporate.",
      "expected_output": "A refusal to merely reword: the posting is identified as the gatekeeper pattern, audited against the five-item self-audit checklist, and returned as requiring a structural rewrite with the requirement list cut to the actual pillar mix or the level re-priced.",
      "files": [],
      "expectations": [
        "Identifies the posting as the 'gatekeeper' failure pattern by name rather than treating it as a tone problem",
        "Attributes the gatekeeper/pit-trap taxonomy to Joe Nash and DevRelCon 2021",
        "Names the levelling inconsistency directly: an 'Associate' title at $72,000 against requirements implying a full senior engineering career",
        "Flags the '10k+ combined social following' requirement as off-core-skills emphasis rather than a fundamental of communicating with developers",
        "Flags the four-language production-engineering requirement as describing an impossible person rather than the role's actual pillar mix",
        "States the posting needs a rewrite before publishing, not after it fails to convert candidates",
        "Runs a tactics-versus-outcomes check and notes the activity list (write, speak, run Discord, answer support, help sales) traces to no stated outcome",
        "Cuts the requirement list down to what the role's pillar mix actually needs, instead of softening the wording of each bullet",
        "Recommends re-pricing the level against the real requirement, or cutting the requirement to match the stated pay",
        "Makes no assertion about what any jurisdiction's pay-transparency law currently requires without asking the user to confirm the hiring location's rule"
      ]
    },
    {
      "id": 3,
      "prompt": "Series A, 40 people, remote-first with an office in Denver. Here's the posting I drafted for our first ever DevRel person - does this read well?\n\n'Founding Developer Advocate. No formal DevRel background required - we'll figure this out together! You'll own our documentation, write and maintain our SDK samples, run the community Discord, take a shift on the support rota, join technical sales calls when needed, and build internal enablement training for our AEs. You'll wear a lot of hats and have enormous impact. Competitive salary and equity.'\n\nI'm pretty happy with the energy of it, just want a second opinion.",
      "expected_output": "The posting is named as the pit-trap pattern and returned with three structural requirements (resources, ladder, twelve-month goal) plus a real compensation stance, with postponing the hire offered as a legitimate outcome.",
      "files": [],
      "expectations": [
        "Identifies the posting as the 'pit trap' failure pattern by name",
        "Names the six functions loaded onto one person (docs, SDKs, community, support, sales engineering, internal training) as the pit-trap signature rather than as attractive breadth",
        "Requires the posting to state explicitly what resources the role gets",
        "Requires the posting to state a career ladder or progression path, or to say plainly that none exists yet",
        "Requires a stated twelve-month goal for the role",
        "Offers postponing the hire until resources, ladder and goal exist as a legitimate outcome, not only rewriting the text",
        "Rejects 'competitive salary and equity' and requires either a published range or an explicit statement of why the range is gated",
        "Does not assert what Colorado or any other named jurisdiction's pay-transparency law currently requires, and asks the user to confirm the current rule for the hiring location instead",
        "Points out that 'no formal DevRel background required' is internally inconsistent with the scope the posting loads onto the role",
        "Names the funding driver the role will be measured on, or flags that the posting does not state one"
      ]
    },
    {
      "id": 4,
      "prompt": "We're down to three candidates for a Developer Advocate opening at Quilt Metrics (usage-metering API, Series B). For the next stage I want a take-home: write a 1,200-word tutorial using our API and record a 5-minute Loom walking through it. Realistically 6-8 hours of work. Unpaid obviously, everyone in this industry does this. Two of the three already have public blogs and a couple of conference talks between them; the third is a career-changer with basically nothing public. How should I brief the take-home and what rubric should I score it on?",
      "expected_output": "The unpaid take-home is refused for the two candidates with public work, a six-signal portfolio evaluation is run first, and any surviving work sample is paid, scored on a frozen rubric, and applied identically to every candidate.",
      "files": [],
      "expectations": [
        "Refuses to design an unpaid spec-work take-home for the two candidates who already have public writing and speaking artefacts",
        "States that a portfolio evaluation runs before any new work is requested from a candidate",
        "Offers a paid live working session as the alternative where a work sample is genuinely needed",
        "States that any work sample, if run, must be paid and scored against a fixed rubric, never treated as free trial work",
        "Evaluates the portfolio-rich candidates against the six-signal rubric: public writing, public speaking, code in public, community evidence, teaching artefact, developer-voice artefact",
        "Notes that judging the existing public work first can remove the need for the content take-home entirely",
        "Does not accept 'everyone in this industry does this' as a reason to keep the exercise unpaid",
        "Requires the same exercise and the same rubric to apply to every candidate for the role, rather than running a different stage for the career-changer alone",
        "Recommends freezing the rubric so every candidate for the role is scored against the same bar",
        "Scores each of the six signals on a 0-3 scale where 0 is absent, 1 is claimed but unevidenced, 2 is evidenced, and 3 is evidenced with a stated outcome"
      ]
    },
    {
      "id": 5,
      "prompt": "Need a decision by tomorrow on who we advance for our product-focused Developer Advocate role. Growth-stage, product-led, everything is self-serve API signup.\n\nMarco: 47k followers on X, posts daily, mostly about his own consulting practice. Two Medium posts behind a paywall, and he mentioned a ghostwriter drafted them. No public repos I could find. Claims he 'drove 4 million impressions' at his last company - when I asked what that converted to he changed the subject and then said impressions are a vanity metric anyway. Nine years in software sales engineering.\n\nFen: finished a bootcamp 14 months ago. No blog, no talks. Three small public repos, I cloned one and it ran first try with a clear README. Filed 11 issues on our own GitHub last year, one of which turned into a full docs rewrite on our side. Extremely active in our Discord, answers other people's questions.\n\nGut says Marco because of the reach. Who do we advance?",
      "expected_output": "Both candidates scored across all six signals on the 0-3 scale, weighted toward code in public and developer-voice artefact for the product-focused sub-role, with Marco's negative signals named explicitly and a paid, scored work sample designed for Fen.",
      "files": [],
      "expectations": [
        "Scores both candidates across all six signals (public writing, public speaking, code in public, community evidence, teaching artefact, developer-voice artefact) on the 0-3 scale",
        "Weights the scoring toward code in public and the developer-voice artefact because the target sub-role is a product-focused advocate",
        "Names Marco's follower count with no substance behind it as a negative signal explicitly, not merely as a missing strength",
        "Names the ghostwritten, paywalled content Marco cannot defend in conversation as a negative signal",
        "Names Marco's shifting story on the impressions figure as the exaggerated-or-dismissed-metrics negative signal",
        "Credits Fen's 11 filed issues, and the one that produced a docs rewrite, as a developer-voice artefact",
        "Credits Fen's runnable public repos as code in public rather than discounting them as bootcamp projects",
        "States that a product-focused advocate is screened on a recent developer background, a stricter bar than the outreach-focused variant",
        "Designs a scored, paid work sample for Fen matched to the product-focused sub-role, such as reviewing an anonymised support thread and proposing the SDK or docs fix",
        "Marks the score bands used as a working baseline rather than presenting them as a published industry standard"
      ]
    },
    {
      "id": 6,
      "prompt": "Hiring a Community Manager for our Discord and forum - open-source distributed database, 35k Discord members, lots of heated threads about our licence change last year. I don't want to get this wrong so I want to run the full gauntlet: technical self-rating questionnaire first as a filter, then a coding take-home, a content take-home, a presentation round, three conversational rounds, a DevRel-opinion round, and a founder round at the end. We're a 9-person team and honestly I can spare about 3 hours of interviewer time per candidate in total. What order should these go in?",
      "expected_output": "Stages deleted rather than reordered: a 2-3 stage loop built from portfolio evaluation plus conflict-handling conversational rounds, with the coding take-home removed as non-discriminating and the self-rating questionnaire demoted from gate to follow-up targeting.",
      "files": [],
      "expectations": [
        "Deletes interview stages rather than only reordering the eight the user listed",
        "Cuts the loop to 2-3 stages for a community-manager hire",
        "Removes the coding take-home, stating it does not discriminate for this sub-role",
        "Keeps the portfolio evaluation and places it before any new work is requested of the candidate",
        "Keeps a conversational round with an explicit conflict-handling or de-escalation emphasis",
        "States there is no standard DevRel interview loop, so formats are chosen against this role's pillar mix rather than run by default",
        "Recommends skipping a live work sample entirely rather than running one unscored under the three-hour ceiling",
        "States that a technical self-rating questionnaire must never gate or veto a candidate on its own, and is used to target follow-up questions in a later round",
        "Screens the community-manager role on adjacent people-field experience and coaching or conflict-resolution communication rather than on hands-on coding depth",
        "Includes at least one DevRel-opinion question in whatever loop survives the cut"
      ]
    },
    {
      "id": 7,
      "prompt": "Our interview process at Brightwell: after all the rounds, the four interviewers get in a room for 30 minutes, talk the candidate through, and land on hire/no-hire by consensus. Works fine for our backend engineers. But we just lost a Developer Advocate candidate we all liked to a competing offer, and the debrief before that one was a mess - two people visibly flipped their opinion after the hiring manager spoke first, and then nobody wanted to be the holdout. Help me run a tighter debrief meeting.",
      "expected_output": "Scoring moved out of the debrief entirely: independent, evidence-noted scores submitted before any discussion, combined mechanically against pre-set scorecard weights, with the debrief limited to calibrating interpretation.",
      "files": [],
      "expectations": [
        "Moves scoring out of the debrief: every interviewer submits an independent score before any discussion happens",
        "Requires a written evidence note per competency alongside each submitted score",
        "Combines scores mechanically against pre-set competency weights rather than reaching a consensus verdict in the room",
        "States that the debrief calibrates interpretation of already-submitted scores and never originates a score",
        "Identifies the two interviewers flipping after the hiring manager spoke as the failure the change prevents, rather than a meeting-facilitation problem to coach around",
        "Requires competency weights to be set on the scorecard before the loop runs, not after candidates are seen",
        "Requires the same question set to be used for every candidate for the role",
        "Requires every interview question to map to a named scorecard competency",
        "Notes that the structured, independently-scored, mechanically-combined result is a general employment-selection finding rather than a DevRel-specific one",
        "Does not propose a blended single gut score or a group-consensus rating as the output of the debrief"
      ]
    },
    {
      "id": 8,
      "prompt": "Our first Developer Advocate starts March 2nd at Overtone - API observability, Series B, product-led, about 400 self-serve teams on the platform. I've got a 30-60-90 doc half written and my VP wants it tightened before Friday. Right now it says: month 1 'onboard, meet the team, read the docs, get set up with all our tools'; month 2 'start posting on the company blog and attend a conference'; month 3 'own the community'. Can you clean this up and make it sound more rigorous?",
      "expected_output": "A ramp plan anchored on artefacts rather than activities: a day-30 friction log with severity and proposed fix per point, a day-60 paired shipped artefact plus a landed friction-log fix and a first metric attempt, and day-90 self-directed ownership with a written funding-driver metric plan and a joint written decision.",
      "files": [],
      "expectations": [
        "Replaces the month-1 onboarding list with a shipped friction log as the day-30 deliverable",
        "Specifies that the friction log carries a severity and a proposed fix for each point",
        "Sets a day-60 milestone of one shipped artefact in the target pillar, paired with an existing team member",
        "Requires at least one friction-log fix from day 30 to land by day 60, driven through docs or engineering by the new hire",
        "Requires a first attempt at the metric the role's funding driver is measured on by day 60, even as a rough baseline number",
        "Sets a day-90 milestone of self-directed ownership of one recurring program slice, without a pairing partner",
        "Requires a written plan by day 90 for the funding-driver metric, covering what good looks like in two quarters and how it will be tracked",
        "Requires a joint, written manager and new-hire decision at day 90 on continuing at the current scope, adjusting it, or escalating a concern",
        "Treats the three missed milestones as an explicit decision trigger rather than an assumed extended grace period",
        "Replaces 'attend a conference' with a shipped deliverable, since attendance is an activity and not a milestone"
      ]
    },
    {
      "id": 9,
      "prompt": "I run the ecosystem team at the Torrent Mesh Foundation - vendor-neutral, six corporate members, we steward a networking project. We want to bring on 8-10 ambassadors this quarter. I already wrote the requirement list by copying our salaried Developer Advocate posting: 4+ years experience, own the conference schedule for their region, respond to community questions within 24 hours, and report to me in a weekly 1:1. Where should I post it to get applicants? I was going to put it on LinkedIn and Indeed and maybe boost it.",
      "expected_output": "The paid-versus-unpaid question is settled first, the salaried requirement list is refused for an ambassador program, and sourcing is redirected from generic boards to community scouting, organic-content scouting, referrals and niche DevRel boards.",
      "files": [],
      "expectations": [
        "Asks whether the ambassador role is paid or unpaid before accepting the copied requirement list",
        "States that foundation ambassador programs are frequently unpaid and gated on measurable contribution rather than communication polish",
        "Refuses to carry the salaried Developer Advocate requirement list into an unpaid ambassador program",
        "Flags the weekly reporting line and the 24-hour response obligation as employment-shaped obligations inappropriate for an unpaid program",
        "Cites a foundation ambassador program that is explicitly not a paid position and selects on a minimum contribution score, such as the CNCF Ambassador program",
        "Treats a salaried vendor-neutral foundation advocate posting and an unpaid ambassador program as two different postings, never one template",
        "States that generic job boards such as LinkedIn and Indeed underperform here, because the pool that both codes credibly and communicates publicly is small and already visible through other channels",
        "Recommends scouting already-engaged contributors inside the project's own community venues and approaching them directly",
        "Notes that technology-specific Slack and Discord communities generally forbid unsolicited direct messages, so a post in a dedicated jobs channel respects each community's own rules",
        "Names niche DevRel job boards as preferable to generic boards because their listings are pre-filtered to companies already running a DevRel function"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "how do I hire a developer advocate", "should_trigger": true },
    { "query": "write me a job posting for a developer advocate", "should_trigger": true },
    { "query": "what should our DevRel interview loop look like", "should_trigger": true },
    { "query": "we need a scorecard for our first devrel hire", "should_trigger": true },
    { "query": "is this candidate's portfolio good enough to advance to the next round", "should_trigger": true },
    { "query": "design a take-home exercise for a developer advocate candidate", "should_trigger": true },
    { "query": "our developer evangelist job ad isn't converting, can you look at it", "should_trigger": true },
    { "query": "what questions should I ask a community manager candidate", "should_trigger": true },
    { "query": "30-60-90 plan for a new developer advocate starting next month", "should_trigger": true },
    { "query": "how do I tell whether a devrel candidate is any good", "should_trigger": true },
    { "query": "we're hiring our first person to do docs, talks and community - what do we even call the role", "should_trigger": true },
    { "query": "what's a fair interview process for a developer educator", "should_trigger": true },
    { "query": "should I ask a candidate to write us a blog post as a test", "should_trigger": true },
    { "query": "how many rounds should we run for a DX engineer hire", "should_trigger": true },
    { "query": "requirements list for a founding developer advocate", "should_trigger": true },
    { "query": "help me build a rubric to evaluate developer advocate candidates", "should_trigger": true },
    { "query": "we keep getting applicants who can talk but can't code - fix our screen", "should_trigger": true },
    { "query": "where do I find developer advocate candidates", "should_trigger": true },
    { "query": "our devrel job description reads like we want a unicorn", "should_trigger": true },
    { "query": "what should the first 90 days look like for a developer advocate", "should_trigger": true },
    { "query": "I need to write a JD for someone to run our developer community", "should_trigger": true },
    { "query": "how should four interviewers score a devrel candidate", "should_trigger": true },
    { "query": "what does 'senior developer advocate' actually mean when we're only 8 people", "should_trigger": true },
    { "query": "evaluate this developer advocate resume for us", "should_trigger": true },
    { "query": "should we put a salary range in our devrel posting", "should_trigger": true },
    { "query": "planning an interview panel for a developer relations manager", "should_trigger": true },
    { "query": "we want ambassadors for our open source project, how do we recruit them", "should_trigger": true },
    { "query": "what outcomes should I put on a devrel role's scorecard", "should_trigger": true },
    { "query": "reusing my old developer advocate JD from my last company at a 6-person startup, is that ok", "should_trigger": true },
    { "query": "designing a paid work sample for someone new to devrel", "should_trigger": true },
    { "query": "which interview formats actually predict a good developer advocate", "should_trigger": true },
    { "query": "how do I ramp a new community manager in their first quarter", "should_trigger": true },
    { "query": "our devrel hire failed at 6 months, what should we have tested for", "should_trigger": true },
    { "query": "what red flags should I look for in a developer advocate's public work", "should_trigger": true },
    { "query": "we need someone to do developer marketing and I don't know what to screen on", "should_trigger": true },
    { "query": "turn this list of responsibilities into a proper role definition for our advocate hire", "should_trigger": true },
    { "query": "briefing an external recruiter on a developer relations opening", "should_trigger": true },
    { "query": "onboarding plan for our new developer experience hire", "should_trigger": true },
    { "query": "how do I compare two devrel candidates with completely different backgrounds", "should_trigger": true },
    { "query": "should this role need to ship SDK samples or is speaking well enough", "should_trigger": true },
    { "query": "we only have 3 hours of interviewer time per candidate, what do we cut from the loop", "should_trigger": true },
    { "query": "how do I prep for a developer advocate interview next week", "should_trigger": false },
    { "query": "review my devrel portfolio before I start applying", "should_trigger": false },
    { "query": "I want to break into developer relations from backend engineering", "should_trigger": false },
    { "query": "should I take this developer advocate offer or stay where I am", "should_trigger": false },
    { "query": "how do I negotiate a devrel salary", "should_trigger": false },
    { "query": "what should be on my resume for a community manager role", "should_trigger": false },
    { "query": "am I ready to apply for a senior developer advocate position", "should_trigger": false },
    { "query": "should DevRel report to marketing or to product", "should_trigger": false },
    { "query": "how big should our devrel team be at series B", "should_trigger": false },
    { "query": "centralized or embedded devrel org, which shape fits us", "should_trigger": false },
    { "query": "who should own docs, devrel or engineering", "should_trigger": false },
    { "query": "how do we make our engineering brand attractive to senior engineers", "should_trigger": false },
    { "query": "what should our careers page say to developers", "should_trigger": false },
    { "query": "should we start an engineering blog to attract engineers", "should_trigger": false },
    { "query": "how do I measure devrel impact for my board deck", "should_trigger": false },
    { "query": "what devrel metrics should I report monthly", "should_trigger": false },
    { "query": "set up event tracking across our docs and blog", "should_trigger": false },
    { "query": "how much should we spend on devrel next year", "should_trigger": false },
    { "query": "what should our developer relations strategy be for next year", "should_trigger": false },
    { "query": "split our devrel budget across events and content", "should_trigger": false },
    { "query": "design a perks ladder for our developer champions program", "should_trigger": false },
    { "query": "what obligations should champions have in our ambassador program", "should_trigger": false },
    { "query": "should we start a Discord or a forum for our users", "should_trigger": false },
    { "query": "write a code of conduct for our developer community", "should_trigger": false },
    { "query": "how do I measure the health of our developer community", "should_trigger": false },
    { "query": "how do we get more first-time contributors to our repo", "should_trigger": false },
    { "query": "who decides what gets merged in our open source project", "should_trigger": false },
    { "query": "help me write a conference talk proposal", "should_trigger": false },
    { "query": "audit our quickstart guide", "should_trigger": false },
    { "query": "turn these commits into release notes", "should_trigger": false },
    { "query": "plan our devrel content calendar for Q3", "should_trigger": false },
    { "query": "map the developer journey for our platform team segment", "should_trigger": false },
    { "query": "which conferences should we sponsor this year", "should_trigger": false },
    { "query": "write a case study about how Northwind uses our API", "should_trigger": false },
    { "query": "write a job description for a senior backend engineer", "should_trigger": false },
    { "query": "design an interview loop for a product manager", "should_trigger": false },
    { "query": "build a hiring scorecard for our first sales rep", "should_trigger": false },
    { "query": "how do I run a technical coding interview", "should_trigger": false },
    { "query": "write our engineering onboarding checklist", "should_trigger": false },
    { "query": "recruiting strategy for a data science team", "should_trigger": false },
    { "query": "what questions should I ask in a reference check", "should_trigger": false }
  ]
}

# Company type and funding driver lookup

Contents: the company-type bar · the four pillars · the seven funding drivers · per-sub-role hiring requirements.

Source: "A review of DevRel job titles and career progression" (Hoopy, May 2023, sponsored by Common Room); Matthew Revell, "The four pillars of developer relations" (developerrelations.com, 2018, updated 2025).

## Company-type bar

The same title means a different job across these columns. Tatiana Mikhaleva (Docker Captain, CNCF Ambassador): "'DevRel' and 'Developer Advocate' mean something different at every company." Recalibrate the whole scorecard against this table before reusing any prior posting.

| Dimension           | Early startup (pre-seed-A), team of one             | Growth / scale-up (B-D)                        | Big-tech enterprise                                     | OSS-first / foundation                                         |
| ------------------- | --------------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------- |
| Hires for           | generalist across all four pillars, self-directed   | one pillar deep, collaborative                 | specialised; separate advocacy/education/community orgs | contributor-community credibility, maintainer instincts        |
| Portfolio must show | breadth plus one end-to-end outcome owned alone     | depth in the pillar, cross-functional evidence | sustained high-quality output at scale, in one lane     | real contribution history, triage and governance participation |
| "Senior" means      | founding generalist                                 | specialist plus team lead                      | anchored to the engineering ladder                      | deep upstream contributor, vendor-neutral                      |
| Coding depth        | high - builds the demos and the docs                | medium-high                                    | high - sample code, client libraries, API review        | very high - PRs, CVE fixes, working-group membership           |
| Content and travel  | very high volume, one person covers every channel   | structured, shared across a team               | large budgets, heavy conference presence                | community-led events and meetups                               |
| Success measured by | signups, early adoption, founder proximity          | activation and funnel metrics                  | attribution and product influence                       | contributor growth and project velocity                        |
| Comp structure      | low cash, meaningful equity, tiny conference budget | mid cash plus equity                           | high base plus stock, large travel budget               | foundation salary, or unpaid ambassador plus stipend           |

Foundation ambassador programs are frequently unpaid and gated on measurable contribution rather than communication skill - the CNCF Ambassador FAQ states the program is not a paid position and selects on a minimum DevStats contribution score. Foundations also hire salaried, vendor-neutral advocates; treat the two as different postings entirely, never the same template.

## The four pillars

| Pillar               | Definition                                                                   | Representative activities                                                                               |
| -------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Developer advocacy   | two-way bridge: developer needs into the company, guidance out to developers | speaking, sample apps and reference implementations, forum engagement, carrying feedback to product     |
| Developer marketing  | surfacing the technology where developers already are, without a sales push  | technical content marketing, technical SEO, developer social, event sponsorship, newsletters            |
| Developer enablement | removing friction once a developer tries the product                         | docs strategy, SDKs and tooling, getting-started guides, code samples, training and certification       |
| Developer community  | peer-to-peer learning and long-term engagement                               | community platforms, champions/ambassador programs, events and hackathons, recognising OSS contribution |

Boundaries are fuzzy on purpose - the same blog post can be marketing, advocacy and enablement at once. Ask which pillar the posting's outcomes actually sit in before writing the requirement list.

## The seven funding drivers

Developer adoption · sales enablement · developer enablement · product input · ecosystem and partnerships · contributor community · employer branding.

The driver determines the pillar mix, which determines what the role is measured on, whatever the title says:

- Early-stage companies fund enablement plus marketing.
- OSS projects fund community plus advocacy.
- Enterprise platforms fund enablement plus advocacy.
- Growth-stage companies fund marketing plus community.

Name the driver in the scorecard's mission line. A posting that cannot state its own driver is a posting nobody has decided the purpose of yet.

## Per-sub-role hiring requirements

| Sub-role                  | Screened on                                                                                                                                                                                                     |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Outreach-focused advocate | some developer background, content creation, public speaking, networking, empathy, written communication                                                                                                        |
| Product-focused advocate  | a _recent_ developer background (stricter than outreach), content creation, networking, empathy                                                                                                                 |
| Community manager         | experience in an adjacent people field (support, social work), coaching and conflict-resolution communication, networking, empathy; less hands-on code except where community work includes OSS issue/PR triage |
| Developer educator        | pedagogy or teaching background, learner-journey design, ability to read code and instrument where learners get stuck                                                                                           |
| DX engineer               | strong engineering background, prior experience consuming similar products, technical writing                                                                                                                   |

A posting screening for all five profiles at once is screening for none of them - decide the sub-role before writing the requirement list.

# Interview loop and question bank

Contents: the verified format set · loop design per sub-role · the question bank by competency · scoring mechanics.

## The verified format set

There is no standard DevRel loop - candidates report meeting any subset of these for the same job title. Pick 3-5 formats that actually test the target sub-role's pillar mix; running every format regardless of role wastes interviewer hours on tests that do not discriminate for this seat.

| Format                              | What it tests                                                                           | Best for                              |
| ----------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------- |
| Presentation round                  | the core public artefact of the job: clarity, pacing, audience read, handling questions | outreach advocate, community manager  |
| Content take-home (a post or video) | writing a developer would trust: shows the code, admits trade-offs, no marketing voice  | outreach advocate, developer educator |
| Coding take-home                    | can build what they will advocate                                                       | product-focused advocate, DX engineer |
| Technical self-rating questionnaire | breadth calibration and honesty - inflated self-ratings unravel in the next round       | any role, as an early screen          |
| Conversational rounds               | technology fluency, community experience, collaboration style                           | every role                            |
| DevRel-opinion round                | the candidate's model of the practice itself - has no memorised right answer            | senior hires, any role                |
| Founder / exec round                | commercial understanding and culture fit                                                | early-stage startup hires             |

Place the portfolio evaluation (Artefact 3 in the skill body) before any new work is requested - judging existing public work first often removes the need for a content or coding take-home entirely.

## Loop design per sub-role

| Sub-role                  | Suggested formats                                                                                     | Stage count |
| ------------------------- | ----------------------------------------------------------------------------------------------------- | ----------- |
| Outreach-focused advocate | portfolio evaluation, presentation round, conversational round, DevRel-opinion                        | 3-4         |
| Product-focused advocate  | portfolio evaluation, coding take-home, conversational round, DevRel-opinion                          | 3-4         |
| Community manager         | portfolio evaluation, conversational rounds (conflict-handling emphasis), presentation round optional | 2-3         |
| Developer educator        | portfolio evaluation, content take-home, conversational round                                         | 2-3         |
| DX engineer               | portfolio evaluation, coding take-home, technical conversational round                                | 2-3         |

Add a founder/exec round for any early-startup hire regardless of sub-role.

## Question bank by competency

Write 2-3 questions per scorecard competency; include at least one DevRel-opinion question per loop.

**DevRel philosophy and strategy**

- What is developer relations for, at a company like ours? (Tests whether they can name a funding driver and pillar mix, not recite a definition.)
- How would you measure your own work here, and what would you refuse to be measured on?
- How do you align DevRel initiatives with the product roadmap?

**Content and communication**

- Walk me through a piece of content you shipped and what it changed.
- How do you keep a tutorial correct after the product changes underneath it?
- How do you translate a complex technical concept for a non-expert audience without losing accuracy?

**Community management**

- How do you identify and grow community leaders or ambassadors?
- Describe a toxic or hostile thread you handled, and the outcome.
- What community-health metrics do you actually trust, and which do you distrust?

**Technical depth**

- How do you evaluate whether documentation is accurate and current?
- Describe your experience integrating with an SDK or API you didn't build.
- How deeply do you expect to understand our architecture, and how would you get there?

**Public speaking**

- How do you prepare a technical talk for an audience with mixed backgrounds?
- How do you handle a live demo failure or a hostile question mid-talk?

**Metrics and measurement**

- What DevRel metrics have you owned, and which did leadership actually believe?
- Tell me about a time data changed a DevRel decision you'd already made up your mind about.

**Behavioural and scenario-based**

- Tell me about developer feedback you carried into a product decision that shipped - name the change.
- A major product delay threatens community momentum. What do you do in the first week?
- A key community contributor leaves. How do you manage the transition?

**Cultural fit**

- How do you stay current with the ecosystem you're advocating in?
- Describe how you've mentored someone junior into a public-facing role.

## Scoring mechanics

- Every interviewer scores independently, with a written evidence note per competency, before any debrief happens.
- Combine scores mechanically against the scorecard's pre-set competency weights. This is a general employment-selection finding - structured, independently-scored, mechanically-combined interviews outperform unstructured ones and holistic group debriefs - not a DevRel-specific one, but nothing about the finding is domain-specific, so it transfers directly.
- The debrief calibrates interpretation of already-submitted scores; it never originates a score.
- Never let a technical self-rating questionnaire gate or veto a candidate on its own - use it to target follow-up questions in the conversational round.

# Portfolio and work-sample scoring

Contents: applying the six-signal rubric from the evaluator's side · negative signals to name · designing a paid work sample when the portfolio is thin.

## The six-signal rubric, applied

The full rubric, its scoring bands, and the candidate-facing framing live in `samber/developer-relations-skills@devrel-career`. This file is the same instrument read from the hiring side.

Score each 0-3: 0 absent, 1 claimed but unevidenced, 2 evidenced, 3 evidenced with a stated outcome.

| #   | Signal                   | What a 3 looks like                                                                                             |
| --- | ------------------------ | --------------------------------------------------------------------------------------------------------------- |
| 1   | Public writing           | Published posts with a link, on a niche this role cares about, at least one showing a result                    |
| 2   | Public speaking          | Two or more talks with links to video or slides; a lightning talk counts                                        |
| 3   | Code in public           | Repos a stranger can run, matching the target product's surface, with a contribution history                    |
| 4   | Community evidence       | A role held (moderating, organising, mentoring), not membership                                                 |
| 5   | Teaching artefact        | A tutorial, workshop, or learner journey with checkpoints                                                       |
| 6   | Developer-voice artefact | A published friction log, feedback synthesis, or issue thread showing user research reaching a product decision |

Weight by the target sub-role: outreach advocate on signals 1+2; product-focused advocate on 3+6; community manager on 4; educator on 5; DX engineer on 3+1.

Score bands, as this skill's own working baseline (not a published industry standard - move them for a stated reason): under 6 total, the candidate needs more shipped work before this loop can evaluate them fairly; 6-11, evaluate the weighted signals for this specific sub-role; 12+, the constraint is targeting fit, not evidence volume.

## Negative signals to name explicitly

Name these when present, rather than only listing what to add - a hiring manager who only lists gaps lets a real red flag pass silently.

- Follower count with no substance behind it.
- Content that only talks about the candidate rather than the developers they served.
- No shipped code and no public artefacts at all for a product-focused or DX role.
- Ghostwritten or paywalled content that the candidate cannot defend in conversation.
- Metrics exaggerated, or dismissed entirely when asked.
- Cannot name a specific developer or team they helped.

## Designing a paid work sample when the portfolio is thin

Never request unpaid spec work when a public portfolio already exists - offer a paid live working session instead. When the candidate is new to the field and has little public work to evaluate, design a short, scored, paid exercise matched to the target sub-role:

| Sub-role                 | Work-sample design                                                                   | Scored on                                                  |
| ------------------------ | ------------------------------------------------------------------------------------ | ---------------------------------------------------------- |
| Outreach advocate        | A 5-minute lightning talk on a topic the candidate picks within the product's domain | Clarity, audience read, handling one injected question     |
| Product-focused advocate | Review a real (anonymised) support thread and propose the SDK or docs fix            | Root-cause read, fix quality, communication to engineering |
| Community manager        | Draft a response to a real (anonymised) hostile community thread                     | Tone, de-escalation, policy consistency                    |
| Developer educator       | Edit a rough internal tutorial draft for a specific learner persona                  | Pedagogical structure, accuracy, accessibility             |
| DX engineer              | A short, scoped integration or SDK-usage exercise against the actual product         | Working code, README a stranger could follow               |

Freeze the rubric for a quarter once set, so every candidate for the role is scored against the same bar.

# 30-60-90 ramp plan template

Contents: the three-phase structure · the artefact milestone at each phase · the early-warning check.

DevRel has no published, field-wide ramp benchmark the way sales has quota-attainment surveys - this template is this skill's own working structure, built from the same artefact logic devrel-career uses for entry: coding depth is role-dependent, but shipping something real, in public or internally, is universal.

## Day 0-30: use the product like a developer would

- Onboard onto the product as a real user, on the same path a developer prospect would take.
- Meet the developers already using the product, and the internal teams (product, support, docs) whose work this role touches.
- Ship a friction log: the concrete points where onboarding, docs, or the API confused a fresh user, with severity and a proposed fix per point.
- Certification/product-knowledge gate: the new hire can explain the product's core workflow to a stranger without notes.

## Day 31-60: ship the first real artefact

- Ship one artefact in the target pillar: a talk, a tutorial, an SDK sample, or a community program slice, paired with an existing team member.
- At least one of the friction-log fixes from day 30 lands, with the new hire driving it through docs/engineering.
- First attempt at the metric this role's funding driver is measured on (see [company-type-and-driver-lookup.md](./company-type-and-driver-lookup.md)) - even a rough baseline number counts.

## Day 61-90: self-directed ownership

- Own one recurring program slice without a pairing partner (a content series, a community ritual, an integration line).
- Deliver a written plan for the funding-driver metric: what "good" looks like in two quarters and how it will be tracked.
- Manager and new hire jointly decide, in writing, whether the 90-day evidence supports continuing at the current scope, adjusting it, or escalating a concern.

## Early-warning check

A hire who has not shipped the day-30 friction log, the day-60 artefact, and a first metric attempt by day 90 needs an explicit conversation, not an extended grace period assumed silently. Treat the three milestones as a decision trigger, the same way sales-hiring treats a missed 90-day quota-ramp milestone.

# Scorecard and posting template

Contents: the scorecard structure · a worked posting example · the gatekeeper/pit-trap self-audit checklist.

## Scorecard structure

1. **Mission** - one sentence naming the funding driver (adoption, sales enablement, developer enablement, product input, ecosystem/partnerships, contributor community, employer branding).
2. **Outcomes** - 3-8 measurable results, ranked by importance, each quantified. Never a list of activities.
3. **Competencies** - 5-7, weighted per the role's sub-type and company type from [company-type-and-driver-lookup.md](./company-type-and-driver-lookup.md).

The scorecard doubles as the interview rubric (Artefact 2) and the ramp milestone map (Artefact 4), so quantify outcomes even when the user's first draft resists it.

## Worked example - product-focused advocate, growth-stage, PLG motion

**Mission:** Reduce time-to-first-successful-API-call for self-serve developers, funded as a developer-enablement and product-input driver.

**Outcomes:**

1. Cut the top three onboarding support threads by 25% within two quarters via shipped docs/SDK fixes, evidenced by a published friction log.
2. Ship two reference integrations for the platform's two highest-volume use cases within the first quarter.
3. Deliver a quarterly developer-feedback synthesis that changes at least one product-roadmap decision, with the change named and dated.
4. Grow accepted community-sourced content (tutorials, integrations) from zero to five pieces in year one.

**Competencies:** API design literacy, technical writing, developer-empathy interviewing, cross-functional influence without authority, sample-code craftsmanship.

## Negative example - the un-scored version

> We're looking for a rockstar Developer Advocate who's passionate about our mission! You'll write blogs, speak at conferences, run our community, help support tickets, and work closely with product. 3+ years experience required, strong coding skills a must, and you should be comfortable wearing many hats in a fast-paced environment.

Why it fails the gatekeeper/pit-trap audit below: a tactics list ("write blogs, speak at conferences, run our community, help support tickets") with no stated outcome, "many hats" with no resourcing statement, and a flat experience requirement with no named sub-role or level.

## Gatekeeper / pit-trap self-audit

Run before publishing any posting (Joe Nash, DevRelCon 2021 - the same taxonomy candidates are taught to detect in devrel-career).

- [ ] **Gatekeeper check** - does the requirement list describe one impossible person (full engineering career, plus OSS contribution, technical writing, community building, event organising) at entry pay? If yes, cut to what the actual pillar mix needs.
- [ ] **Pit-trap check** - does "founding DevRel, no background required" actually mean one person covers docs, SDKs, community, support, sales engineering and training, with no stated resources, ladder, or twelve-month goal? If yes, state the resources and goal explicitly, or postpone the hire.
- [ ] **Off-core-skills check** - is the weight on specific stack requirements or audience-size claims instead of the fundamentals of communicating with developers?
- [ ] **Tactics-vs-outcomes check** - does every activity in the posting trace to a stated outcome, or is it a laundry list?
- [ ] **Levelling check** - does the seniority implied by the requirements match the seniority of the title and the pay?

A posting failing any one of these needs a rewrite before publishing, not after it fails to convert candidates.

# Candidate sourcing channels

Contents: ranked channels · why generic job boards underperform here.

DevRel hiring skews toward channels that surface people already doing the work in public, not toward posting-and-waiting on a generic board - the same public-artefact logic that runs through the whole field's hiring practice.

## Ranked by what practitioners report actually working

- **Niche DevRel job boards** (e.g. devreljob.com) over generic boards - listings pre-filtered to companies already running a DevRel function.
- **Community scouting inside the product's own Slack or Discord** - identify already-engaged power users and ask directly. A documented pattern: a product's most active community member becomes its first developer advocate hire. Retention argument: someone who joined a community because they liked the product tends to stay past the hire.
- **Organic-content scouting** - watch blogs, YouTube, conference-speaker lists, and technical forums (Stack Overflow, Reddit, Hacker News) for people already producing the exact artefact this role needs, then approach directly.
- **Referrals from the existing DevRel network** - practitioners report referrals outperforming cold applications; visibility comes from commenting on job posts and engaging publicly in the same threads the team already reads.
- **Technology-specific Slack/Discord communities** - post in a dedicated `#jobs` channel, respecting each community's own rules; most forbid unsolicited direct messages to members.
- **DevRel-specific conferences** - in-person hiring-manager networking, lower volume, high fit.
- **Content-agency partner networks** - some agencies maintain vetted technical writers or engineers doing contract DevRel-adjacent work, giving a pipeline to convert a contractor to a hire.

## Why generic job boards and cold outreach underperform

The pool of people who both code credibly and communicate publicly is small and already visible through the channels above. A generic posting reaches a much larger pool of people who match the words in the ad but not the publicly-provable work sample this role actually needs - which is also why Artefact 3 scores shipped public work over resume claims.

---
name: devrel-hiring
description: Employer-side DevRel hiring - writes the job posting and outcome-based scorecard, designs the interview loop and question bank across the field's formats (presentation round, take-homes, DevRel-opinion round), scores a portfolio against the six-signal rubric, designs a paid work sample instead of unpaid spec work, and builds a 30-60-90 ramp anchored on a friction log. Splits by company type and funding driver. Use when the user asks how to hire a developer advocate, write a DevRel job posting, design a loop for a community manager or educator, evaluate a candidate's portfolio, or plan a ramp. Do NOT use for candidate-side prep (samber/developer-relations-skills@devrel-career) or org design (samber/developer-relations-skills@devrel-team-structure).
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# DevRel Hiring

Build the four artefacts a hiring manager needs to recruit into a DevRel role with the same rigour the field's own hiring research recommends: a role scorecard and posting, a structured interview loop with question bank, a portfolio-and-work-sample evaluation, and a 30-60-90 ramp plan.

DevRel has no standard job description or career ladder (Chris Aniszczyk, CNCF CTO), and its own hiring literature documents two named failure patterns in postings written without this discipline - see Reading the answers. That absence is the reason to build these four artefacts deliberately rather than adapt a generic engineering or marketing hiring template.

Out of scope, hand off instead:

- **Where DevRel reports and how the team is shaped** - samber/developer-relations-skills@devrel-team-structure decides the org before this skill recruits into it.
- **Coaching the candidate** - samber/developer-relations-skills@devrel-career is the mirror image of this skill, built for the person being evaluated.

If the user is job-hunting rather than hiring ("how do I prep for a DevRel interview", "is this posting worth applying to"), say so in one line and point them at devrel-career.

## Interview

Ask one question at a time, multiple-choice where possible. Skip anything already answered. Questions 8-10 re-rank the artefacts below before any is built - ask them before producing anything.

**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. Company type: (a) early startup, pre-seed-A, this will be a team of one (b) growth/scale-up, B-D (c) big-tech enterprise (d) OSS-first company or foundation.
2. Role target: (a) developer advocate, outreach-focused (b) developer advocate, product-focused (c) community manager (d) developer educator (e) DX engineer (f) not sure - recommend one from the funding driver.
3. What funds this role - the driver behind the budget: developer adoption, sales enablement, developer enablement, product input, ecosystem/partnerships, contributor community, or employer branding?
4. Go-to-market motion: sales-led B2B, product-led (PLG) B2B, B2C/individual-facing, or OSS/foundation with no purchase gate.
5. Coding-depth requirement: does this role need to ship SDK samples and review API design, or is the bar public communication with only light code?
6. Team stage: first DevRel hire with no incumbent to calibrate against, or a repeatable hire with existing top performers to profile from?
7. Compensation stance: will you publish a range in the posting, and do you know your hiring jurisdiction's pay-transparency requirement?
8. Deadline: this month, this quarter, or no hard date?
9. One-off hire or the first of several where the scorecard and question bank get reused?
10. Effort ceiling: how many interviewer-hours per candidate, and is there a recruiter or a trained panel?

## Reading the answers

- **Q1 sets the bar and the portfolio weighting** - load [references/company-type-and-driver-lookup.md](./references/company-type-and-driver-lookup.md). A startup hires a generalist who justifies the function's own existence; big tech anchors the role to its engineering levelling scale; an OSS/foundation role screens on contribution history, not communication polish.
- **Q2 + Q3 decide what the posting is screened on** - see [references/company-type-and-driver-lookup.md](./references/company-type-and-driver-lookup.md) for the per-role requirement table. A candidate who cannot say which sub-role they target is applying to all and matching none; the same is true of a posting that cannot say which sub-role it needs.
- **Q3 + Q4 decide the pillar mix and therefore the metric the role is measured on**: sales-led promotes advocacy plus sales enablement; PLG promotes enablement plus product input; B2C promotes community plus reach; OSS/foundation promotes community plus advocacy.
- **Before drafting the posting, self-audit it against the field's two named failure patterns** (Joe Nash, DevRelCon 2021 - the same taxonomy devrel-career teaches candidates to detect from the outside):
  - **Gatekeeper** - describing an impossible person: a full engineering career across several stacks plus OSS contribution, technical writing, community building and event organising, advertised at entry pay.
  - **Pit trap** - "founding DevRel, no background required" that actually expects one person to cover docs, SDKs, community, support, sales engineering, and training with no resources, no ladder and no stated goal.
  - Both share three symptoms: off-core skills emphasis, a tactics list with no stated outcome, and levelling that is inconsistent with the pay. A posting failing any symptom needs a rewrite before it goes out, not after it fails to convert.
- **Q6 decides the candidate profile.** First hire: a builder who can justify the function's existence without an incumbent team, similar to a company's first sales hire - weight self-direction and breadth over specialised depth. Repeatable hire: profile from the org's own top performers on the pillar this role actually owns.
- **Q7 triggers the compensation gate** in the Quality gate below - never invent a jurisdiction's legal requirement; confirm current pay-transparency rules for the hiring location before publishing.
- **Q8 promotes the fast-acting options**: a this-month deadline promotes reusing an existing question bank and a shorter loop over designing a new custom work sample from scratch.
- **Q9 decides whether the work sample stays thin.** One-off: design it once, cheaply. Compounding: the frozen rubric and question bank serve every future hire in this pillar, which promotes building both properly first.
- **Q10 deletes loop stages rather than reordering them.** Under a handful of interviewer-hours per candidate: cut to a scorecard, one structured conversational round, and the portfolio evaluation; skip a live work sample entirely rather than running it unscored.

## Workflow

Produce the four artefacts in order. Deliver each one, validate it with the user, then move to the next.

1. Run the Interview. State the role and pillar-mix recommendation in one short paragraph the user can veto.
2. **Artefact 1 - role scorecard and posting.** Build from [references/company-type-and-driver-lookup.md](./references/company-type-and-driver-lookup.md) and [references/scorecard-and-posting-template.md](./references/scorecard-and-posting-template.md):
   - a one-sentence mission naming the funding driver from Q3
   - 3-8 measurable outcomes ranked by importance and quantified (e.g. "cut top-three onboarding support threads 25% via a shipped friction-log fix", "40 accepted CFPs sourced from the community in year one"), never vague responsibilities
   - 5-7 competencies weighted per the role and company type from Q1-Q2
   - run the gatekeeper/pit-trap self-audit above before publishing
3. **Artefact 2 - interview loop and question bank.** Build from [references/interview-loop-and-question-bank.md](./references/interview-loop-and-question-bank.md):
   - pick 3-5 formats from the field's verified set (presentation round, content take-home, coding take-home, technical self-rating, conversational rounds, DevRel-opinion round, founder/exec round at startups) - there is no standard loop, so choose formats that actually test this role's pillar mix, never the whole set by default
   - place the portfolio evaluation (Artefact 3) early, before any new work is requested of the candidate
   - write 2-3 questions per scorecard competency from the category banks in the reference file, plus at least one DevRel-opinion question - candidates report it as the hardest round because it has no memorised answer, which is exactly why it separates a position from a rehearsed pitch
   - define scoring mechanics: every interviewer scores independently with an evidence note before any debrief, then combine mechanically against the scorecard's pre-set weights - a general employment-selection finding (structured, independently-scored, mechanically-combined interviews outperform unstructured ones and holistic debriefs), not one specific to DevRel, but it transfers directly since nothing about the finding is domain-specific
   - never request unpaid spec work when a public portfolio already exists; offer a paid live working session instead
4. **Artefact 3 - portfolio and work-sample evaluation.** Build from [references/portfolio-and-work-sample-scoring.md](./references/portfolio-and-work-sample-scoring.md):
   - score the candidate's shipped public work against the six-signal distribution rubric (public writing, public speaking, code in public, community evidence, teaching artefact, developer-voice artefact), weighted by the target sub-role from Q2 - the full rubric and its scoring bands live in devrel-career; this skill applies it from the evaluator's side
   - when the portfolio is thin or the candidate is new to the field, design a scored, paid work sample instead of judging by resume alone - a short lightning-talk round, a documentation-edit exercise, or an "explain this API change to a developer" exercise, matched to the target sub-role
   - name the negative signals explicitly when present (follower count with no substance, only self-promotion, no shipped code, inability to name a developer helped) rather than only listing what is missing
5. **Artefact 4 - 30-60-90 ramp plan.** Build from [references/ramp-plan-template.md](./references/ramp-plan-template.md):
   - Day 0-30: the new hire uses the product as a developer would and ships a friction log - the same artefact devrel-career recommends as a portfolio piece, now the first-30-days deliverable
   - Day 31-60: first public or internal artefact shipped in the target pillar, paired with an existing team member
   - Day 61-90: self-directed ownership of one recurring program slice, plus a documented plan for the metric the role's funding driver is measured on
6. Note candidate-sourcing channels from [references/sourcing-channels.md](./references/sourcing-channels.md) if the user has not yet identified where to find candidates.
7. Run the Quality gate below on all four artefacts. Iterate until it passes.
8. If your harness has persistent memory, store the scorecard, the frozen question bank, the loop design and the ramp milestones so later hires into the same role reuse them instead of restarting.

## Company type and funding driver

Never treat a posting template as portable across company types: the same title means a different job at a startup, a growth-stage company, a big-tech vendor, and an OSS-first foundation, and each expects a different portfolio bar and coding depth. The full comparison table, the four pillars, and the seven funding drivers that predict what a role is measured on: [references/company-type-and-driver-lookup.md](./references/company-type-and-driver-lookup.md).

Foundation and OSS-adjacent ambassador-style roles are frequently unpaid and gated on measurable contribution rather than communication skill - confirm which kind of role this is before writing a salaried posting's requirements into an unpaid program, or the reverse.

## Quality gate

Score the four artefacts against these checks before final delivery. Iterate until every check passes.

1. The scorecard has 3-8 outcomes, every one quantified and ranked, and names the funding driver from Q3.
2. The posting passes the gatekeeper/pit-trap self-audit: no off-core skills emphasis, no tactics-without-outcomes list, levelling consistent with the stated pay.
3. Every interview question maps to a named scorecard competency; the same question set applies to every candidate for the role.
4. The loop includes at least one format that actually tests the target pillar (a presentation round for outreach-heavy roles, a coding take-home for DX/product-focused roles), never a generic set copied regardless of role.
5. No stage asks for unpaid spec work when public portfolio evidence already exists.
6. Interviewers submit independent, evidence-noted scores before any debrief; the final combination is mechanical against pre-set weights.
7. The portfolio evaluation is scored against the six-signal rubric, weighted by target sub-role, with negative signals named explicitly where present.
8. If a live work sample was designed, it is scored on a fixed rubric and paid, never treated as free trial work.
9. The posting states a real compensation stance (a published range, or an explicit note on why it is gated) consistent with the Q7 jurisdiction answer - never publish "competitive" with no figure and no stated reason.
10. The ramp plan contains a day-30 friction-log deliverable, a day-60 shipped-artefact milestone, and a day-90 self-directed-ownership milestone.
11. Every claim about "what good looks like" in this skill's own output is traceable to a named source or explicitly marked as this skill's own working assumption - this field has no single authoritative career-ladder body, so an unlabelled claim reads as more settled than it is.

## Common failure modes

Not ranked, deliberately: every row is a defect with one mandatory fix.

| Failure                                                | Fix                                                                                                                      |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| Gatekeeper posting                                     | Cut the off-core requirement list to what the pillar mix actually needs; re-price the level against the real requirement |
| Pit-trap posting                                       | State the resources, the ladder and the twelve-month goal explicitly, or postpone the hire until they exist              |
| Copying a generic engineering or marketing JD template | Rebuild from the funding driver and pillar mix; DevRel's outcomes and competencies do not map onto either template       |
| Judging by resume instead of shipped work              | Run the six-signal portfolio evaluation before any conversational round                                                  |
| Unpaid spec-work audition                              | Offer a paid live working session or judge the existing public portfolio instead                                         |
| One blended gut score after a group debrief            | Independent, evidence-noted scores before any discussion, combined mechanically                                          |
| Applying the same loop to every DevRel sub-role        | Choose formats and questions per the target sub-role's actual screened requirements                                      |
| "Competitive compensation", no range, no reason        | Publish a range or state explicitly why it is gated, checked against the jurisdiction's own current requirement          |
| Ramp plan with no artefact milestone                   | Anchor day 30 on a shipped friction log, day 60 on a shipped pillar artefact, day 90 on self-directed ownership          |
| Treating a title as portable across company types      | Recalibrate the whole scorecard against Q1's company-type row before reusing any prior posting                           |

## Reference

- See [references/company-type-and-driver-lookup.md](./references/company-type-and-driver-lookup.md) for the company-type comparison table, the four pillars, and the seven funding drivers.
- See [references/scorecard-and-posting-template.md](./references/scorecard-and-posting-template.md) for the scorecard structure and a worked posting example.
- See [references/interview-loop-and-question-bank.md](./references/interview-loop-and-question-bank.md) for the format table, per-role loop design, and the category-organised question bank.
- See [references/portfolio-and-work-sample-scoring.md](./references/portfolio-and-work-sample-scoring.md) for the six-signal scoring application and paid work-sample designs.
- See [references/ramp-plan-template.md](./references/ramp-plan-template.md) for the full 30-60-90 template.
- See [references/sourcing-channels.md](./references/sourcing-channels.md) for where DevRel candidates are actually found.
- See `samber/developer-relations-skills@devrel-career` for the candidate's side of this table - portfolio building, interview prep, offer evaluation; this skill never coaches candidates.
- See `samber/developer-relations-skills@devrel-team-structure` for the org design and reporting line this role is recruited into - decided before, not by, this skill.
- See `samber/developer-relations-skills@devrel-metrics` for the measurement framework the scorecard's outcomes should stay consistent with once the hire is in seat.
- See `samber/developer-relations-skills@tech-employer-branding` for the employer-brand surfaces a candidate will check before accepting.