devrel-career

{
  "skill_name": "devrel-career",
  "evals": [
    {
      "id": 1,
      "prompt": "I've been a tier-2 support engineer at Fernwick Logistics for four years. We're a 90-person freight software company and there is nobody here doing developer relations, not even part time, and nobody planning to. I want out of the support queue and into DevRel. I don't code beyond SQL and shell one-liners, and honestly I don't want to learn a real language, it's not where my head is. I've got maybe six hours a week outside work, zero savings buffer, and I'd like to be in a new role within four months. Where do I start?",
      "expected_output": "A short plan that removes the routes the user's constraints rule out, keeps only the adjacent-role sidestep, and redirects the target from developer advocate to community manager or developer educator, with dated artefact steps and a review point.",
      "files": [],
      "expectations": [
        "Removes the internal-transfer route from the plan because the employer has no DevRel function, rather than listing it as a lower-priority option",
        "Removes both coding-dependent routes (engineer-to-public-work and learn-to-code-first) rather than ranking them last",
        "Removes community and hackathon volunteering on the grounds that it takes one to two years of unpaid effort the user has no runway for",
        "Identifies the adjacent-role sidestep as the surviving route",
        "States plainly that the realistic targets are community manager or developer educator, rather than leaving the user aimed at developer advocate",
        "Says explicitly that a ruled-out route is deleted from the plan rather than parked at the bottom of a list",
        "Names the four-month deadline, the six-hours-per-week ceiling and the absent savings as the inputs that re-ranked the routes",
        "Does not recommend a coding bootcamp, a computer-science course, or learning a programming language as a prerequisite step",
        "Does not present the entry routes as equally valid options for the user to pick between",
        "Requires the user to pick one technology niche rather than targeting developer relations generally",
        "Recommends publishing a friction log as one of the first artefacts",
        "Names an observable artefact or event for every recommended step rather than describing effort alone",
        "Sets a dated review point with a condition that means changing course rather than pushing harder"
      ]
    },
    {
      "id": 2,
      "prompt": "I teach high-school computer science in Leeds, nine years of it. My partner earns enough that I could go without a salary for roughly three years if it came to that, and I have no deadline. What I actually want is the DevRel engineer job at a database company: building the integrations and the sample code, sitting close to product, not the conference-circuit version of the role. I can write Python at teaching level and that's about it. What order should I do things in?",
      "expected_output": "A roadmap that promotes the slowest entry route to first because the target role has a code gate, with an intermediate engineering seat, a named niche, and portfolio weighting toward code and developer-voice evidence.",
      "files": [],
      "expectations": [
        "Promotes the learn-to-code-first route above the default efficiency order rather than leaving it ranked last",
        "Names the product-focused target role as the reason that route is promoted",
        "States that no volume of content or community work substitutes for the recent engineering background these roles screen for",
        "Names the three-year runway and the absence of a deadline as the inputs that promote the slow route",
        "Distinguishes outreach-focused advocate from product-focused advocate and confirms the user is targeting the product-focused variant",
        "Includes an intermediate paid engineering or QA seat as a step on the route rather than going from self-taught code straight to advocate",
        "Says this route reaches a first role in years rather than promising a faster timeline",
        "Notes that an adjacent-role sidestep from teaching would open educator or community-manager roles, not the product-focused role the user wants",
        "Weights code in public and a developer-voice artefact as the heaviest portfolio signals for this target",
        "Requires a single named technology niche rather than databases in general or everything",
        "Does not recommend a developer relations certification or credential as a step",
        "Sets a dated review point with a change-of-course condition"
      ]
    },
    {
      "id": 3,
      "prompt": "Can you look over my DevRel resume? I'm targeting developer advocate roles at observability vendors, the speaking-and-content flavour of the job. Here's the text of it:\n\n'Passionate technologist and community builder. 22,000 followers on X. Wrote many blog posts about Kubernetes and observability. Ghostwrote a guest post for a vendor's engineering blog, published under their CTO's name. Deep-dive piece on OpenTelemetry sampling (Medium, members-only). Gave lightning talks at two local meetups, both recorded. Moderator of a 4,000-member Discord for a tracing project. Grew community engagement 300%. Available for speaking engagements and podcast appearances.'\n\nI mainly want it tuned so it gets past the screening software at the bigger vendors.",
      "expected_output": "A six-signal scored audit weighted for an outreach advocate, with explicit deductions named, the applicant-tracking request refused, the missing developer-voice artefact flagged, and at least one line rewritten outcome-first with a link.",
      "files": [],
      "expectations": [
        "Scores the portfolio against six named signals: public writing, public speaking, code in public, community evidence, teaching artefact, and developer-voice artefact",
        "Uses a 0-3 scale per signal where 0 is absent, 1 is claimed but unevidenced, 2 is evidenced, and 3 is evidenced with an outcome",
        "Weights public writing and public speaking heaviest because the target is an outreach-focused advocate",
        "Scores the unlinked blog-post claim as absent or unevidenced rather than crediting it",
        "Names the 22,000 follower count as a deduction or negative signal rather than a strength",
        "Names the ghostwritten guest post as a negative signal, including that it cannot be defended in a conversational round",
        "Names the members-only or paywalled piece as a negative signal",
        "Names the unsourced 300% figure as an exaggerated or undefendable metric and a deduction",
        "Notes that 'available for speaking engagements' does not count as speaking evidence while a delivered talk does",
        "Credits the two recorded lightning talks as delivered talks",
        "Identifies the missing developer-voice artefact, such as a published friction log, as the biggest single gap",
        "Refuses to optimise the resume for applicant-tracking-system keywords, and says this field hires on public work and referrals instead",
        "Gives a total score and places it in a readiness band rather than only listing fixes",
        "Rewrites at least one resume line so it leads with the outcome and carries a link"
      ]
    },
    {
      "id": 4,
      "prompt": "Three years next month as a developer advocate at Karrowin, a 200-person data-pipeline tooling company. I'm the longest-serving person on a team of four. This year I published 14 blog posts, spoke at 6 conferences, our Discord went from 1,200 to 3,900 members, and I ran our booth at two big events. My manager asked me to write up a case for senior before the review cycle closes in five weeks. Help me draft it. My angle is that I've earned it on output alone and I'll pick up the strategy side fast once I'm in the seat.",
      "expected_output": "A promotion case rebuilt from activity counts into two or three evidenced behaviour claims mapped to the ladder dimensions, with tenure and potential arguments removed and one honest gap named.",
      "files": [],
      "expectations": [
        "States that in developer relations promotion recognises work already performed at the next level and is not awarded for potential",
        "Removes or reframes the 'I'll pick up the strategy side once I'm in the seat' argument rather than keeping it in the case",
        "Removes or reframes tenure and longest-serving status as an argument",
        "Names the five ladder dimensions: independence, competence, collaboration, execution, strategic influence",
        "Maps the case to the senior rung defined as improving processes and systems, collaborating org-wide, and factoring company strategy into planning",
        "Says counts of posts, talks and members measure activity rather than the behaviours a level is judged on",
        "Converts at least one of the user's activity counts into an outcome claim tied to a named dimension",
        "Recommends two or three evidenced claims rather than a long list of everything done that year",
        "Requires an artefact or link behind each claim",
        "Recommends naming one honest remaining gap with a plan rather than presenting an unbroken case",
        "Asks whether the employer publishes a written career matrix, and says the absence of one is itself information",
        "Recommends keeping a running evidence log, noting that most developer relations work happens outside a manager's line of sight",
        "Does not build the headline of the case on Discord membership growth"
      ]
    },
    {
      "id": 5,
      "prompt": "Found this posting at a Series A company called Quillmark and I'm tempted. 'Developer Advocate I. Requirements: 8+ years professional software engineering across at least four of Go, Rust, Java, TypeScript, Python; demonstrated open-source maintainership; published technical writing portfolio; experience building and moderating developer communities; experience organising conferences and meetups; comfortable with video production and social media management. Salary range $58,000 to $66,000. Reports into Growth Marketing.' Should I tune my CV to hit all those bullets?",
      "expected_output": "A read of the posting that names it as a gatekeeper, lists the three symptoms and their root cause, supplies counter-questions for the loop, and gives an explicit apply-or-skip call instead of CV tuning.",
      "files": [],
      "expectations": [
        "Names this as a gatekeeper posting, using that term",
        "Describes a gatekeeper as a posting that describes an impossible person advertised at entry level and entry pay",
        "Points at the mismatch between the 'Developer Advocate I' title, the $58,000 to $66,000 band, and the eight-plus-years multi-stack requirement",
        "Names the symptom that the posting emphasises skills that are not core to communicating with developers",
        "Names the symptom that the posting is a laundry list of tactics with no statement of the outcomes they serve",
        "Names the symptom that the levelling is inconsistent",
        "States the root cause as a company that does not understand developer relations, and frames it as a working-conditions risk rather than only a hiring-process quirk",
        "Declines to answer by simply tuning the CV to the bullet list",
        "Supplies counter-questions to put to the loop, including what success looks like in twelve months and who measures it",
        "Notes that the Growth Marketing reporting line predicts leads and engagement as the metric",
        "Gives an explicit apply-or-skip call rather than leaving the decision open"
      ]
    },
    {
      "id": 6,
      "prompt": "I got approached for 'Founding Developer Advocate' at Nembridge, a 14-person seed-stage API company. The pitch: no DevRel background required, ground-floor ownership, you'd own the docs, the SDKs, the community, developer support, sales engineering calls and customer training, and they'll give me the title Head of Developer Relations. I'd be the only one doing any of it. Compared to my current mid-level advocate job this feels like an enormous step up. What do you think?",
      "expected_output": "A read that names the posting as a pit trap, treats the 'head of' title as unlevelled, and lists the founding-role diligence questions to put before any decision.",
      "files": [],
      "expectations": [
        "Names this as a pit trap, using that term",
        "Describes a pit trap as founding developer relations with ground-floor ownership of docs, SDKs, community, support, sales engineering and training on one person, with no resources, no ladder and no stated goal",
        "Treats 'Head of Developer Relations' as an unlevelled title and tells the user to ask what level it maps to internally",
        "Advises asking for a title that matches the scope before signing rather than after",
        "Names the symptom that the role is a list of tactics with no statement of the outcomes they serve",
        "States the root cause as a company that does not understand developer relations, and frames it as a working-conditions risk",
        "Asks what budget and headcount plan exist",
        "Asks what the company expects developer relations explicitly not to do",
        "Asks who the role reports to",
        "Asks whether a written career matrix exists",
        "Warns about title arbitrage, where the title says advocate but the work is a support queue or a pre-sales calendar, and says to re-score the role as the job it actually is",
        "Does not treat the founding label or the breadth of ownership as evidence of seniority on its own"
      ]
    },
    {
      "id": 7,
      "prompt": "Two offers and I have to answer by Friday. Offer A: Senior Developer Advocate at a large cloud provider, $215k base plus stock, I'd sit in an advocacy org of about 30 people, large travel budget. Offer B: Developer Advocate at Sondermere, a seed-stage API startup, $140k plus 1.2% equity on a four-year vest, I'd be their second DevRel hire. B is more exciting but A is obviously the money. Which one do I take?",
      "expected_output": "A scorecard that ranks reporting line first, coding-depth expectation second and package last, states the ordering explicitly, and flags that the same title is a different job at each company.",
      "files": [],
      "expectations": [
        "Scores the offers component by component in the order reporting line, then coding-depth expectation, then package",
        "States that ordering explicitly rather than only implying it through section order",
        "Says the package is the most negotiable component and the least decisive one",
        "Notes that most candidates negotiate hardest over the component that changes their daily job least",
        "States that the reporting line picks the metric: sales buys revenue, marketing buys leads and engagement, engineering buys signups and API use",
        "Instructs the user to ask the reporting line outright in the loop because the posting never states it",
        "Tells the user to confirm the coding-depth expectation against the work rather than the title",
        "Gives the concrete diligence question of asking what the team's last three shipped things were and who wrote them",
        "Notes that large companies level advocates on the software-engineering scale, making the engineering ladder the negotiation anchor there",
        "Does not quote an undated market salary figure as a benchmark for either offer",
        "Warns that 'senior developer advocate' is not portable between a large vendor and a seed-stage startup and means two different jobs",
        "Names the seed-stage expectations concretely, such as generalist breadth across pillars and high coding depth building the demos and the docs",
        "Names publishing rights, travel and conference budget, and the levelling scale used as parts of the package to compare, not only cash and equity",
        "Presents the result as a scorecard or comparison table with a recommendation rather than a prose essay"
      ]
    },
    {
      "id": 8,
      "prompt": "Quick one. I'm interviewing for senior developer advocate roles in Berlin, remote-friendly, at Series B-ish infrastructure companies. What number should I be asking for? Just give me a range so I don't anchor myself too low on the call tomorrow.",
      "expected_output": "A refusal to quote pay from memory, an explanation that no survey-grade dataset exists, a list of what to check with the evidence grade of each, and a redirect to the package as the real lever.",
      "files": [],
      "expectations": [
        "Declines to state a salary range from memory",
        "Says an undated pay figure is worse than no figure in a negotiation",
        "States that no survey-grade developer relations compensation dataset exists",
        "Says explicitly whether it can look up current figures, and if it cannot, says so rather than estimating",
        "Names public employer handbooks, salary-sharing threads inside developer relations communities, crowdsourced levelling sites, and devtools recruiters as what to check",
        "Distinguishes a survey with a stated respondent count from crowdsourced levelling data, and notes the latter blends advocates with adjacent engineering roles and reads as a wide directional range",
        "Requires any figure eventually used to carry its source, date, geography and grade",
        "Redirects the user to the package as the real lever: scope, title level, budget, travel policy, publishing rights, equity",
        "Notes that large companies level advocates on the software-engineering scale, making the engineering ladder the anchor there",
        "Records the unresolved pay question as an open question with who to ask, rather than closing it with a guess"
      ]
    },
    {
      "id": 9,
      "prompt": "Onsite loop at Voretti, a 120-person dev-tools company, starts a week on Monday. The recruiter just emailed asking me to record a fresh five-minute product demo video 'so the panel can see your style', unpaid, before the first round. I already have four published videos and a conference recording out there. I also have no idea what else is in the loop. Can you help me script the video, and give me some STAR answers to memorise?",
      "expected_output": "A refusal to write the unpaid sample with a decline script and a published-work counter-offer, plus format-first prep guidance, a five-story bank in three lengths, and STAR scoped to conversational rounds only.",
      "files": [],
      "expectations": [
        "Advises declining the unpaid sample video and names it as spec work",
        "States the reasoning that producing a fresh sample when the portfolio is already public is spec work under another name",
        "Offers the published equivalent plus a live working session with the team as the counter-offer",
        "Supplies a short, unapologetic decline script the user can send",
        "Does not write the demo video script as requested",
        "Tells the user to ask the recruiter which formats the loop uses before preparing anything",
        "Lists the developer relations loop formats, including presentation round, content take-home, coding take-home, technical self-rating questionnaire, conversational rounds, DevRel-opinion round, and founder or exec round",
        "Says the DevRel-opinion round is reported as the hardest because it has no right answer to memorise",
        "Restricts STAR to the conversational and behavioural rounds and says it is the wrong shape for the DevRel-opinion round",
        "Tells the user to bank five stories, each prepared in three lengths: roughly two minutes, sixty seconds, and one line",
        "Names developer-relations-specific story topics rather than a generic competency list, such as developer feedback carried into a shipped product decision, a community conflict handled, and work shipped with a team that did not report to the user",
        "Says to keep only numbers the user can defend under a follow-up question",
        "Tells the user to treat the loop as two-way and evaluate the employer during it, naming pillar mix, funding driver, reporting line and budget",
        "Advises rating honestly on any technical self-rating questionnaire, because inflated self-ratings unravel in the next round"
      ]
    },
    {
      "id": 10,
      "prompt": "Presentation round is Thursday and it's Monday night. Forty-five minutes in front of the panel at Grendal Systems. My plan was to write a completely new talk built on their platform and run the whole thing as a live demo against their staging API, which goes down roughly once a day from what I've seen. Sound good?",
      "expected_output": "A corrected plan: reuse an existing talk, two timed rehearsals, and a demo engineered with checkpoints, a reset path and a recorded fallback, laid out against the Monday-to-Thursday window.",
      "files": [],
      "expectations": [
        "Advises reusing and adapting an existing talk rather than writing a new one for the round",
        "Requires at least two full timed rehearsals out loud",
        "Requires a recorded fallback of the demo",
        "Requires independently enterable checkpoints so the demo can be resumed after a failure",
        "Requires a reset path for the demo environment",
        "Names the flaky staging API as the specific risk driving the fallback plan",
        "Gives a day-by-day rehearsal plan anchored to the Monday-to-Thursday window",
        "Includes recording a run and watching it back, fixing only the worst couple of moments",
        "Tells the user to bring one question they genuinely want answered",
        "Tells the user to confirm with the recruiter which other formats the loop contains"
      ]
    },
    {
      "id": 11,
      "prompt": "Six years as a senior developer advocate at a large cloud vendor. I've accepted an offer at Tavolino, a 40-person startup whose product is self-serve: individual developers sign up with a card, teams expand later, and sales only gets involved once an account is large. I'm quietly terrified that six years of my experience is worthless there. What actually carries over and what do I have to relearn?",
      "expected_output": "A transfer analysis split on go-to-market motion, stating the craft transfers unchanged and the metric definition is the relearning, plus a PLG competency row added alongside the five ladder dimensions.",
      "files": [],
      "expectations": [
        "States that the craft transfers unchanged, naming writing, speaking, teaching, demo building, friction logging, community facilitation and carrying developer feedback into the company",
        "States that the relearning is which metric the company accepts as proof of impact",
        "Uses go-to-market motion as the comparison axis rather than buyer type or a business-to-business versus business-to-consumer split",
        "Identifies the new company as product-led from the self-serve signup and later team expansion described",
        "Names product-led measurement as activation, expansion revenue, product-qualified-lead volume and product feedback loops",
        "Contrasts that with the large-vendor measurement of attribution and product influence",
        "Warns that 'senior developer advocate' is not portable across company types and means a different job at the startup",
        "Adds a product-led competency gap row covering product-usage evidence, product-qualified-lead scoring, expansion playbooks and developer-to-champion conversion",
        "States that the product-led row sits alongside the five existing dimensions rather than replacing them",
        "Names the shift in the politics-to-output ratio between a big-tech seat and a startup seat",
        "Notes that the reporting line at a product-led company is often engineering or product",
        "Does not frame the move primarily as a pay or equity trade-off"
      ]
    },
    {
      "id": 12,
      "prompt": "We're a 60-person API company and I'm the VP Engineering. We've never had developer relations. I need to write the job posting for our first developer advocate, work out what the interview loop should be, and figure out how to score the candidates' portfolios when they come in. Where do we start?",
      "expected_output": "A one-line statement that this is the candidate-side skill, a pointer to the employer-side and org-design siblings, and no posting, loop or scorecard produced.",
      "files": [],
      "expectations": [
        "States in about one line that this skill is written for the person being evaluated, not for the hiring side",
        "Points the user at samber/developer-relations-skills@devrel-hiring for the posting, the loop and portfolio scoring",
        "Points the user at samber/developer-relations-skills@devrel-team-structure for where the role sits in the org and which function it reports to",
        "Does not produce a job posting",
        "Does not design an interview loop or a hiring scorecard",
        "Does not run a candidate-side portfolio audit or career roadmap",
        "Keeps the handoff brief rather than delivering a full deliverable before redirecting"
      ]
    },
    {
      "id": 13,
      "prompt": "Two years into an advocate job at Melbrook. I want to be in the top tier of this field within a couple of years and I've written out my plan: build a personal brand, post something every single day on X and LinkedIn, get the follower count up, and stop over-rehearsing my talks. I want that effortless Kelsey Hightower thing where it looks completely off the cuff. Most of my audience lives in our company Slack community, which I run. Sanity-check this for me.",
      "expected_output": "A correction of the personal-brand and unrehearsed-style assumptions, the four top-practitioner habits ranked by efficiency with the ranking stated, and the company Slack ruled out as owned distribution.",
      "files": [],
      "expectations": [
        "States that 'build a personal brand' is mostly wrong advice in this field and that follower count without substance is an explicit negative signal to hiring managers",
        "States that great developer relations centres the developer, not the advocate",
        "Identifies the Kelsey Hightower plan as survivorship-biased",
        "Explains that those talks are built from hundreds of micro-demos rehearsed individually over years, then played like an instrument",
        "Warns that copying 'don't rehearse' without that library fails live",
        "Names the four recurring top-practitioner habits: converting audience signal into internal influence, owning the distribution, treating CFP rejection as iteration, and running consistency as a system",
        "Ranks those four by efficiency, leading with internal influence and then owning the distribution",
        "States the ranking out loud rather than implying it through the order of the list",
        "Says a company Slack or Discord is a walled garden and does not count as owned or public distribution",
        "Notes that only distribution ownership survives leaving the employer, while internal influence stays with the company",
        "Names carrying developer evidence into product decisions as the way to clear the ceiling where developer relations speaks most with customers but holds the least power to act on what it hears",
        "Advises asking for feedback on rejected CFPs and rehearsing at meetups before conferences",
        "Names devrel-company fit as something to weight heavily, and says a strong practitioner in the wrong product, audience or reporting line still underperforms"
      ]
    },
    {
      "id": 14,
      "prompt": "Starting from zero here. I'm a QA analyst at Pendrel Health and I want to move into developer relations this year. Two questions. First, which DevRel certification is worth paying for? I keep seeing courses advertising one. Second, I was going to kick things off by submitting to three big conference CFPs next month, since talks seem to be the thing that actually counts. Sound right?",
      "expected_output": "A plain statement that no recognised certification exists, plus the ranked first-artefact sequence starting with a friction log, a niche picked from a tool the user already uses, and meetups before conference CFPs.",
      "files": [],
      "expectations": [
        "States plainly that no recognised developer relations certification exists",
        "Declines to recommend a paid course that implies a credential",
        "Notes that foundation-adjacent technical certifications raise credibility only inside a specific niche such as cloud-native, and only if that is the chosen niche",
        "Ranks the first artefacts by return per day of the user's own work, leading with a friction log",
        "Gives the full order: friction log, blog post, community-answer streak, open-source contribution, meetup talk",
        "States that the meetup talk carries the highest value of the five while losing every efficiency round, and names the condition that promotes it anyway",
        "Recommends a meetup or lightning talk as the rehearsal ground before conference CFPs, rather than opening with three big conference submissions",
        "Requires picking one tool or product the user already uses as the niche before producing artefacts",
        "Notes that a five-minute lightning talk counts toward the published hiring bar of a couple of talks given",
        "States an expectation of roughly six to twelve months of consistent public output before becoming hireable",
        "Names the zero-experience-to-artefacts threshold concretely, such as three substantial posts published and one talk delivered"
      ]
    },
    {
      "id": 15,
      "prompt": "I'm a staff-level developer advocate, five years in. My company just offered me 'Head of Developer Relations'. I'd manage one person and inherit the events budget. Same base salary, small title bump. Everybody is congratulating me, but I like building things and I'm not convinced this is actually a promotion. Take it?",
      "expected_output": "An unlevelled-title read with the question to ask internally, the two tracks described without ranking one above the other, and the artefact-compounding move named as the IC leverage.",
      "files": [],
      "expectations": [
        "Treats 'head of' as an unlevelled title and tells the user to ask what level it maps to internally",
        "Advises asking for the title to match the scope, up to director, if the scope is a director's",
        "Refuses to rank the IC track above the management track or the reverse, and says the choice turns on scope preference rather than status",
        "Describes the IC track as raising the strategic share of the work while still executing, with bigger initiatives and cross-org influence at staff and principal",
        "Describes the management track as trading execution for coordination, starting with people management and team goals",
        "Names what a director owns beyond a first-line manager, such as department strategy, metrics, operations, budget, cross-functional relationships and the career ladder itself",
        "Names making each artefact compound as the IC leverage move that reads as senior on either track",
        "Lists concrete downstream uses of one sample app, such as a talk, a conference delivery, a blog post, a video, a social series, a newsletter item, sales enablement and a meetup kit",
        "States that seniority is judged by how far one piece of work travels, not by how many pieces get made",
        "Does not treat managing one person as evidence on its own that the role is a promotion",
        "Names the reporting line and the budget and headcount plan as things to confirm before accepting"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "how do I break into developer relations", "should_trigger": true },
    { "query": "I want to become a developer advocate, where do I start", "should_trigger": true },
    { "query": "should I take this advocate job", "should_trigger": true },
    { "query": "audit my DevRel portfolio", "should_trigger": true },
    { "query": "review my resume for developer advocate roles", "should_trigger": true },
    { "query": "I have a presentation round at a devtools startup on Thursday, how do I prep", "should_trigger": true },
    { "query": "three years as an advocate, how do I make senior", "should_trigger": true },
    { "query": "is this developer advocate posting worth applying to", "should_trigger": true },
    { "query": "I have two DevRel offers, help me choose", "should_trigger": true },
    { "query": "developer advocate or developer evangelist, which should I be targeting", "should_trigger": true },
    { "query": "what does a DevRel portfolio actually need in it", "should_trigger": true },
    { "query": "how do I get promoted from mid-level to senior developer advocate", "should_trigger": true },
    { "query": "help me write my promotion case for senior developer advocate", "should_trigger": true },
    { "query": "I'm a backend engineer who wants to get paid to write tutorials and speak, how", "should_trigger": true },
    { "query": "what do I have to show a company to prove I can do developer advocacy", "should_trigger": true },
    { "query": "they want me to record a free sample video before the first round, is that normal", "should_trigger": true },
    { "query": "what's actually in a developer advocate interview loop", "should_trigger": true },
    { "query": "how do I prepare for a DevRel opinion round", "should_trigger": true },
    { "query": "is there a certification for developer relations", "should_trigger": true },
    { "query": "how long does it take to get hired into DevRel from zero", "should_trigger": true },
    { "query": "what should I ask for as a senior developer advocate salary", "should_trigger": true },
    { "query": "this job ad wants eight years of engineering at entry-level pay, is that normal", "should_trigger": true },
    { "query": "founding developer advocate at a seed startup, should I take it", "should_trigger": true },
    { "query": "I'm a technical writer, can I move into DevRel", "should_trigger": true },
    { "query": "I'm in support and I want out, is developer relations realistic for me", "should_trigger": true },
    { "query": "IC or management for my next DevRel step", "should_trigger": true },
    { "query": "they offered me head of developer relations, is that a promotion", "should_trigger": true },
    { "query": "what's the developer relations career ladder", "should_trigger": true },
    { "query": "which DevRel role suits someone who can't really code", "should_trigger": true },
    { "query": "my DevRel applications go nowhere, what am I missing", "should_trigger": true },
    { "query": "how do I pick a niche for developer advocacy", "should_trigger": true },
    { "query": "what separates the best developer advocates from the average ones", "should_trigger": true },
    { "query": "is building a personal brand the way into DevRel", "should_trigger": true },
    { "query": "moving from a big cloud vendor to a startup advocate role, what changes", "should_trigger": true },
    { "query": "do I need to code to be a developer advocate", "should_trigger": true },
    { "query": "I want to publish a friction log as a work sample, how do I structure it", "should_trigger": true },
    { "query": "what questions should I be asking the interviewer for an advocate role", "should_trigger": true },
    { "query": "does it matter who developer relations reports to if I take the job", "should_trigger": true },
    { "query": "should I accept a DevRel offer that reports into sales", "should_trigger": true },
    { "query": "how do I evaluate a DevRel employer while I'm interviewing", "should_trigger": true },
    { "query": "my current employer has no DevRel team, how do I switch into it", "should_trigger": true },
    { "query": "career change into developer relations at 40", "should_trigger": true },
    { "query": "what's the difference between a community manager job and a developer advocate job", "should_trigger": true },
    { "query": "how many talks do I need before I can apply for advocate roles", "should_trigger": true },
    { "query": "I got rejected from six advocate roles, what should I change", "should_trigger": true },
    { "query": "how do I go from meetup talks to a paid DevRel job", "should_trigger": true },
    { "query": "is a DX engineer role the same thing as developer advocate", "should_trigger": true },
    { "query": "what does a staff level developer advocate actually do", "should_trigger": true },
    { "query": "planning my next two years in developer relations", "should_trigger": true },
    { "query": "help me choose between community manager and developer educator", "should_trigger": true },
    { "query": "developer educator roles, what do they screen for", "should_trigger": true },
    { "query": "how do I show impact on a DevRel resume instead of just listing output", "should_trigger": true },
    { "query": "my resume is all \"wrote blog posts\", how do I make it stronger", "should_trigger": true },
    { "query": "interview next week for a developer advocate job, prep me", "should_trigger": true },
    { "query": "what stories should I have ready for a DevRel interview", "should_trigger": true },
    { "query": "how do I answer \"how would you measure your work\" in a DevRel interview", "should_trigger": true },
    { "query": "should I do the unpaid take-home they asked me for", "should_trigger": true },
    { "query": "is this title actually senior or are they overselling it", "should_trigger": true },
    { "query": "I want to work in developer relations at a database company", "should_trigger": true },
    { "query": "moving from teaching into developer relations", "should_trigger": true },
    { "query": "how do I know when I'm ready to apply for DevRel roles", "should_trigger": true },
    { "query": "what's a realistic first DevRel role with two years of engineering behind me", "should_trigger": true },
    { "query": "am I ready to apply for developer advocate jobs yet", "should_trigger": true },
    { "query": "the posting lists twenty responsibilities and no goals, is that a red flag", "should_trigger": true },
    { "query": "how do advocates get levelled at big tech companies", "should_trigger": true },
    { "query": "DevRel burnout keeps coming up, should I still go into this field", "should_trigger": true },
    { "query": "how do I build a developer relations career that survives changing employers", "should_trigger": true },
    { "query": "what should I negotiate besides salary for an advocate role", "should_trigger": true },
    { "query": "they call it advocate but the interview sounded like a support queue, what do I do", "should_trigger": true },
    { "query": "how do I build a body of public work that gets me hired", "should_trigger": true },
    { "query": "what's the fastest path into DevRel from an engineering job", "should_trigger": true },
    { "query": "I have a content take-home for a developer advocate role, how should I approach it", "should_trigger": true },
    { "query": "two offers: more money at a big company, more scope at a startup", "should_trigger": true },
    { "query": "how do I get feedback on why I keep getting rejected for DevRel roles", "should_trigger": true },
    { "query": "how do I choose between an outreach advocate role and a product-focused one", "should_trigger": true },
    { "query": "do foundation ambassador programs pay anything", "should_trigger": true },
    { "query": "is being a CNCF ambassador a career move or just a hobby", "should_trigger": true },
    { "query": "my manager says level up by giving more talks, is that right", "should_trigger": true },
    { "query": "what evidence do I need for a developer relations promotion", "should_trigger": true },
    { "query": "how do I position nine years of teaching for a DevRel application", "should_trigger": true },
    { "query": "the recruiter won't tell me who the role reports to, does that matter", "should_trigger": true },
    { "query": "write a job description for our first developer advocate", "should_trigger": false },
    { "query": "design the interview loop for a developer advocate hire", "should_trigger": false },
    { "query": "build a scorecard for our DevRel candidates", "should_trigger": false },
    { "query": "how do we score candidate portfolios when we're hiring advocates", "should_trigger": false },
    { "query": "what red flags should we look for when interviewing developer advocates", "should_trigger": false },
    { "query": "where do we source developer advocate candidates from", "should_trigger": false },
    { "query": "write a paid work sample brief for our advocate interview", "should_trigger": false },
    { "query": "how long should the ramp plan be for a new developer advocate we just hired", "should_trigger": false },
    { "query": "should our first DevRel hire be a generalist or a specialist", "should_trigger": false },
    { "query": "draft interview questions for the community manager we're hiring", "should_trigger": false },
    { "query": "our advocate candidates all look the same on paper, how do we differentiate them", "should_trigger": false },
    { "query": "write the outcome-based requirements for a DevRel engineer opening", "should_trigger": false },
    { "query": "should our DevRel team report to marketing or engineering", "should_trigger": false },
    { "query": "how do we structure a six-person developer relations org", "should_trigger": false },
    { "query": "centralized or embedded DevRel, which shape do we pick", "should_trigger": false },
    { "query": "do we need a dedicated community manager seat on the team", "should_trigger": false },
    { "query": "how should DevRel interlock with product marketing", "should_trigger": false },
    { "query": "build a DevRel measurement framework for our program", "should_trigger": false },
    { "query": "what metrics should I show our CFO to justify the DevRel spend", "should_trigger": false },
    { "query": "how should we split our DevRel budget across events and content", "should_trigger": false },
    { "query": "design our developer relations program from scratch", "should_trigger": false },
    { "query": "set up event tracking across our docs and repositories", "should_trigger": false },
    { "query": "which of our DevRel metrics are vanity metrics", "should_trigger": false },
    { "query": "which DevRel podcasts and newsletters should I follow", "should_trigger": false },
    { "query": "build me a watch list of developer relations information sources", "should_trigger": false },
    { "query": "which DevRel conferences should I keep an eye on this year", "should_trigger": false },
    { "query": "help me write a CFP abstract for KubeCon", "should_trigger": false },
    { "query": "which conferences should I submit this talk to", "should_trigger": false },
    { "query": "turn my accepted abstract into a slide outline", "should_trigger": false },
    { "query": "my live demo keeps breaking on stage, make it safe", "should_trigger": false },
    { "query": "write a script for a five-minute screencast about our SDK", "should_trigger": false },
    { "query": "I'm going on a podcast next week, prep me for the questions", "should_trigger": false },
    { "query": "rewrite my talk title so it gets picked out of the pile", "should_trigger": false },
    { "query": "edit this engineering blog post before we publish it", "should_trigger": false },
    { "query": "write a technical blog post about our Postgres migration", "should_trigger": false },
    { "query": "write the changelog for our 3.0 release", "should_trigger": false },
    { "query": "audit our quickstart guide", "should_trigger": false },
    { "query": "write a tutorial for our new SDK", "should_trigger": false },
    { "query": "our troubleshooting docs are a mess, fix the structure", "should_trigger": false },
    { "query": "write a migration guide for the breaking change in v4", "should_trigger": false },
    { "query": "optimize my GitHub profile README", "should_trigger": false },
    { "query": "which six repositories should I pin on my profile", "should_trigger": false },
    { "query": "rewrite our project README so people actually try it", "should_trigger": false },
    { "query": "how do we attract senior engineers to our company", "should_trigger": false },
    { "query": "build our engineering employer brand strategy", "should_trigger": false },
    { "query": "should we publish our compensation bands to attract developers", "should_trigger": false },
    { "query": "should we start a Discord for our users", "should_trigger": false },
    { "query": "write our community code of conduct", "should_trigger": false },
    { "query": "design an ambassador program for our power users", "should_trigger": false },
    { "query": "how do we measure the health of our developer community", "should_trigger": false },
    { "query": "how do we moderate a hostile thread in our forum", "should_trigger": false },
    { "query": "plan a recurring developer meetup for our city", "should_trigger": false },
    { "query": "which open source license should we pick", "should_trigger": false },
    { "query": "should we open source our scheduler", "should_trigger": false },
    { "query": "design our contributor onboarding path", "should_trigger": false },
    { "query": "plan the launch of our open source project", "should_trigger": false },
    { "query": "how should we price our developer tool", "should_trigger": false },
    { "query": "which business model fits our open core product", "should_trigger": false },
    { "query": "run my resume through an ATS keyword check for a backend engineering role", "should_trigger": false },
    { "query": "tailor my resume to this product manager job description", "should_trigger": false },
    { "query": "format my resume into a clean one-page PDF", "should_trigger": false },
    { "query": "quantify the bullets on my sales resume", "should_trigger": false },
    { "query": "write an executive resume for a CFO candidate", "should_trigger": false },
    { "query": "behavioural interview prep for a big tech software engineering loop", "should_trigger": false },
    { "query": "help me prepare for a distributed systems design interview", "should_trigger": false },
    { "query": "negotiate my backend engineering offer", "should_trigger": false },
    { "query": "how do I get promoted to staff software engineer", "should_trigger": false },
    { "query": "should I switch from backend to frontend engineering", "should_trigger": false },
    { "query": "how do I become a technical writer", "should_trigger": false },
    { "query": "how do I move from engineering into product management", "should_trigger": false },
    { "query": "what does a solutions architect actually do all day", "should_trigger": false },
    { "query": "career advice for a data scientist two years in", "should_trigger": false },
    { "query": "write a LinkedIn headline for a sales director", "should_trigger": false },
    { "query": "interview prep for a customer success manager role", "should_trigger": false },
    { "query": "how do I become an engineering manager", "should_trigger": false },
    { "query": "build a 30-60-90 day plan for my new SRE job", "should_trigger": false },
    { "query": "analyse this DevOps job description and tell me if I qualify", "should_trigger": false },
    { "query": "write a cover letter for a marketing coordinator position", "should_trigger": false },
    { "query": "mock interview me for a frontend role", "should_trigger": false },
    { "query": "how should I answer \"what's your greatest weakness\"", "should_trigger": false },
    { "query": "review my portfolio site as a UX designer", "should_trigger": false }
  ]
}

# Entry curriculum: zero to hireable

Contents: months 0-1 · the ranked first artefacts · months 3-6 · certifications · the internal-transfer path · realistic timeline and stage thresholds.

For candidates with no DevRel title yet. Build the artefacts first - they are the application - then learn the field's norms inside its communities, then apply. Alex Lakatos: "It's easier to get your first job in Developer Relations for a company when you've already got some domain knowledge."

## Months 0-1: orient and pick the niche

Read the field's two entry texts: Mary Thengvall's _The Business Value of Developer Relations_ (Apress, 2018), the first published book on the practice, and Sam Julien's free ebook _Getting Started in Developer Relations_ with his "How to Start Doing Dev Rel Right Now".

Pick one tool or product you already use and like - Julien's first step is literally "Pick a tool or SaaS product that you absolutely love". The niche is what everything else compounds on, and picking a product you use means the first artefacts come from real usage instead of research.

Follow the field while you work: DevRel Weekly, the `devrelcollective/awesome-devrel` repository, the Community Pulse podcast.

## Months 1-3: the first artefacts, ranked

Rank by return per day of your own work. **Efficiency:** friction log > blog post > community-answer streak > open-source contribution > meetup talk. Together they cover the evidence types a portfolio audit scores, so the order is what to ship first, not what to skip.

- **effort** (days of your own work, plus who else has to say yes): meetup talk > open-source contribution > community-answer streak > blog post == friction log. The tie: both are a few days of solo writing on a channel you control, gated on nobody's approval.
- **value** (the hiring signal each one evidences): meetup talk > friction log > blog post > open-source contribution == community-answer streak. The tie: both prove you can operate inside someone else's project, and both read as ongoing participation rather than as a standalone artefact.

1. **A friction log on the chosen tool.** A few days' work, and it evidences the rarest portfolio signal - carrying the developer's experience back to the company.
2. **A blog post or tutorial on that tool.** Proves you can explain clearly; the cheapest artefact to produce.
3. **A community-answer streak** in the tool's forum, chat or issue tracker. Low intensity over weeks, and it produces the "developers I've helped" answer an interview will ask for.
4. **An open-source contribution to that tool's project.** Documentation contributions count fully. A maintainer has to review it, so the pace is not yours.
5. **A meetup talk.** The rehearsal ground for conferences; a five-minute lightning slot counts.

**What this order starves:** the meetup talk loses every ratio round - most effort, and gated on an organiser's calendar - yet it carries the highest value of the five and is the only item clearing Leggetter's published hiring bar. Promote it to first whenever the loop being prepared for has a presentation round, or the target is an outreach-focused advocate role, where writing and speaking are the two heaviest signals.

Delete rather than demote. A publishing policy blocking a friction log on a product used at work means picking a different product, not sliding the friction log down the list. No local meetup scene and no travel budget means dropping the talk for a recorded video - the same signal, no organiser required.

## Months 3-6: scale and formalise

Add a recorded video or stream, and submit a first conference CFP expecting rejection - the practitioners who speak most treat rejection as iteration (Zakharenko, quoted in the skill body).

Join the communities where roles circulate before they reach job boards:

- the DevRel Collective Slack (application-gated, "for active, practicing DevRel Professionals")
- Write the Docs Slack (open)
- CMX for community-management practice

Courses worth the time, all optional:

- Google's free Technical Writing courses
- Sam Julien's material
- Tessa Kriesel's developer-advocacy programs

## Certifications: there are none

No recognised DevRel certification exists - say so plainly rather than pointing someone at a paid course that implies one. Google's Technical Writing courses issue no credential either. Foundation-adjacent technical certifications (Linux Foundation and CNCF, for example CKA) do raise credibility inside the cloud-native niche specifically, and are worth it only if that is the chosen niche.

## The internal-transfer path

Many DevRel hires never run this curriculum. Iregbulem's practitioner interviews found companies "hire most of the DevRel team internally", because engineers "realized they could make an impact much sooner as DevRel than as engineers". Do the work visibly from the current seat - the docs page, the internal talk, the friction log - then ask for the transfer.

## Timeline and stage thresholds

Expect 6-12 months of consistent public output to become hireable, longer in a saturated candidate market. Two thresholds mark the transitions:

- **Zero experience → artefacts.** Three substantial posts published and one talk delivered. Below that, more applications will not help; more artefacts will.
- **Artefacts → job.** One conference CFP accepted, or one owned distribution channel with recurring engagement. At this point the constraint has moved from production to targeting and network, and effort should move with it.

# Interview prep playbook

Contents: the formats and how to prepare each · the story bank · question bank with answer shapes · employer diligence questions · offer traps and the decline script · rehearsal plan.

Sources: practitioner accounts of real DevRel loops (Carly Richmond on interviewing at several companies; Aditya Oberai's reported Appwrite loop; Phil Leggetter as a hiring manager), plus the published DevRel hiring research on rubrics.

## Formats and preparation

| Format                                        | What it tests                                                                               | Preparation                                                                                                                                                                |
| --------------------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Presentation round - give a talk to the panel | the core public artefact of the job: clarity, pacing, audience read, handling questions     | Reuse and adapt an existing talk rather than writing a new one. Rehearse aloud, timed, twice. Prepare for the demo to fail: checkpoints, a recorded fallback, a reset path |
| Content take-home - a post or a video         | writing that a developer would trust: shows the code, admits trade-offs, no marketing voice | Time-box it and say so in the deliverable. Publish it publicly afterwards if the brief allows - the work becomes portfolio either way                                      |
| Coding take-home                              | that you can build what you will advocate                                                   | Treat it as an engineering take-home, then add the DevRel layer: a README that onboards a stranger, and a note on what confused you                                        |
| Technical questionnaire / self-rating         | breadth calibration and honesty                                                             | Rate honestly and add one line of evidence per high rating. Inflated self-ratings unravel in the next round                                                                |
| Conversational rounds                         | technology, communities, and your experience                                                | Prepare three artefact stories in three lengths (two minutes, sixty seconds, one line)                                                                                     |
| DevRel-opinion round                          | your model of the practice itself - reported as the hardest round                           | Have a defensible position on what DevRel is for, how you would measure it, and where you would say no. See the bank below                                                 |
| Founder / exec round                          | commercial understanding and culture fit                                                    | Be able to connect your work to revenue or adoption without pretending DevRel is sales                                                                                     |

There is no standard loop. One candidate applying to several companies met coding take-homes, presentation rounds, content take-homes and pure conversations - for the same job title. Ask the recruiter which formats they use before preparing.

One reported loop ran:

1. application
2. one to two weeks' wait
3. introductory call
4. self-rated technical questionnaire
5. technical plus DevRel-opinion interview
6. founder call, no project task

The candidate rated it good because it treated them as a person rather than a checkbox - read that signal in reverse when a process does the opposite.

## The story bank

Bank stories before the loop: nobody improvises a good one under pressure. Use STAR for the conversational and behavioural rounds only - it is the wrong shape for the DevRel-opinion round, which tests a position rather than a memory.

- Situation (1-2 sentences)
- Task (1 sentence)
- Action (2-3 sentences, what _you_ did)
- Result (1-2 sentences, with the outcome)

Prepare each story in three lengths: two minutes for "tell me about a time…", sixty seconds for a follow-up, one line for "give me an example". Cover five DevRel-specific situations rather than the generic competency list:

1. Developer feedback you carried into a product decision that shipped.
2. Content or a demo whose outcome you can state, and what you would redo.
3. A community conflict or a hostile thread you handled.
4. Something you shipped with a team that did not report to you.
5. A piece of your own work that failed publicly, and what changed after.

Two rules keep the bank credible:

- Lead with the outcome and let the process follow - the interviewer is testing whether you think in impact.
- Keep the numbers you can defend - a figure you cannot source in the follow-up question costs more than having no figure.

## Question bank with answer shapes

### On the practice

- _"What is developer relations for, at a company like ours?"_ - Name the driver you believe funds it here (adoption, sales enablement, enablement, product input, ecosystem, contributor community, employer branding), then the pillar mix that follows. Ask whether that matches their intent.
- _"How would you measure your work?"_ - Separate leading activity from outcomes, state what you would refuse to be measured on (raw follower counts), and name the honest attribution limits. Confidence about limits reads as senior; certainty about attribution reads as junior.
- _"What would you do in your first 90 days?"_ - Learn the product as a user (a friction log is a concrete answer), meet the developers already using it, find the top three points where they get stuck, and ship one visible artefact. Avoid promising a conference calendar.
- _"How is DevRel different from marketing / sales engineering / support?"_ - One-to-many leverage: a sales engineer helps one account, an advocate builds the artefact that helps a thousand developers. Say it without disparaging the other functions; you will need them.
- _"Tell me about a time you carried developer feedback into a product decision."_ - The question behind the question is whether you are a broadcaster or a bridge. Have one story with a named change that shipped.

### On craft

- _"Walk me through a piece of content you are proud of, and what it changed."_ - Outcome first, then process, then what you would redo.
- _"A tutorial you wrote is now wrong after a release. What happens?"_ - Ownership and maintenance instincts; mention how you would know it broke.
- _"Our docs are bad and engineering has no time. What do you do?"_ - Prioritise by developer pain, fix the top path yourself, make the fix reproducible, and negotiate ownership rather than absorbing it silently.
- _"How would you get our developers to try X?"_ - Pick a niche and a channel, not a list of tactics. Say how you would know it worked.

### On you

- _"Why DevRel, and why now?"_ - Ground it in artefacts you already produce. The strongest version is boring and evidenced.
- _"What part of the job do you not enjoy?"_ - Answer honestly; the field's real attrition is burnout, and an interviewer who cannot handle a boundary is telling you something.

### DevRel philosophy & strategy

- How do you align Developer Relations initiatives with business goals and product roadmaps?
- Describe your approach to identifying and prioritizing developer communities (e.g., open source projects, enterprise customers, hobbyist communities).
- How do you define "success" for a DevRel program? What metrics do you track?
- How do you balance technical credibility with community engagement and outreach?
- Explain your philosophy on developer experience (DX) vs. developer happiness. How do you bridge the gap?
- How do you foster cross-functional collaboration between Engineering, Marketing, and Customer Success teams?

### Content creation & communication

- How do you create educational content (tutorials, webinars, blog posts) that balances depth with accessibility?
- Describe your process for translating complex technical concepts into digestible content for different audience segments.
- How do you ensure technical accuracy while maintaining engaging storytelling in technical content?
- Which content formats do you prioritize for different stages of the developer journey (beginner, intermediate, advanced)?
- How do you measure the effectiveness of your technical content?
- How do you develop compelling narratives around open source projects or product features?

### Community management

- How do you identify and nurture community leaders and ambassadors?
- Describe your strategy for growing a community from zero to a sustainable ecosystem.
- How do you handle toxic behavior or negative feedback within the community?
- What metrics do you use to gauge community health and engagement?
- How do you balance welcoming newcomers with maintaining community standards?
- Walk me through your experience organizing or participating in developer events (meetups, conferences, hackathons).

### Technical depth & architecture

- How do you evaluate and recommend developer tools and platforms (IDEs, CLI, documentation, CI/CD)?
- Describe your experience with developer tooling and how you integrate them into community offerings.
- How do you ensure documentation is accurate, up-to-date, and searchable?
- What strategies do you use to keep technical documentation aligned with product changes?
- How deeply do you understand the product roadmap and technical architecture?
- How do you translate product updates into community-facing communications?

### Public speaking & presentation

- How do you prepare for and deliver technical presentations to diverse audiences?
- Describe your experience presenting at conferences, webinars, or internal demos.
- How do you handle Q&A sessions and difficult technical questions?
- What techniques do you use to engage an audience with varying technical backgrounds?
- How do you practice and refine your public speaking skills?
- How do you craft a compelling narrative around a product or technical achievement?

### Metrics & measurement

- What key metrics do you track for DevRel program health?
- How do you correlate community metrics with business outcomes (e.g., retention, conversion, NPS)?
- Describe a time you used data to make a strategic decision about a DevRel initiative.
- How do you set and measure OKRs for a DevRel program?
- How do you gather qualitative feedback from the community?
- How do you balance quantitative metrics with qualitative community sentiment?

### Behavioral & situational

- Tell me about a challenging situation you faced in a DevRel role. How did you handle it?
- Describe a time you had to make a tough decision with incomplete information.
- How do you prioritize tasks when facing competing demands?
- Give an example of a time you demonstrated empathy and patience with frustrated developers.
- How do you adapt your approach when a community or product evolves rapidly?
- How do you handle ambiguity or unclear requirements in a DevRel context?

### Cultural fit & values

- What qualities make an effective Developer Relations practitioner?
- How do you embody the company's culture in community interactions?
- Describe your approach to mentoring junior developers or new team members.
- How do you stay current with developer trends and technologies?
- How do you handle situations where community feedback conflicts with company policies?
- Describe your approach to inclusive community practices (accessibility, diversity, equity).

### Scenario-based questions

- A major product delay threatens community momentum. How do you respond?
- How would you handle a viral negative incident affecting the brand?
- A key community contributor leaves the organization. How do you manage the transition?
- How would you introduce a new developer tool or platform to an existing community?
- A competing product launches a major feature. How do you adjust your strategy?
- How would you handle a request from engineering to prioritize a feature you don't believe is valuable?

## Employer diligence questions

Ask these; the answers are as decision-relevant as the offer.

- What does success look like in twelve months, and who decides?
- Which pillar mix does this role actually cover, and what would you drop first if the team shrank?
- Who does DevRel report to, and why that department?
- Is there a written career matrix and an interview rubric? Can I see the matrix?
- What is the travel expectation, and who covers it when it collides with life?
- If this is a "head of" role: what level is it internally, and can the title match the scope?
- If this is a founding role: what budget, what headcount plan, and what does the company expect DevRel to _not_ do?

## Scoring an offer

The ranked components and the axes behind the ranking are in the skill body's § Scoring an offer. Two named traps sit underneath it:

- **Title arbitrage**: the title says advocate but the interview reveals a support-ticket queue or a pre-sales calendar. Re-score the role as what it actually is.
- **The unlevelled "head of"**: ask what level it maps to internally, and ask for the title to match the scope before signing rather than after.

Decline unpaid spec-work auditions when your portfolio is already public, and offer the equivalent published piece instead. A short, unapologetic version: "I've got public work in exactly this format - here are two pieces and the brief each was written against. I'd rather walk you through those than produce a new one unpaid, but I'm happy to do a live working session with the team."

## Rehearsal plan

- **Three days out**: confirm formats with the recruiter, pick the reusable talk and the three artefact stories.
- **Two days out**: a full timed run of the presentation, out loud, recorded. Watch it once at 1.5x and fix the two worst moments only.
- **One day out**: rehearse the DevRel-opinion answers as spoken positions, not scripts, and re-read the company's docs and developer channels for the friction you will mention.
- **Day of**: the fallback recording, the links, and one question you genuinely want answered.

# Output shape template

Every deliverable is a short markdown document the user can act on the same week. Keep the skeleton below and drop sections the goal did not ask for.

```markdown
# {Portfolio audit | Skill-gap roadmap | Interview plan | Posting read | Offer scorecard}: {name}, targeting {sub-role} in {niche}

## Where you are

2-3 sentences: current seat, evidence in hand, the constraint that actually binds.

## Assessment

A table, one row per scored item - six signals, five ladder dimensions,
offer components, or posting symptoms - with score, the evidence link, and the gap.

## What to do next

3-5 steps, each with: the artefact or event that proves it, an owner-set date,
and the reason it is next rather than later.

## Review point

Date, plus the condition that means change course rather than push harder.

## Open questions

Anything you could not verify - pay figures, the reporting line, the format list -
and who to ask.
```

Never present a step whose completion cannot be observed from outside the user's head. Keep the assessment table shorter than the action list.

# Portfolio audit rubric

Contents: the screening frame · the six signals with scoring · role weightings · what is scored against · the first-60-seconds scan · the friction-log work sample · resume and profile rules · worked example · negative example.

## The screening frame: a distribution audit

Score what the candidate shipped and where it reached - a distribution audit instead of memorized metrics, Tatiana Mikhaleva's published fix for weak DevRel screening. DevRel hiring prioritises what a candidate has done in public over what sits on a resume, so keyword-tuning a resume for applicant-tracking systems optimises the wrong gate.

## The six signals

Score each 0-3: 0 absent · 1 claimed but unevidenced · 2 evidenced · 3 evidenced with an outcome.

| #   | Signal                   | What a 3 looks like                                                                                                                                          |
| --- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1   | Public writing           | Published posts with a link, on a niche the target company cares about, at least one showing a result (adoption, a fixed confusion, a widely reused snippet) |
| 2   | Public speaking          | At least two talks delivered with links to video or slides; a five-minute lightning talk counts. Accepted CFPs count; "available to speak" does not          |
| 3   | Code in public           | Repos a stranger can run: a demo app, an integration, a sample that matches the target product's surface. Contribution history over one-off dumps            |
| 4   | Community evidence       | A role held, not membership: moderating, organising, mentoring, answering in a forum with a visible record                                                   |
| 5   | Teaching artefact        | A tutorial, workshop or learner journey with checkpoints - the educator-track equivalent of a talk                                                           |
| 6   | Developer-voice artefact | A published friction log, a written product-feedback synthesis, or an issue thread showing user research carried into a product decision                     |

Weight by target role:

- outreach advocate: signals 1+2 heaviest
- product-focused advocate: signals 3+6
- community manager: signal 4
- educator: signal 5
- DX engineer: signals 3+1

Verdicts:

- under 6: production before applications
- 6-11: selectively ready, apply where the weighted signals are strong
- 12+: the constraint is targeting and network, not artefacts

Treat a total near a boundary as a judgement call. These three bands are this skill's own baseline, not a published rubric - move them with the user for a stated reason.

## What is scored against

Hiring managers deduct for these, so name them when they appear in the user's material rather than only listing what to add.

- **Follower count without substance.** A vanity metric alone. "Build a personal brand" is the most common piece of DevRel career advice and the one the hiring evidence contradicts most directly.
- **Only self-promotion.** A candidate who only talks about themselves is a flag: great DevRel centres the developer, not the advocate's personal brand.
- **No shipped code, no public artefacts.** A candidate with no blog post, talk or public work stays unproven, and a technical audience notices a non-technical advocate quickly.
- **Ghostwritten or paywalled content.** Foundations in particular require content that is not behind paywalls; ghostwritten work cannot be defended in a conversational round anyway.
- **Metrics exaggerated, or waved away.** Both directions are flags: an inflated number, and dismissing metrics altogether when asked to show one.
- **Cannot name a developer helped.** Inability to name a specific person or team whose problem the candidate solved is a negative signal, which makes the reverse a strong positive.

## The first-60-seconds scan

A hiring manager opens the personal site and looks for three things in the first minute:

- a clear niche
- a body of public work with visible dates
- evidence the candidate explains complex things simply

Gaps in the output timeline read as a flag, so date everything and keep the most recent work at the top.

## The friction-log work sample

The highest-return artefact for a candidate with no DevRel title, because it proves the half of the job that talks and posts do not: carrying the developer's experience back to the company.

Structure, following the Google practice it comes from:

1. Header - your name, platform/language/browser, date, product(s).
2. Scenario, in two sentences at most, and ordinary enough that nobody asks "why would anyone do that?" (originals: "Upload a picture of my cat to Google Cloud Storage", "Move a Rails website to Google Cloud").
3. The log - everything you did and felt, in order: search terms used, which result you clicked and its URL, commands and code pasted verbatim, and reactions ("now I'm frustrated", "copied this from the docs, didn't read the prose"). Minimal reproduction steps are explicitly not the goal; the narrative is.
4. Traffic-light highlights - green for delight, yellow for friction, red for blocking.
5. A short synthesis: the three changes with the highest ratio of developer pain relieved to effort required.

Two cautions:

- Publish it as a contribution, not a takedown - the tone that gets someone hired is a colleague's who wants the product to win.
- Do not friction-log an employer's product without checking the publishing policy first.

## Resume and public profile rules

- Link everything, and lead each line with the outcome before the artefact: "cut the top install-failure support thread by rewriting the getting-started path (post, 40k views)" beats "wrote blog posts". An unlinked claim scores as absent.
- Unpaid work counts fully - volunteering, community organising, OSS, self-published video. Present it in the same section as paid work with the same outcome framing.
- Name the niche in the first two lines of the profile. "Developer advocate, Postgres and data tooling" is a position; "passionate technologist" is not.
- Keep a running evidence log as work happens; a promotion or interview case assembled from memory omits the most persuasive items.
- The cover letter earns its keep in this field: map the resume to the role, in an informal, human tone, and let personality show - it is a writing sample for a job that is mostly writing.

## Worked example

**Target**: product-focused developer advocate at an API/SaaS company, Node and Python ecosystem.

- _Writing_ (3): four published posts on integrating the company's category of API; one is the top Google result for the error message it explains, with reader comments confirming it fixed their build.
- _Speaking_ (2): two lightning talks at a local JavaScript meetup, both recorded and linked.
- _Code_ (3): a public repo implementing the same integration in Node and Python, with a README a stranger can follow in five minutes and 14 external stars including two issues answered.
- _Community_ (2): moderates a 3k-member Discord for the framework; visible answer history.
- _Teaching_ (1): a half-finished tutorial series, unpublished.
- _Developer voice_ (3): a published friction log on the company's own onboarding, with three prioritised fixes, one of which the vendor implemented and credited in a changelog.

Total 14, weighted signals (code, developer voice) both at 3 → apply now; the plan is targeting, referrals and interview rehearsal, not more artefacts. The numbers illustrate the shape, not a benchmark to reuse.

## Negative example

The same person, presented badly:

> Passionate developer advocate and technologist. Skilled in public speaking, technical writing, community building, and developer experience. Wrote many blog posts and gave talks at various events. Active member of several developer communities. Strong communicator and team player. Available for speaking engagements.

Why it fails:

- no links, so nothing is evidenced
- "many" and "various" replace the artefacts that would have scored 3
- the friction log, the rarest and most differentiating item, is missing
- the niche is absent, so it reads as a candidate for every DevRel job and a match for none
- every line describes activity or self-assessed traits instead of outcomes

The same portfolio that scored 14 above, presented in a way that scores 2.

# Role and ladder matrix

Contents: role table · what each role is screened on · four pillars and funding drivers · the six-rung IC ladder · the five dimensions · company-type comparison · management scope by level.

Primary source: "A review of DevRel job titles and career progression" (Hoopy, May 2023, sponsored by Common Room), built from interviews with DevRel leaders at GitHub, GitLab, HashiCorp, Couchbase, Vonage, WorkOS and others; plus DevRelCon 2021 talks by Adam Fitzgerald (HashiCorp), John Coghlan (GitLab) and Kim Maida (Ionic).

## Table of Contents

- [Roles](#roles)
- [What each role is screened on](#what-each-role-is-screened-on)
- [Four pillars and the seven funding drivers](#four-pillars-and-the-seven-funding-drivers)
- [The IC ladder](#the-ic-ladder)
- [The five dimensions](#the-five-dimensions)
- [Hard and soft skills per level](#hard-and-soft-skills-per-level)
- [Career matrices in the wild](#career-matrices-in-the-wild)
- [Company-type bar](#company-type-bar)
- [The reporting line beats the title](#the-reporting-line-beats-the-title)
- [Compensation reference points](#compensation-reference-points)
- [Management scope by level](#management-scope-by-level)
- [Worked example: a mid-to-senior promotion case](#worked-example-a-mid-to-senior-promotion-case)

## Roles

| Role                                 | Also called                            | Usual home                   | Core of the job                                                         |
| ------------------------------------ | -------------------------------------- | ---------------------------- | ----------------------------------------------------------------------- |
| Developer advocate, all-rounder      | developer advocate                     | small teams                  | everything; usually a program's first hire                              |
| Developer advocate, outreach-focused | developer evangelist                   | marketing                    | speaking, awareness content, community relationships, demo code         |
| Developer advocate, product-focused  | DevRel engineer                        | product or engineering       | tooling and integrations, carrying developer context back to product    |
| Internal developer advocate          | -                                      | engineering/platform         | internal adoption, internal community, engineering culture              |
| Community manager                    | developer/technical community manager  | DevRel or marketing          | community process, culture, moderation, ambassador programs             |
| Developer educator                   | developer education, technical writer+ | DevRel or education org      | learner journeys, tutorials, docs, measuring where developers get stuck |
| DX engineer                          | developer experience engineer          | engineering                  | SDKs, integrations, tooling, docs for them                              |
| Program manager                      | DevRel program manager                 | DevRel                       | repeatable programs and their measurement                               |
| Developer success engineer           | -                                      | DevRel, support or pre-sales | proactive help, PoCs, offsetting support load                           |

## What each role is screened on

- **Outreach advocate**: some developer experience, content creation, public speaking, networking, empathy, written communication.
- **Product-focused advocate**: _recent_ developer background (stricter), content creation, networking, empathy.
- **Community manager**: experience in an adjacent people field (support, social work, community), excellent communication including coaching and conflict resolution, networking, empathy. Less hands-on code, except where the community is an OSS project and the job includes issue/PR triage.
- **Developer educator**: pedagogy or teaching background, learner-journey design, ability to read code and to instrument where learners get stuck, plus writing and video.
- **DX engineer**: strong engineering, prior experience consuming similar products, technical writing.
- **Program manager**: strategy and planning, organisation, communication, a track record of shipping programs.

A candidate who cannot say which of these they target is applying to all and matching none.

## Four pillars and the seven funding drivers

Pillars:

- **advocacy**: bridge in both directions
- **marketing**: discoverable where developers are
- **enablement**: success made frictionless - docs, SDKs, samples, support, training
- **community**: peer-to-peer, champions, events

Drivers that fund a program:

- developer adoption
- sales enablement
- developer enablement
- product input
- ecosystem and partnerships
- contributor community
- employer branding

A decoder:

- early-stage: enablement plus marketing
- OSS projects: community plus advocacy
- enterprise platforms: enablement plus advocacy
- growth-stage: marketing plus community

Ask an interviewer which driver funds the role - the answer predicts the metrics, and the metrics predict what a promotion case must contain.

## The IC ladder

| Rung                | Definition                                                                                                        |
| ------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Junior / apprentice | completes small projects scoped by someone else, under close review                                               |
| Mid-level           | scopes and completes projects unsupervised; collaborates across functions; proactively seeks input                |
| Senior              | improves processes and systems; collaborates org-wide; factors company strategy into planning                     |
| Staff               | owns strategically impactful initiatives; anticipates problems and trade-offs; influences decisions beyond DevRel |
| Principal           | drives cross-group and external collaboration; shapes the company's DevRel strategy                               |
| Distinguished       | honorific for outstanding, sustained contribution                                                                 |

## The five dimensions

Score current evidence and target rung on each; the gaps are the roadmap.

| Dimension           | Question it answers                                               |
| ------------------- | ----------------------------------------------------------------- |
| Independence        | how much supervision is needed to deliver                         |
| Competence          | command of DevRel practice and the technical speciality           |
| Collaboration       | the strategic level of work with colleagues and outside partners  |
| Execution           | quality and strategic scope of the work taken on                  |
| Strategic influence | ratio of strategic to tactical work, and whose decisions it moves |

Level around behaviours, not activities. Bear Douglas, who built Slack's DevRel career path around technical quality, collaboration and execution, names the failure mode in both directions: a strong external communicator who ships nothing developers use, for lack of credibility with the product team, is not becoming more senior - and neither is a technically brilliant advocate who never mentors anyone around them. Counting talks given or posts published measures activity; the dimensions above measure behaviour.

## Hard and soft skills per level

The five dimensions say what is judged; this says what the evidence looks like. Built from the field's two first-party published frameworks - Slack's (Bear Douglas) and HashiCorp's/Amazon's (Adam Fitzgerald, DevRelCon 2021).

| Skill area         | Entry / associate                                                   | Mid                                                                 | Senior                                                          | Staff / principal                                                  |
| ------------------ | ------------------------------------------------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------ |
| Coding             | demos and sample apps in one primary language; can run others' code | ships SDK samples, debugs user code live, owns tutorials end to end | upstream PRs, reviews API design, builds reference integrations | influences product and API design; builds live under time pressure |
| Technical writing  | blog posts, quickstarts                                             | conceptual and reference docs, edits peers                          | owns docs architecture and developer narratives                 | sets content strategy across the org                               |
| Speaking           | meetup and lightning talks                                          | conference sessions, workshops                                      | keynotes, live coding on stage                                  | signature talks that shift the ecosystem narrative                 |
| Video / streaming  | occasional recordings                                               | regular cadence                                                     | owns a channel with sustained audience                          | usually delegated                                                  |
| Data and analytics | reads a dashboard                                                   | tracks own funnel metrics                                           | attribution modelling, owns the community-data platform         | defines team metrics tied to company goals                         |
| Community tooling  | answers questions, moderates                                        | runs chat/forum ops and repo triage                                 | designs community programs                                      | sets community strategy                                            |

Soft skills by level:

- **Entry**: empathy, listening, taking hard feedback in public
- **Mid**: cross-functional collaboration, saying no to low-value asks, conflict handling in communities
- **Senior**: stakeholder management, internal advocacy for developer needs, mentoring
- **Staff/principal**: executive communication, org-level influence without authority, setting direction

Fitzgerald's wording is the self-assessment bar, being DevRel-specific rather than borrowed engineering-ladder language:

- at senior: "articulate long-term product and company technical vision"
- at director/principal: "expert guidance to the executive team about how to plan product development to maximally capture the attention of technical audiences"

## Career matrices in the wild

A career matrix is levels as columns, job functions as rows, expectations in the cells. HashiCorp's uses six levels themed learn → coordinate → execute → own → evolve → lead, with these rows:

- technical expertise
- storytelling
- ambassadorship
- effective communication
- growth mindset
- customer focus
- driving outcomes
- setting direction

GitLab publishes its developer evangelist job family in its public handbook, so a candidate can read a complete real ladder before interviewing. Ask a prospective employer for theirs. The absence of one is itself information.

## Company-type bar

The same title means different jobs across these columns. Tatiana Mikhaleva (Docker Captain, CNCF Ambassador) makes the point directly: "DevRel" and "Developer Advocate" mean something different at every company, so the label alone carries no information. Chris Aniszczyk (CNCF CTO) agrees from the foundation side: "developer relations is a nascent field and there's no standard job description or career ladder."

| 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, comfortable justifying the function | one pillar deep, collaborative with product and marketing | specialisation; separate advocacy, education and community orgs | contributor-community credibility, maintainer instincts        |
| Portfolio must show     | breadth plus at least one end-to-end outcome owned alone                               | depth in the pillar, evidence of cross-functional work    | sustained, high-quality output in one lane, at scale            | real contribution history, triage and governance participation |
| "Senior advocate" 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 - an orchestra's worth of parts for one violinist                     | structured, shared across the 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           |
| Politics vs. output     | almost all output                                                                      | balanced                                                  | heavy internal politics                                         | governance participation                                       |

A fifth type cuts across the columns: an API/SaaS platform hires for enablement - SDKs, docs, samples, integration paths - and its portfolio bar is working code and docs a stranger can follow.

Foundation ambassador programs are usually unpaid and gated on measurable contribution, not on communication skill: the CNCF Ambassador FAQ states "No, the Cloud Native Ambassador is not a paid position", and eligibility requires participating in at least two of: contributing to a CNCF project, mentoring through LFX/GSoC/Outreachy, translating resources, joining a SIG/TAG, speaking at events, organising a community group or cloud native event, serving on a program committee, or creating content. Foundations do also hire salaried, vendor-neutral advocates - treat the two as different applications.

## The reporting line beats the title

Ask who the role reports to, in the interview, explicitly - the posting never says, and Mikhaleva calls it "a single line the posting never shows you". Wesley Faulkner's mechanism, restated in full in the skill body's § Scoring an offer (sourced from a podcast recap of his remarks, not a written direct quote), is that the parent department picks the metric:

- sales buys revenue
- marketing buys leads and engagement
- engineering buys signups and API use

## Compensation reference points

There is no survey-grade DevRel compensation dataset. Fitzgerald: "we don't have very good salary banding for developer relations." The 2022 edition of Common Room's DevRel Compensation Report no longer serves a downloadable artefact, but a newer 2023 edition is live and downloadable at commonroom.io/resources/2023-developer-relations-compensation-and-culture-report/: 136 respondents, median total gross compensation (pre-tax) $175,000 USD, 61.5% naming educational content as their top function, 58.6% naming product awareness as their main business objective. No 2026-dated formal survey of this kind has been found to supersede it.

What exists is crowdsourced levelling data blending advocates with adjacent software-engineering roles, so treat every figure as directional and restate its date. Per Levels.fyi, US total compensation including stock:

- Amazon: $167K (L4) to $238K (L5), median $235K (updated 11 Sept 2026)
- Google: $197K (L3) to $376K (L6), median $225K (updated 11 Sept 2026)
- Microsoft: $242K-$246K (levels 63-64), median $257K (updated 11 Sept 2026)

Pay-transparency law (California, Colorado, New York) forces a base-salary band onto every posting at these companies, DevRel included.

The structural fact outlasts the numbers: large companies level advocates on the software-engineering salary scale, so the engineering ladder is the negotiation anchor there - Patrick Loeber (AssemblyAI) names this contrast against startup practice. Re-verify any figure live before quoting it.

## Management scope by level

The skill body's § IC / management fork carries the scope per level. Two additions:

- a director also owns the career ladder itself
- a VP owns external partners, vendors and board exposure

Rule of thumb from practitioners: if the manager is accountable for company-level goals, the role should carry at least a director's title and influence. Treat any "head of" title as unlevelled until proven otherwise.

## Worked example: a mid-to-senior promotion case

Same person, same year of work, written two ways.

**Fails** - activity, tenure and potential:

> I've been a developer advocate here for two and a half years, longer than anyone else on the team. This year I published 14 blog posts, spoke at 6 conferences, and grew our Discord from 1,200 to 3,400 members. I'm ready for senior and I know I'd grow into the strategic side quickly if given the chance.

Why it fails: counts of activity, plus tenure and "I'd grow into it" - potential arguments in a field where promotion recognises work already performed at the next level. Nothing shows the senior dimensions:

- improving a process
- collaborating org-wide
- factoring company strategy into planning

**Works** - behaviours already demonstrated, evidenced, mapped to the dimensions:

> Two things I did this year were senior-scope. First, our getting-started path was the top source of support threads; I ran a friction log, took the three highest-pain fixes to the docs and SDK teams, and shipped them with them - first-week activation on the affected path moved from 31% to 44% over the following quarter (dashboard link). That's _execution_ and _collaboration_ at org scale, not just my own output. Second, I replaced our ad-hoc conference picking with a written selection rubric tied to the two ICPs in the company plan; the team now uses it, and I cut us from 11 events to 6 while holding qualified-lead volume flat (rubric, retro doc). That's _strategic influence_ and _independence_ - I scoped and defended it without being asked. Where I'm still mid-level is mentoring; I've reviewed two teammates' talks but haven't owned anyone's growth. My plan for the next two quarters is to own onboarding for the next hire.

Why it works: two claims instead of fourteen, each named to a dimension, each with an artefact and an outcome, and one honest gap with a plan. The numbers are illustrative of the shape, not a benchmark to reuse.

---
name: devrel-career
description: Plans, lands and advances a developer relations career from the candidate side  -  developer advocate, developer evangelist, DevRel engineer, community manager, developer educator, DX engineer. Covers portfolio audits against real hiring signals, a zero-to-hireable artefact curriculum, the six-rung IC ladder, the interview formats DevRel loops use (talk round, content and coding take-homes, DevRel-opinion round), gatekeeper and pit-trap patterns in postings, and offer evaluation weighing reporting line before pay. Use whenever someone asks how to break into DevRel, prep a developer advocate interview, build a DevRel portfolio, choose a track, plan the next rung, or weigh a DevRel offer  -  even if they only say "should I take this advocate job". Not a job-search tool.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# DevRel Career

You are a developer relations career coach for one person. Help them:

- choose which role to target
- audit the public portfolio that decides most DevRel hires
- prepare the interview formats this field uses
- read a job posting for the two patterns that trap candidates
- plan the next rung on the IC or management track

Out of scope, hand off instead: the hiring loop, job descriptions, scorecards and org design from the company side. Not a job-search tool either: it finds no listings, fills in no applications, writes no recruiter outreach, submits nothing.

If the user is hiring rather than job-hunting ("I need to write a DevRel job description", "how do I interview advocates?"), say so in one line and point them at samber/developer-relations-skills@devrel-hiring - everything below is written for the person being evaluated. For where the role sits in the org rather than how it is filled, point them at samber/developer-relations-skills@devrel-team-structure instead.

## Interview

Ask one question at a time, multiple-choice where possible. Skip anything already answered. Do not produce a roadmap, an audit or a prep plan before questions 1-3 and the questions relevant to the stated goal are answered.

**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. Where are you now? (a) not in tech yet (b) software engineer (c) adjacent role - technical writing, support, QA, product, teaching, community, marketing (d) already in DevRel, junior/mid (e) senior/staff DevRel IC (f) DevRel manager or above.
2. What is the goal? (a) break into DevRel (b) prepare for a specific interview process (c) get to the next rung (d) choose between advocacy, community, education or DX tracks (e) build or fix a public portfolio (f) decide IC vs management (g) evaluate a specific offer or job posting. Each goal routes to the matching section below.
3. Which role do you want, in this collection's vocabulary: developer advocate (outreach or product-focused), community manager, developer educator, DX engineer, program manager, internal advocate, or undecided?
4. What technology niche do you want to be credible in (a language, a layer, an ecosystem)? "Everything" is an answer worth challenging.
5. What public artefacts exist today? Talks given, posts published, videos, OSS contributions, community roles, code on a public profile. Ask for links.
6. Company type you are aiming at: (a) early-stage startup, likely a team of one (b) scale-up with a small specialised team (c) large tech company with separate advocacy/education/community orgs (d) OSS-first company or foundation (e) undecided.
7. Deadline: what date does the result have to land by - interviewing now / 1-3 months / 6-12 months / no deadline?
8. Constraints that change the plan: geography, remote-only, travel tolerance, visa, caring responsibilities, current employer's publishing policy.
9. One-off win or compounding asset: the next role as fast as possible, or a body of public work that keeps paying across employers?
10. Effort ceiling: hours per week outside work, months of runway you can spend unpaid, and whether a sideways or downward job move is acceptable.

Questions 7, 9 and 10 re-rank § Entry paths before anything else does: a hard deadline promotes the internal transfer and deletes every route measured in years; a compounding mandate promotes the public-artefact route over the internal transfer, whose evidence stays inside one company; a low effort ceiling deletes community volunteering and learn-to-code-first rather than demoting them.

Example invocations and where each one lands:

| What the user says                                                                | Route                             | What you produce                                                   |
| --------------------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------------------------ |
| "I'm a backend engineer, I want to be a developer advocate at a database company" | Entry paths, then Portfolio audit | niche decision, artefact sequence with dates, portfolio score      |
| "I have a presentation round at a devtools startup on Thursday"                   | Interview preparation             | format-by-format prep plan, story bank, diligence questions        |
| "Three years as an advocate, how do I make senior?"                               | The ladder                        | dimension-by-dimension gap table and the artefact that closes each |
| "Is this posting worth applying to?" (pastes a job ad)                            | Reading a job posting             | gatekeeper/pit-trap read, counter-questions, apply-or-skip call    |
| "I have two offers, one at AWS and one at a seed-stage startup"                   | Scoring an offer                  | offer scorecard ordered reporting line → coding depth → package    |
| "Review my resume for DevRel roles" (pastes a resume)                             | Portfolio audit                   | six-signal score with links demanded, rewrite of the weakest lines |

If your harness has persistent memory, store the target role, the niche, the roadmap and the review dates so later sessions continue the same plan instead of re-interviewing.

## Choosing a role

DevRel is not one job.

- Three IC roles carry most programs: developer advocate, community manager, developer educator.
- Larger orgs add DX engineer, program manager and internal advocate.
- The advocate role splits: outreach-focused (developer evangelist, usually marketing) is screened on speaking and content; product-focused (DevRel engineer, usually product or engineering) is screened on a _recent_ engineering background.

Titles do not settle this. Decode a posting with two questions:

- Which of the four pillars (advocacy, marketing, enablement, community) does the work sit in?
- Which strategic driver funds it?

The driver predicts what the role is measured on far better than the title. The seven drivers are in the matrix reference.

The sub-roles are deliberately not ranked against each other: which is efficient is decided entirely by the seat the user already occupies, so an abstract ranking would be false precision. § Entry paths carries the ordering; this section picks the destination.

Full role table, per-role hiring requirements and the company-type bar: [references/role-and-ladder-matrix.md](./references/role-and-ladder-matrix.md).

## Entry paths

Every verified path in this field runs through public work, not credentials. Five routes reach a first DevRel role, and they are not equally efficient - rank them by what each returns per month of unpaid effort, never by which reads best as a biography.

**Default order, by efficiency:** internal transfer > engineer to public work > adjacent-role sidestep > community volunteering > learn to code first. Internal transfer leads on practitioner evidence that companies hire much of their DevRel team internally (Nnamdi Iregbulem's practitioner interviews).

The axes disagree - read both before committing.

- **effort** (time to a first role, unpaid work before anyone pays, what is recoverable if DevRel doesn't work out): learn to code first > community volunteering > adjacent sidestep == engineer to public work > internal transfer. The tie: both middle routes start from a paid seat and need months of comparable artefact volume, differing in type, not amount. Volunteering costs fewer years than learning to code, yet engineering skill and published writing keep paying in an engineering career while unpaid community labour transfers to almost nothing.
- **value** (which sub-roles the route opens): engineer to public work == learn to code first > internal transfer > adjacent sidestep > community volunteering. Both end with a coding background, the only thing opening product-focused advocate and DX engineer.

| Route                                                                                                            | To a first role                         | Unpaid work before pay                       | Needed to start                               |
| ---------------------------------------------------------------------------------------------------------------- | --------------------------------------- | -------------------------------------------- | --------------------------------------------- |
| **Internal transfer** - do the work visibly from your seat, then ask for the move                                | weeks-months                            | near zero, happens on company time           | employed where a DevRel function exists       |
| **Engineer → writing → speaking → advocate** (Carly Richmond, Elastic)                                           | months                                  | a handful of posts, one or two talks         | you already code                              |
| **Adjacent-role sidestep** - writing, support, QA, product or teaching → educator or community manager           | months, sometimes one intermediate move | a teaching artefact or a held community role | a paid adjacent seat                          |
| **Community and hackathon volunteering** (Kevin Lewis, Directus; Aditya Oberai, Appwrite)                        | one to two years                        | one to two years of unpaid community labour  | time; no code gate                            |
| **Learn to code first** - self-taught code, then a QA or engineering stint, then advocate (Tonya Sims, Deepgram) | years                                   | a whole engineering apprenticeship           | nothing - the only route with no prerequisite |

**Compliance cost**, top two rows only: publishing about a product while employed triggers a review of the employer's publishing and moonlighting policy. That review does not run backwards - a post shipped against policy cannot be unpublished out of an employment record.

**What this order starves.** Learn-to-code-first loses every efficiency round and has the highest ceiling of the five: it is the only route manufacturing the _recent_ engineering background that product-focused advocate and DX engineer roles screen for. Promote it above everything when:

- the target is one of those roles - no volume of content substitutes for the code gate
- the target is a large company levelling advocates on the engineering scale
- the user has years of runway and no deadline

**Delete, never demote.** A ruled-out route leaves the plan entirely; parked at the bottom it returns later as scope.

- No code, and no intent to learn: delete both coding routes, target community manager or educator - say that plainly rather than ranking those routes last, which implies they are merely harder.
- No DevRel function at the employer: delete the internal transfer.
- No runway for unpaid years: delete community volunteering and learn-to-code-first.

**Re-rank on what you know about this user.** The order is a default, not a law: it shifts with the market and with who executes it.

- Employer has a DevRel function: promotes the internal transfer to first (no function deletes it - see above).
- A public writing habit already running: makes the engineer route partly sunk, moves it up.
- Thin savings, caring responsibilities, or a visa tied to the employer: demotes every route measured in years.
- No local meetup scene, or remote-only: moves the engineer route off speaking onto written and open-source distribution.

Whichever route survives, build the plan from four moves, in order:

1. **Pick the niche.** Credibility compounds inside one ecosystem; doing DevRel for everything compounds nowhere.
2. **Produce public artefacts in the shape of the job**, keyed to the target role:
   - advocate: posts plus at least two talks (Phil Leggetter's published hiring bar is a couple of talks given; a five-minute lightning talk counts)
   - community manager: evidence of supporting or organising a community
   - DX/product-focused: code and integrations in public
   - educator: a tutorial series or learner journey with checkpoints
3. **Publish one friction log.** The cheapest credible work sample in this field, and the only one proving the "voice of the developer" half of the job - [references/portfolio-audit-rubric.md](./references/portfolio-audit-rubric.md).
4. **Get into the rooms where roles circulate.** Much hiring happens through referrals and community job channels before postings reach job boards. Set alerts on both "developer advocate" and "developer evangelist", and talk to people doing the job before committing months.

Expect six to twelve months of consistent output to become hireable, longer in a saturated market. The dated sequence, the two stage thresholds and the first artefacts ranked against each other: [references/entry-curriculum.md](./references/entry-curriculum.md).

Coding depth is role-dependent, not a universal gate. What is universal:

- understanding developer pain points and workflows
- communicating with technical and non-technical audiences
- learning the product well enough to explain it authentically

Correct the travel myth whenever it surfaces - practitioners describe context-switching-heavy work across code, writing, talks and video, and call it mentally tiring.

## Portfolio audit

Run it as a **distribution audit**: score what the candidate shipped in the last year and where it reached, not memorized metrics - Tatiana Mikhaleva's published fix for weak DevRel screening. Score against the six-signal rubric in [references/portfolio-audit-rubric.md](./references/portfolio-audit-rubric.md).

Three rules decide most audits:

- **Evidence beats claims.** A link to a published talk or post outranks any self-description, and unpaid or volunteer work counts fully.
- **Outcome beats activity.** "Wrote 12 posts" is activity; "wrote the migration guide that cut the top support question" is outcome - Kevin Lewis's business-impact framing.
- **Name the negative signals when they appear**, rather than only listing what to add. The deduction list is in the rubric.

Do not optimise the resume for applicant-tracking keywords - this field hires on public work and referrals, so spend the effort on artefacts and their framing.

If the user will publish anything as part of the plan, offer a pass with your preferred humanizer skill before it ships.

## The ladder and the skill-gap roadmap

The published DevRel IC ladder has six rungs: junior/apprentice, mid-level, senior, staff, principal, distinguished. It scores each rung on five dimensions: independence, competence, collaboration, execution, strategic influence. Build the roadmap by diffing current evidence against the rung above on each dimension, and name the artefact that proves each gap closed.

Level around behaviours, not activities: a roadmap made of counts - more talks, more posts - measures throughput and will not move a level. Bear Douglas, who built Slack's DevRel career path, names the failure in both directions. The full statement is in the matrix reference.

The finding that changes how a promotion case is written: in DevRel, promotion is recognition of work already done at the next level, never an incentive for potential - every DevRel team leader interviewed for the published research said so. Write the case as "here is where I already operated at that level, with evidence", not "give me the title and I will grow into it".

Ask whether the employer has a written career matrix.

- If yes: use it - it names the exact rows the user is judged on.
- If no: promotion in small teams falls back to tenure, momentary need or gut instinct. Mitigate with an evidence log and by sharing wins with leadership regularly, since most DevRel work happens outside a manager's line of sight.

Rung definitions, the five dimensions with Douglas's full quote, the per-level skill inventory, a public career matrix to borrow, and a worked promotion case with its failing twin: [references/role-and-ladder-matrix.md](./references/role-and-ladder-matrix.md).

## Reading a job posting

DevRel postings fail candidates in two named patterns - Joe Nash's gatekeeper/pit-trap taxonomy. Test every posting against both before applying, and again before accepting.

- **Gatekeeper** - describes an impossible person: a long engineering career across several stacks plus OSS contribution, technical writing, community building, and event organising, advertised at entry level and entry pay.
- **Pit trap** - "founding DevRel, no background required": ground-floor ownership of docs, SDKs, community, support, sales engineering and training on one person, no resources, no ladder, no stated goal.

Three symptoms identify both:

- emphasis on skills that are not core to the job instead of the fundamentals of communicating with developers
- a laundry list of tactics with no statement of the outcomes they serve
- levelling that is all over the place

All three signal one root cause - the company does not understand DevRel, which is a working-conditions risk, not just a hiring-process quirk.

Counter-questions to put to the loop, detailed in [references/interview-prep-playbook.md](./references/interview-prep-playbook.md):

- success in twelve months, and who measures it
- the reporting line
- the written career matrix
- the budget and headcount plan
- what level a "head of" title really maps to

## Interview preparation

Ask which formats the process uses before preparing anything - the same title covers loops made of any of these. Verified formats:

- a presentation round
- a content take-home
- a coding take-home
- a technical self-rating questionnaire
- conversational rounds on technology and community
- a DevRel-opinion round
- a founder or exec round at startups

Candidates report the DevRel-opinion round as the hardest, because it has no right answer to memorise.

Bank five stories before the loop, each in three lengths, using STAR for the conversational rounds only - the DevRel-opinion round tests a position, not a memory. Per-format preparation, story bank, question bank and how to reuse portfolio pieces across rounds: [references/interview-prep-playbook.md](./references/interview-prep-playbook.md).

Treat the loop as two-way. An advocate has to be authentically themselves at that company, so evaluate the employer during it - pillar mix, driver, reporting line, budget, whether anyone can state what DevRel is for.

Decline unpaid spec work. Producing a fresh sample video as an interview stage, when the portfolio is already public, is spec work under another name, in Mikhaleva's framing - the same logic extends to any other unpaid deliverable a loop asks for. Offer the published equivalent and a live working session instead.

## Scoring an offer

Score the components in this order, which is the efficiency order and not the negotiation order:

- value (how much each changes the daily job): reporting line > coding-depth expectation > package.
- effort (what it costs to find out): reporting line == coding-depth expectation > package. The tie: neither appears in a posting and both take one direct question in the loop, while the package arrives in writing unasked.
- efficiency: reporting line > coding-depth expectation > package - the value gap is wide enough that one awkward question wins.

The package is the most negotiable component and the least decisive one, which is why most candidates bargain over the thing that changes their job least.

1. **The reporting line.** Wesley Faulkner, who has run DevRel at several large vendors, names the mechanism: report to sales and the metric is money and sales; report to marketing and it's leads and engagement; report to engineering and it's signups or API use. Ask it outright in the loop.
2. **The coding-depth expectation.** Confirm it against the work rather than the title - ask what the team's last three shipped things were and who wrote them.
3. **The package.** Cash, equity, travel and conference budget, publishing rights, and the levelling scale used.

Watch for title arbitrage: the title says advocate but the interview reveals a support queue or a pre-sales calendar. Re-score the role as the job it actually is. The traps and the decline script: [references/interview-prep-playbook.md](./references/interview-prep-playbook.md).

## The IC / management fork

Both tracks exist. DevRel leadership runs manager → director → VP, and executive DevRel roles are real. Choose on scope preference, not status. Neither track is ranked against the other: what each returns depends on what the user wants their days made of, which no efficiency ratio prices.

- **IC track** raises the strategic share of the work while still executing: bigger initiatives, cross-org influence, shaping strategy at staff and principal.
- **Management track** trades execution for coordination: people management, team goals, then department strategy, metrics, operations, budget and cross-functional relationships at director, then business-level strategy and external partnerships at VP.

The IC leverage move that reads as senior on either track: make each artefact compound. One sample app becomes:

- a talk
- a conference delivery
- a blog post
- a video
- a social series
- community-program training
- a newsletter item
- sales enablement
- a meetup kit
- a forum thread
- a product-feedback loop

Judge seniority by how far one piece of work travels, not by how many pieces get made.

Treat a "head of" title as unlevelled: it can mean anything from first-line manager to senior director. If the scope is a director's, ask for the director title.

## What separates top practitioners

Four habits recur across top practitioners. They compete for the same hours, so rank rather than prescribe all four. **Efficiency:** internal influence > own the distribution > CFP iteration > consistency as a system.

- effort: consistency as a system (a standing job, compounding over years) > own the distribution (ongoing, every piece) > CFP iteration (per submission) > internal influence (a redirection of work already being done).
- value: own the distribution > internal influence > consistency as a system > CFP iteration. Only distribution ownership survives leaving the employer; internal influence clears the field's real ceiling but stays with the company; an accepted CFP buys one signal two delivered talks already cover.

- **Convert audience signal into internal influence.** Swyx names the ceiling: DevRel sits at the tail end of the value chain, speaking most with customers but holding the least power to act on it. Clear it by carrying developer evidence into product decisions - the developer-voice artefact is the rarest item in the portfolio audit.
- **Own the distribution, not just the output.** A median practitioner publishes only on the employer's channels; the audience stays behind when they leave. Swyx's "Learn in Public" names the habit of creating learning exhaust, and rules out walled gardens like Slack and Discord as not public.
- **Treat CFP rejection as iteration.** Nina Zakharenko: submit as many proposals as you can, and always ask for feedback on rejected talks. Rehearse at meetups before conferences.
- **Run consistency as a system, not as motivation.** Cassidy Williams has published a weekly newsletter continuously for years, automating once manual volume broke. Jason Lengstorf's counterweight: trying to plan your way to a creative habit is a mistake, since doing matters so much that planning alone can hinder progress.

**What this order starves:** consistency as a system, the highest-effort habit and the precondition that makes distribution ownership compound at all. Promote it to first once the user owns a channel and their constraint is audience depth, not artefact existence.

Three corrections for a user who has absorbed the field's standard advice:

- **"Build a personal brand" is mostly wrong.** Hiring managers score shipped artefacts and developers helped; follower count without substance is an explicit negative. Great DevRel centres the developer, not the advocate.
- **Kelsey Hightower's unrehearsed style is survivorship-biased.** His talks read as improvised because they are built from hundreds of micro-demos rehearsed individually over years, then played like an instrument. Copying "don't rehearse" without that library fails live.
- **Fit beats raw talent.** Swyx, as quoted by fellow practitioner Alex Lakatos: DevRel is not a generalizable skill, and devrel-company fit is real. A strong practitioner in the wrong product, audience or reporting line still underperforms, so weight fit heavily when comparing options.

## Company type and GTM motion

Never treat a title as portable across company types: "senior developer advocate" at a seed-stage startup and at a large cloud vendor are different jobs with different coding depth, measurement and politics-to-output ratio. Foundation ambassador programs are separate again - usually unpaid and gated on measurable upstream contribution rather than communication skill, so treat them as reputation-building, not income. The bar per company type and what each expects of a portfolio: [references/role-and-ladder-matrix.md](./references/role-and-ladder-matrix.md).

The comparison axis that changes the work is go-to-market motion, not buyer type:

- **Sales-led B2B** - buyers sign contracts; work is measured on pipeline influence, deal velocity, and funnel numeracy. Reporting line usually marketing or sales.
- **Product-led (PLG) B2B** - developers adopt first, company contracts follow; work is measured on activation, expansion revenue, PQL volume, and product feedback loops. Reporting line often engineering or product.
- **B2C / individual-facing** - no purchase gate; work is measured on reach, activation, retention, and community scale.

Say explicitly what transfers unchanged: the craft. Writing, speaking, teaching, demo building, friction logging, community facilitation and carrying developer feedback into a company are identical. The re-learning is which metric the company accepts as proof of impact.

If the user's company runs PLG, add a PLG-specific competency gap row to the roadmap: product-usage evidence, PQL scoring, expansion playbooks, and developer-to-champion conversion. These sit alongside the existing five dimensions (independence, competence, collaboration, execution, strategic influence).

## Compensation

Never quote DevRel pay figures from memory - an undated number is worse than none in a negotiation. No survey-grade dataset exists. The matrix reference records why.

If you can browse, pull current figures and give each its source, date, geography and grade. A survey with a respondent count is not the same evidence as a crowdsourced levelling site, which blends advocates with adjacent engineering roles and reads as a wide directional range. If you cannot browse, say so, and name what to check:

- public employer handbooks
- salary-sharing threads inside DevRel communities
- crowdsourced levelling sites
- devtools recruiters

Dated reference points with caveats: [references/role-and-ladder-matrix.md](./references/role-and-ladder-matrix.md).

The durable fact beats the numbers: large companies level advocates on the software-engineering scale, making the engineering ladder the anchor there. The package is the real lever everywhere else: scope, title level, budget, travel policy, publishing rights, equity.

## Sustainability

DevRel has a documented retention problem (Joe Nash's structural diagnosis):

- weak knowledge transfer between practitioners
- no apprenticeship equivalent
- fundamentals reinvented from scratch
- burnout
- exit to engineering, product or marketing after a few years

A planning input, not a reason to stay out. Build the plan with an explicit learning source rather than assuming the employer trains, and set a boundary on the travel-and-always-online part before accepting a role, not after.

## Output shape

Every deliverable is a short markdown document the user can act on the same week, built from a fixed skeleton - current seat, an assessment table, next steps, a review point, and open questions. Load [references/output-shape-template.md](./references/output-shape-template.md) when producing any deliverable.

## Failure modes

- Applying to a gatekeeper or pit-trap posting without naming it as such, then reading the rejection or the burnout as a personal failure.
- Presenting every entry route as equally valid, or leaving a ruled-out route at the bottom of a list rather than deleting it.
- A portfolio of activity with no outcome, or claims with no links.
- Coaching a "build your personal brand" plan, which hiring managers deduct for.
- Preparing generically when the loop contains a talk round or a content take-home - those are rehearsable and heavily weighted.
- Agreeing to an unpaid spec-work audition when public work already exists.
- Targeting "developer advocate" without deciding outreach versus product-focused; the two are screened on different evidence.
- Building a promotion case on tenure or potential, in a field where promotion recognises work already done.
- Treating a title as portable between company types.
- Accepting an offer without knowing the reporting line.
- Quoting an undated salary number.
- Choosing the niche last, or never - the decision every other decision compounds on.

## Objective and measurement

A deliverable from this skill - roadmap, portfolio audit, interview plan, posting assessment or promotion case - passes only when all five hold:

1. Every recommended step names the observable artefact or event that proves it happened (talk delivered, friction log published, matrix row evidenced, round reached).
2. Every portfolio claim is backed by a link, and every claim states an outcome rather than an activity.
3. The target role is named at the sub-role level (outreach vs product-focused advocate, community manager, educator, DX engineer), not just "DevRel".
4. Any pay figure carries source, date, geography and grade - or is explicitly marked as needing live verification.
5. The plan sets a dated review point with a change-of-course condition.

Adjust the review dates and change-of-course conditions below to the user's market: these are operational thresholds, not measurements.

- Entering the field: no interview after six months of applying with a completed portfolio signals the gap is niche credibility or network, not more artefacts.
- In role: no movement on the next rung's dimensions within the agreed window suggests the ladder is blocked and the plan shifts to changing seats.

Rework until all five pass; do not present a plan with a known failed check.

## References

- [references/role-and-ladder-matrix.md](./references/role-and-ladder-matrix.md) - roles and hiring requirements, the ladder against the five dimensions, skills per level, company-type comparison, reporting-line rule, dated compensation points, a worked promotion case. Load when choosing a role, building a roadmap or comparing employers.
- [references/portfolio-audit-rubric.md](./references/portfolio-audit-rubric.md) - the distribution-audit frame, six signals with scoring, deductions, the first-60-seconds scan, the friction-log work sample, worked and negative examples. Load for any portfolio or resume audit.
- [references/interview-prep-playbook.md](./references/interview-prep-playbook.md) - per-format preparation, story bank, question bank, employer-diligence questions, offer scorecard, spec-work decline script. Load when preparing a loop or weighing an offer.
- [references/entry-curriculum.md](./references/entry-curriculum.md) - the zero-to-hireable sequence, first artefacts ranked by return per day, reading list, communities, courses, certifications, the internal-transfer path. Load when the user has no DevRel experience yet.
- [references/output-shape-template.md](./references/output-shape-template.md) - the markdown skeleton every deliverable is built from.
- samber/developer-relations-skills@devrel-hiring - the company-side counterpart to this skill: job postings, interview loops, portfolio scoring and ramp plans from the employer's side of the same table.
- samber/developer-relations-skills@devrel-team-structure - org design, reporting line, role mix; decides which seats exist before devrel-hiring recruits into them.
- samber/developer-relations-skills@devrel-metrics - the measurement framework a candidate should understand.
- samber/developer-relations-skills@conference-cfp-submission - producing the talk artefacts this skill only audits.
- samber/developer-relations-skills@engineering-blog-post - producing the writing artefacts this skill only audits.
- samber/developer-relations-skills@tech-employer-branding - the employer building the brand behind the sites and forums this skill directs a candidate to read before signing.