Back to Details

devrel-hiring

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DevRel Hiring

DevRel 招聘

Build the four artefacts a hiring manager needs to recruit into a DevRel role with the same rigour the field's own hiring research recommends: a role scorecard and posting, a structured interview loop with question bank, a portfolio-and-work-sample evaluation, and a 30-60-90 ramp plan.
DevRel has no standard job description or career ladder (Chris Aniszczyk, CNCF CTO), and its own hiring literature documents two named failure patterns in postings written without this discipline - see Reading the answers. That absence is the reason to build these four artefacts deliberately rather than adapt a generic engineering or marketing hiring template.
Out of scope, hand off instead:
  • Where DevRel reports and how the team is shaped - samber/developer-relations-skills@devrel-team-structure decides the org before this skill recruits into it.
  • Coaching the candidate - samber/developer-relations-skills@devrel-career is the mirror image of this skill, built for the person being evaluated.
If the user is job-hunting rather than hiring ("how do I prep for a DevRel interview", "is this posting worth applying to"), say so in one line and point them at devrel-career.
为招聘经理构建招聘 DevRel 角色所需的四类交付物，并以该领域自身的招聘研究所推荐的标准来执行：角色计分卡与职位描述、带题库的结构化面试流程、作品集与工作样本评估，以及 30-60-90 入职爬坡计划。
DevRel 没有标准的职位描述或职业阶梯（Chris Aniszczyk，CNCF CTO），其招聘文献也记录了在缺乏这套纪律的情况下撰写职位描述时出现的两类知名失败模式——见“解读回答”。正是由于这种缺失，才需要刻意构建这四类交付物，而不是套用通用的工程或市场营销招聘模板。
不在范围内，请转交：
  • DevRel 向谁汇报以及团队如何构成 - samber/developer-relations-skills@devrel-team-structure 先决定组织，然后本 skill 才为它招聘。
  • 辅导候选人 - samber/developer-relations-skills@devrel-career 是本 skill 的镜像，专为被评估者打造。
如果用户是在求职而非招聘（“如何准备 DevRel 面试”、“这个职位值得申请吗”），用一句话说明，并引导其前往 devrel-career。

Interview

面试

Ask one question at a time, multiple-choice where possible. Skip anything already answered. Questions 8-10 re-rank the artefacts below before any is built - ask them before producing anything.
  1. Company type: (a) early startup, pre-seed-A, this will be a team of one (b) growth/scale-up, B-D (c) big-tech enterprise (d) OSS-first company or foundation.
  2. Role target: (a) developer advocate, outreach-focused (b) developer advocate, product-focused (c) community manager (d) developer educator (e) DX engineer (f) not sure - recommend one from the funding driver.
  3. What funds this role - the driver behind the budget: developer adoption, sales enablement, developer enablement, product input, ecosystem/partnerships, contributor community, or employer branding?
  4. Go-to-market motion: sales-led B2B, product-led (PLG) B2B, B2C/individual-facing, or OSS/foundation with no purchase gate.
  5. Coding-depth requirement: does this role need to ship SDK samples and review API design, or is the bar public communication with only light code?
  6. Team stage: first DevRel hire with no incumbent to calibrate against, or a repeatable hire with existing top performers to profile from?
  7. Compensation stance: will you publish a range in the posting, and do you know your hiring jurisdiction's pay-transparency requirement?
  8. Deadline: this month, this quarter, or no hard date?
  9. One-off hire or the first of several where the scorecard and question bank get reused?
  10. Effort ceiling: how many interviewer-hours per candidate, and is there a recruiter or a trained panel?
一次只问一个问题，尽可能用选择题。已回答的内容跳过。问题 8-10 会在构建任何交付物之前对下面的交付物重新排序——请在产出任何内容之前先问这些问题。
  1. 公司类型：(a) 早期创业公司，种子轮-A轮，这将是单人团队 (b) 成长期/规模扩张期，B-D轮 (c) 大型科技企业 (d) OSS优先的公司或基金会。
  2. 角色目标：(a) 开发者布道师，专注于对外推广 (b) 开发者布道师，专注于产品 (c) 社区经理 (d) 开发者教育者 (e) DX工程师 (f) 不确定——根据资金驱动因素推荐一个。
  3. 什么为该角色提供资金——预算背后的驱动因素：开发者采用、销售赋能、开发者赋能、产品输入、生态/合作伙伴、贡献者社区，还是雇主品牌？
  4. 市场进入策略：销售主导的B2B、产品主导（PLG）的B2B、B2C/面向个人，还是无购买门槛的OSS/基金会？
  5. 编码深度要求：该角色是否需要交付SDK示例并评审API设计，还是以公开沟通为主、只需少量代码即可？
  6. 团队阶段：首个DevRel招聘，没有现任职者作为校准基准；还是可复用招聘，有现有顶尖绩效者可供画像？
  7. 薪酬立场：你会在职位描述中公布范围吗？你是否了解招聘辖区的薪酬透明度要求？
  8. 截止时间：本月、本季度，还是没有硬性日期？
  9. 一次性招聘，还是多个职位中的第一个，计分卡和题库会被复用？
  10. 精力上限：每位候选人多少面试官小时？是否有招聘人员或训练有素的面试小组？

Reading the answers

解读回答

  • Q1 sets the bar and the portfolio weighting - load references/company-type-and-driver-lookup.md. A startup hires a generalist who justifies the function's own existence; big tech anchors the role to its engineering levelling scale; an OSS/foundation role screens on contribution history, not communication polish.
  • Q2 + Q3 decide what the posting is screened on - see references/company-type-and-driver-lookup.md for the per-role requirement table. A candidate who cannot say which sub-role they target is applying to all and matching none; the same is true of a posting that cannot say which sub-role it needs.
  • Q3 + Q4 decide the pillar mix and therefore the metric the role is measured on: sales-led promotes advocacy plus sales enablement; PLG promotes enablement plus product input; B2C promotes community plus reach; OSS/foundation promotes community plus advocacy.
  • Before drafting the posting, self-audit it against the field's two named failure patterns (Joe Nash, DevRelCon 2021 - the same taxonomy devrel-career teaches candidates to detect from the outside):
    • Gatekeeper - describing an impossible person: a full engineering career across several stacks plus OSS contribution, technical writing, community building and event organising, advertised at entry pay.
    • Pit trap - "founding DevRel, no background required" that actually expects one person to cover docs, SDKs, community, support, sales engineering, and training with no resources, no ladder and no stated goal.
    • Both share three symptoms: off-core skills emphasis, a tactics list with no stated outcome, and levelling that is inconsistent with the pay. A posting failing any symptom needs a rewrite before it goes out, not after it fails to convert.
  • Q6 decides the candidate profile. First hire: a builder who can justify the function's existence without an incumbent team, similar to a company's first sales hire - weight self-direction and breadth over specialised depth. Repeatable hire: profile from the org's own top performers on the pillar this role actually owns.
  • Q7 triggers the compensation gate in the Quality gate below - never invent a jurisdiction's legal requirement; confirm current pay-transparency rules for the hiring location before publishing.
  • Q8 promotes the fast-acting options: a this-month deadline promotes reusing an existing question bank and a shorter loop over designing a new custom work sample from scratch.
  • Q9 decides whether the work sample stays thin. One-off: design it once, cheaply. Compounding: the frozen rubric and question bank serve every future hire in this pillar, which promotes building both properly first.
  • Q10 deletes loop stages rather than reordering them. Under a handful of interviewer-hours per candidate: cut to a scorecard, one structured conversational round, and the portfolio evaluation; skip a live work sample entirely rather than running it unscored.
  • Q1设定标准与作品集权重 - 加载 references/company-type-and-driver-lookup.md。创业公司招通才，需要其证明该职能本身存在的价值；大型科技公司将该角色锚定在工程职级体系上；OSS/基金会角色按贡献历史筛选，而不是看沟通技巧。
  • Q2 + Q3决定职位描述以何为筛选依据 - 参见 references/company-type-and-driver-lookup.md 中的分角色要求表。一个说不出自己瞄准哪个子角色的候选人，是在申请所有职位而匹配不上任何一个；同理，一份说不出自己需要哪个子角色的职位描述也是如此。
  • Q3 + Q4决定支柱组合，进而决定衡量该角色的指标：销售主导侧重布道加销售赋能；PLG侧重赋能加产品输入；B2C侧重社区加触达；OSS/基金会侧重社区加布道。
  • 在起草职位描述前，对照该领域两个知名的失败模式进行自我审计（Joe Nash，DevRelCon 2021——devrel-career 教候选人从外部识别的正是同一套分类）：
    • 守门人（Gatekeeper） - 描述一个不可能存在的人：横跨多个技术栈的完整工程生涯，外加OSS贡献、技术写作、社区建设和活动组织，却按入门薪资招聘。
    • 陷阱（Pit trap） - “创始DevRel，无需背景”，实际却期望一个人在没有资源、没有职级阶梯、没有明确目标的情况下覆盖文档、SDK、社区、支持、销售工程和培训。
    • 两种模式有三个共同症状：强调非核心技能、罗列战术却没有明确成果、职级与薪酬不一致。任何一项症状未通过的职位描述都需要在发布前重写，而不是等转化失败后再改。
  • Q6决定候选人画像。 首次招聘：需要能在没有现成团队的情况下证明职能价值的建设者，类似公司第一位销售——自我驱动力和广度优先于专精深度。可复用招聘：以该角色实际负责的支柱上组织内现有顶尖绩效者为画像蓝本。
  • Q7触发下方质量门中的薪酬门槛 - 绝不虚构某个司法辖区的法律要求；发布前确认招聘地现行的薪酬透明度规则。
  • Q8优先考虑快速行动选项：本月截止会优先复现现有题库和更短的流程，而不是从零设计新的定制工作样本。
  • Q9决定工作样本是否保持轻量。 一次性：便宜地设计一次。复利型：冻结的评分标准和题库将服务于该支柱未来每一次招聘，因此应先妥善构建两者。
  • Q10删除流程环节，而不是重新排序。 在每位候选人只有少量面试官小时的情况下：缩减为计分卡、一轮结构化对话和作品集评估；完全跳过现场工作样本，也不要无评分地运行。

Workflow

工作流程

Produce the four artefacts in order. Deliver each one, validate it with the user, then move to the next.
  1. Run the Interview. State the role and pillar-mix recommendation in one short paragraph the user can veto.
  2. Artefact 1 - role scorecard and posting. Build from references/company-type-and-driver-lookup.md and references/scorecard-and-posting-template.md:
    • a one-sentence mission naming the funding driver from Q3
    • 3-8 measurable outcomes ranked by importance and quantified (e.g. "cut top-three onboarding support threads 25% via a shipped friction-log fix", "40 accepted CFPs sourced from the community in year one"), never vague responsibilities
    • 5-7 competencies weighted per the role and company type from Q1-Q2
    • run the gatekeeper/pit-trap self-audit above before publishing
  3. Artefact 2 - interview loop and question bank. Build from references/interview-loop-and-question-bank.md:
    • pick 3-5 formats from the field's verified set (presentation round, content take-home, coding take-home, technical self-rating, conversational rounds, DevRel-opinion round, founder/exec round at startups) - there is no standard loop, so choose formats that actually test this role's pillar mix, never the whole set by default
    • place the portfolio evaluation (Artefact 3) early, before any new work is requested of the candidate
    • write 2-3 questions per scorecard competency from the category banks in the reference file, plus at least one DevRel-opinion question - candidates report it as the hardest round because it has no memorised answer, which is exactly why it separates a position from a rehearsed pitch
    • define scoring mechanics: every interviewer scores independently with an evidence note before any debrief, then combine mechanically against the scorecard's pre-set weights - a general employment-selection finding (structured, independently-scored, mechanically-combined interviews outperform unstructured ones and holistic debriefs), not one specific to DevRel, but it transfers directly since nothing about the finding is domain-specific
    • never request unpaid spec work when a public portfolio already exists; offer a paid live working session instead
  4. Artefact 3 - portfolio and work-sample evaluation. Build from references/portfolio-and-work-sample-scoring.md:
    • score the candidate's shipped public work against the six-signal distribution rubric (public writing, public speaking, code in public, community evidence, teaching artefact, developer-voice artefact), weighted by the target sub-role from Q2 - the full rubric and its scoring bands live in devrel-career; this skill applies it from the evaluator's side
    • when the portfolio is thin or the candidate is new to the field, design a scored, paid work sample instead of judging by resume alone - a short lightning-talk round, a documentation-edit exercise, or an "explain this API change to a developer" exercise, matched to the target sub-role
    • name the negative signals explicitly when present (follower count with no substance, only self-promotion, no shipped code, inability to name a developer helped) rather than only listing what is missing
  5. Artefact 4 - 30-60-90 ramp plan. Build from references/ramp-plan-template.md:
    • Day 0-30: the new hire uses the product as a developer would and ships a friction log - the same artefact devrel-career recommends as a portfolio piece, now the first-30-days deliverable
    • Day 31-60: first public or internal artefact shipped in the target pillar, paired with an existing team member
    • Day 61-90: self-directed ownership of one recurring program slice, plus a documented plan for the metric the role's funding driver is measured on
  6. Note candidate-sourcing channels from references/sourcing-channels.md if the user has not yet identified where to find candidates.
  7. Run the Quality gate below on all four artefacts. Iterate until it passes.
  8. If your harness has persistent memory, store the scorecard, the frozen question bank, the loop design and the ramp milestones so later hires into the same role reuse them instead of restarting.
按顺序产出四类交付物。交付每个交付物后，与用户确认，再进行下一个。
  1. 运行“面试”环节。用一小段用户可否决的话说明角色与支柱组合建议。
  2. 交付物1 - 角色计分卡与职位描述。 基于 references/company-type-and-driver-lookup.md 和 references/scorecard-and-posting-template.md 构建：
    • 一句话使命，指出Q3中的资金驱动因素
    • 3-8个可按重要性排序并量化的可衡量成果（例如“通过交付的摩擦日志修复，将前三大上手支持工单减少25%”、“第一年从社区获得40个被接受的CFP”），绝不用模糊的职责描述
    • 5-7项按Q1-Q2中的角色和公司类型加权的胜任力
    • 发布前运行上述守门人/陷阱自我审计
  3. 交付物2 - 面试流程与题库。 基于 references/interview-loop-and-question-bank.md 构建：
    • 从该领域经过验证的格式集中选择3-5种（演示轮、内容带回家、编码带回家、技术自评、对话轮、DevRel观点轮、创业公司创始人/高管轮）——没有标准流程，因此选择真正测试该角色支柱组合的格式，绝不能默认选择整套。
    • 将作品集评估（交付物3）放在前面，在向候选人提出任何新作品要求之前
    • 针对计分卡每项胜任力，从参考文件的分类题库中写2-3个问题，外加至少一个DevRel观点问题——候选人报告称这是最难的一轮，因为它没有可背的答案；这正是它能区分真实立场与排练过演讲的原因
    • 定义评分机制：每位面试官先独立评分并附证据说明，再进行任何汇报，然后按计分卡预设权重机械地合并结果——这是通用人才选拔研究结论（结构化、独立评分、机械合并的面试优于非结构化面试和整体性汇报），并非DevRel特有，但该结论没有任何领域特定部分，因此直接适用
    • 当已有公开作品集时，绝不要求无偿试稿；改为提供付费的现场协作工作环节
  4. 交付物3 - 作品集与工作样本评估。 基于 references/portfolio-and-work-sample-scoring.md 构建：
    • 根据六信号分布评分标准（公开写作、公开演讲、公开代码、社区证据、教学工件、开发者声音工件），按Q2中的目标子角色加权，对候选人已发布的公开工作评分——完整评分标准及其分数段位于 devrel-career；本 skill 从评估者一侧应用它
    • 当作品集薄弱或候选人刚进入该领域时，设计一个有评分、付费的工作样本，而不是仅凭简历判断——可以是简短的闪电演讲轮、文档编辑练习，或“向开发者解释这个API变更”练习，并与目标子角色匹配
    • 存在负面信号时明确说明（粉丝数但没有实质内容、只有自我推销、没有交付过代码、说不出自己帮助过哪位开发者），而不是只列出缺失项
  5. 交付物4 - 30-60-90入职爬坡计划。 基于 references/ramp-plan-template.md 构建：
    • 第0-30天：新员工以开发者身份使用产品，并交付一份摩擦日志——devrel-career 也推荐将其作为作品集素材，现在它是前30天的交付物
    • 第31-60天：在目标支柱中交付首个公开或内部工件，并与一位现有团队成员搭档
    • 第61-90天：自主负责一个周期性项目的切片，并为该角色资金驱动因素所衡量的指标制定书面计划
  6. 如果用户尚未确定从哪里找候选人，从 references/sourcing-channels.md 中记录候选人来源渠道。
  7. 对全部四类交付物运行下方质量门。迭代直至通过。
  8. 如果你的运行环境有持久化记忆，存储计分卡、冻结题库、流程设计和爬坡里程碑，以便后续同一角色的招聘复用，而不是重新开始。

Company type and funding driver

公司类型与资金驱动因素

Never treat a posting template as portable across company types: the same title means a different job at a startup, a growth-stage company, a big-tech vendor, and an OSS-first foundation, and each expects a different portfolio bar and coding depth. The full comparison table, the four pillars, and the seven funding drivers that predict what a role is measured on: references/company-type-and-driver-lookup.md.
Foundation and OSS-adjacent ambassador-style roles are frequently unpaid and gated on measurable contribution rather than communication skill - confirm which kind of role this is before writing a salaried posting's requirements into an unpaid program, or the reverse.
绝不要把职位描述模板视为可跨公司类型移植：同样的职位头衔在创业公司、成长期公司、大型科技厂商和OSS优先基金会代表不同的工作，且各自期望不同的作品集标准和编码深度。完整对比表、四个支柱，以及预测角色衡量指标的七个资金驱动因素：references/company-type-and-driver-lookup.md。
基金会和OSS相关的“大使”类角色通常是无偿的，并且以可衡量的贡献而非沟通能力为门槛——先确认这是哪种角色，再将有薪职位描述的要求写入无偿项目，或反之。

Quality gate

质量门

Score the four artefacts against these checks before final delivery. Iterate until every check passes.
  1. The scorecard has 3-8 outcomes, every one quantified and ranked, and names the funding driver from Q3.
  2. The posting passes the gatekeeper/pit-trap self-audit: no off-core skills emphasis, no tactics-without-outcomes list, levelling consistent with the stated pay.
  3. Every interview question maps to a named scorecard competency; the same question set applies to every candidate for the role.
  4. The loop includes at least one format that actually tests the target pillar (a presentation round for outreach-heavy roles, a coding take-home for DX/product-focused roles), never a generic set copied regardless of role.
  5. No stage asks for unpaid spec work when public portfolio evidence already exists.
  6. Interviewers submit independent, evidence-noted scores before any debrief; the final combination is mechanical against pre-set weights.
  7. The portfolio evaluation is scored against the six-signal rubric, weighted by target sub-role, with negative signals named explicitly where present.
  8. If a live work sample was designed, it is scored on a fixed rubric and paid, never treated as free trial work.
  9. The posting states a real compensation stance (a published range, or an explicit note on why it is gated) consistent with the Q7 jurisdiction answer - never publish "competitive" with no figure and no stated reason.
  10. The ramp plan contains a day-30 friction-log deliverable, a day-60 shipped-artefact milestone, and a day-90 self-directed-ownership milestone.
  11. Every claim about "what good looks like" in this skill's own output is traceable to a named source or explicitly marked as this skill's own working assumption - this field has no single authoritative career-ladder body, so an unlabelled claim reads as more settled than it is.
在最终交付前，按以下检查对四类交付物评分。迭代直至所有检查通过。
  1. 计分卡包含3-8项成果，每项都量化并排序，并指出Q3中的资金驱动因素。
  2. 职位描述通过守门人/陷阱自我审计：不强调非核心技能，不罗列无成果的战术，职级与所述薪酬一致。
  3. 每个面试问题都映射到指定计分卡胜任力；同一组问题应用于该职位的所有候选人。
  4. 流程至少包含一种真正测试目标支柱的格式（对外推广型角色用演示轮，DX/产品型角色用编码带回家），绝不复制与角色无关的通用集合。
  5. 当已有公开作品集证据时，任何环节都不要求无偿试稿。
  6. 面试官在任何汇报之前提交独立、有证据记录的评分；最终合并按预设权重机械完成。
  7. 作品集评估以六信号评分标准评分，按目标子角色加权，存在负面信号时明确说明。
  8. 如果设计了现场工作样本，必须按固定评分标准评分并付费，绝不能当作免费试工。
  9. 职位描述给出真实的薪酬立场（公布范围，或明确说明为何不公布），与Q7司法辖区答案一致——绝不发布没有数字也没有说明理由的“competitive（有竞争力）”。
  10. 爬坡计划包含第30天摩擦日志交付物、第60天交付工件里程碑，以及第90天自主负责里程碑。
  11. 本 skill 输出中关于“什么是好的表现”的每个说法都可追溯到具名来源，或明确标记为本 skill 自身的工作假设——该领域没有单一的权威职业阶梯机构，因此未标注的说法会显得比实际更确定。

Common failure modes

常见失败模式

Not ranked, deliberately: every row is a defect with one mandatory fix.
FailureFix
Gatekeeper postingCut the off-core requirement list to what the pillar mix actually needs; re-price the level against the real requirement
Pit-trap postingState the resources, the ladder and the twelve-month goal explicitly, or postpone the hire until they exist
Copying a generic engineering or marketing JD templateRebuild from the funding driver and pillar mix; DevRel's outcomes and competencies do not map onto either template
Judging by resume instead of shipped workRun the six-signal portfolio evaluation before any conversational round
Unpaid spec-work auditionOffer a paid live working session or judge the existing public portfolio instead
One blended gut score after a group debriefIndependent, evidence-noted scores before any discussion, combined mechanically
Applying the same loop to every DevRel sub-roleChoose formats and questions per the target sub-role's actual screened requirements
"Competitive compensation", no range, no reasonPublish a range or state explicitly why it is gated, checked against the jurisdiction's own current requirement
Ramp plan with no artefact milestoneAnchor day 30 on a shipped friction log, day 60 on a shipped pillar artefact, day 90 on self-directed ownership
Treating a title as portable across company typesRecalibrate the whole scorecard against Q1's company-type row before reusing any prior posting
有意不排序：每一行都是一个缺陷，并有唯一的强制修复方式。
失败修复
守门人式职位描述将非核心要求清单削减为支柱组合实际需要的内容；按真实要求重新定价层级
陷阱式职位描述明确说明资源、阶梯和十二个月目标，否则推迟招聘直到这些条件存在
照搬通用工程或市场营销JD模板从资金驱动因素和支柱组合重新构建；DevRel的成果与胜任力无法映射到任一模板
凭简历而非已交付工作来判断在任何对话轮之前运行六信号作品集评估
无偿试稿式面试提供付费的现场协作工作环节，或直接评估已有公开作品集
小组汇报后给出一个整体直觉分数在任何讨论之前独立、有证据记录地评分，并机械合并
对所有DevRel子角色套用同一流程根据目标子角色实际筛选的要求选择格式和问题
“有竞争力的薪酬”，无范围，无理由公布范围，或明确说明为何不公布，并对照司法辖区现行要求
爬坡计划没有工件里程碑第30天锚定在交付摩擦日志，第60天锚定在交付支柱工件，第90天锚定在自主负责
将职位头衔视为跨公司类型可移植在复用任何旧职位描述前，按Q1的公司类型行重新校准整个计分卡

Reference

参考

  • See references/company-type-and-driver-lookup.md for the company-type comparison table, the four pillars, and the seven funding drivers.
  • See references/scorecard-and-posting-template.md for the scorecard structure and a worked posting example.
  • See references/interview-loop-and-question-bank.md for the format table, per-role loop design, and the category-organised question bank.
  • See references/portfolio-and-work-sample-scoring.md for the six-signal scoring application and paid work-sample designs.
  • See references/ramp-plan-template.md for the full 30-60-90 template.
  • See references/sourcing-channels.md for where DevRel candidates are actually found.
  • See 
    samber/developer-relations-skills@devrel-career
    for the candidate's side of this table - portfolio building, interview prep, offer evaluation; this skill never coaches candidates.
  • See 
    samber/developer-relations-skills@devrel-team-structure
    for the org design and reporting line this role is recruited into - decided before, not by, this skill.
  • See 
    samber/developer-relations-skills@devrel-metrics
    for the measurement framework the scorecard's outcomes should stay consistent with once the hire is in seat.
  • See 
    samber/developer-relations-skills@tech-employer-branding
    for the employer-brand surfaces a candidate will check before accepting.
  • 参见 references/company-type-and-driver-lookup.md 获取公司类型对比表、四个支柱和七个资金驱动因素。
  • 参见 references/scorecard-and-posting-template.md 获取计分卡结构和已完成的职位描述示例。
  • 参见 references/interview-loop-and-question-bank.md 获取格式表、分角色流程设计和按分类组织的题库。
  • 参见 references/portfolio-and-work-sample-scoring.md 获取六信号评分应用和付费工作样本设计。
  • 参见 references/ramp-plan-template.md 获取完整30-60-90模板。
  • 参见 references/sourcing-channels.md 获取可实际找到DevRel候选人的渠道。
  • 参见 
    samber/developer-relations-skills@devrel-career
    了解该表格的候选人侧——作品集构建、面试准备、offer评估；本 skill 不辅导候选人。
  • 参见 
    samber/developer-relations-skills@devrel-team-structure
    了解该角色被招聘进入的组织设计与汇报线——由组织决定在先，而非本 skill。
  • 参见 
    samber/developer-relations-skills@devrel-metrics
    了解衡量框架，计分卡成果应在候选人到岗后保持一致。
  • 参见 
    samber/developer-relations-skills@tech-employer-branding
    了解候选人接受前会查看的雇主品牌触点。