招聘 DevRel/开发者关系岗位时：从结果导向记分卡…

当你要作为雇主方招聘开发者关系（DevRel）岗位——写招聘启事与记分卡、设计面试流程与题库、评估候选人作品集、设计付费工作样本、制定 30-60-90 上手计划时使用。

适用场景

解决思路

1. 先做 10 题面试采集：一次只问一个，能多选就多选，已回答的跳过；第 8-10 题必须在产出任何东西之前问完，它们会重排后面四件套。
2. Q1 公司类型：(a) 早期创业公司 pre-seed-A，一人成军 (b) 成长/规模化公司 B-D 轮 (c) 大厂企业 (d) OSS 优先公司或基金会。
3. Q2 角色目标：(a) outreach 型 developer advocate (b) product 型 developer advocate (c) community manager (d) developer educator (e) DX engineer (f) 不确定——从资金来源驱动推荐一个。
4. Q3 资金来源驱动（预算背后的驱动）：developer adoption、sales enablement、developer enablement、product input、ecosystem/partnerships、contributor community、employer branding。
5. Q4 GTM 模式：sales-led B2B、product-led（PLG）B2B、B2C/面向个人、无购买门槛的 OSS/基金会。
6. Q5 编码深度要求：这个角色是否需要交付 SDK 示例并评审 API 设计，还是只要求公开沟通能力、只需轻度代码。
7. Q6 团队阶段：首位 DevRel 招聘（没有现任者可供校准），还是可复制招聘（有现有 top performer 可对标）。
8. Q7 薪酬立场：是否在启事中公布区间，是否了解招聘所在地的薪酬透明法规要求。
9. Q8 截止时间：本月、本季度，还是无硬性日期。
10. Q9 一次性招聘，还是以后还会招多个、记分卡与题库会被复用的首个岗位。
11. Q10 投入上限：每个候选人允许多少面试官工时，是否有 recruiter 或受过训练的面板。
12. Q1 决定门槛和作品集权重——加载 references/company-type-and-driver-lookup.md：创业公司招的是能自证该职能存在价值的通才；大厂把角色锚定到自家工程职级体系；OSS/基金会按贡献历史筛人，而不是看沟通包装。
13. Q2+Q3 决定招聘启事筛选什么——按 references/company-type-and-driver-lookup.md 的 per-role requirement 表执行；说不出自己瞄准哪个子角色的候选人等于全投全不匹配，说不清需要哪个子角色的启事也一样。
14. Q3+Q4 决定支柱组合，从而决定该角色被考核的指标：sales-led 偏 advocacy + sales enablement；PLG 偏 enablement + product input；B2C 偏 community + reach；OSS/基金会偏 community + advocacy。
15. 发布前做 gatekeeper 自查：是否在描述一个不可能的人——完整的多栈工程生涯加 OSS 贡献、技术写作、社区建设和活动组织，却按初级薪酬招人。
16. 发布前做 pit trap 自查："founding DevRel，无需背景"，实际却要一人包办 docs、SDK、社区、支持、售前工程和培训，且无资源、无晋升阶梯、无明确目标。
17. 核对两种失败模式共有的三个症状：偏离核心的技能强调、只有战术清单没有结果、职级与薪酬不一致；命中任一症状的启事必须在发布前重写，而不是等招不到人之后再改。
18. Q6 决定候选人画像：首位招聘要的是能在没有现成团队时自证职能价值的 builder（类似公司首位销售），权重放在自驱与广度而非专门深度；可复制招聘则从本公司 top performer 身上抽取该岗位真正负责支柱的画像。
19. Q7 触发质量关卡里的薪酬关卡——绝不臆造某司法辖区的法律要求；发布前确认招聘地当前的薪酬透明规则。
20. Q8 推动走快速方案：本月截止时优先复用现有题库和更短的流程，而不是从零设计定制工作样本。
21. Q9 决定工作样本是否做薄：一次性招聘就廉价地设计一次；会复用的招聘则先把冻结的 rubric 和题库建好，服务该支柱未来每一次招聘。
22. Q10 意味着删环节而不是重排环节：面试官工时只有个位数时，砍到记分卡 + 一轮结构化对话 + 作品集评估；宁可完全不做 live work sample，也不要做了却不评分。
23. 按顺序产出四件套，每件交付后先与用户确认，通过后再进入下一件。
24. 先运行 Interview，用一小段话给出角色与支柱组合建议，让用户可以否决。
25. Artefact 1 角色记分卡与招聘启事：依据 references/company-type-and-driver-lookup.md 与 references/scorecard-and-posting-template.md 构建，写一句点名 Q3 资金驱动的使命。
26. 写 3-8 条可衡量的结果，按重要性排序并量化（例如 "通过交付 friction-log 修复，把 top-three 上手支持帖减少 25%"、"第一年从社区获取 40 个被接受的 CFP"），绝不写模糊职责。
27. 写 5-7 项能力，并按 Q1-Q2 得出的角色与公司类型加权。
28. 发布启事前再跑一遍 gatekeeper/pit-trap 自查。
29. Artefact 2 面试流程与题库：依据 references/interview-loop-and-question-bank.md 构建，从该领域已验证的形式里挑 3-5 种（presentation round、content take-home、coding take-home、technical self-rating、conversational rounds、DevRel-opinion round、创业公司的 founder/exec round）——没有标准流程，要选真正测该岗位支柱组合的形式，绝不默认整套上。
30. 把作品集评估（Artefact 3）放在流程前段，在任何向候选人索要新产出之前完成。
31. 每个记分卡能力从参考文件的分类题库写 2-3 个问题，并至少包含一个 DevRel-opinion 问题——候选人反馈它是最难的一轮，因为没有被背诵的答案，这正是它能把真实立场与排练过的 pitch 区分开的原因。
32. 定义评分机制：每位面试官在进入任何 debrief 之前先独立打分并附证据记录，随后按记分卡预设权重机械合并（结构化、独立评分、机械合并的面试优于非结构化与整体讨论式 debrief，这是通用的雇佣选拔结论，不是 DevRel 专有，但完全可直接迁移）。
33. 公开作品集已存在时，绝不索取无偿 spec work；改为提供付费的 live working session。
34. Artefact 3 作品集与工作样本评估：依据 references/portfolio-and-work-sample-scoring.md 构建，用六信号分布 rubric（public writing、public speaking、code in public、community evidence、teaching artefact、developer-voice artefact）对候选人已发布的公开作品打分，并按 Q2 的目标子角色加权（完整 rubric 与评分档在 devrel-career，本技能从评估方应用它）。
35. 作品集薄弱或候选人是领域新人时，设计有偿、按固定 rubric 计分的工作样本，而不是只看简历——短 lightning-talk 环节、文档修改练习，或"向开发者解释这个 API 变更"练习，匹配目标子角色。
36. 存在负面信号时明确点名（只有粉丝数没有实质内容、只自我推广、没有 shipped code、说不出帮过哪个开发者），而不是只列缺了什么。
37. Artefact 4 30-60-90 ramp plan：依据 references/ramp-plan-template.md 构建；Day 0-30 让新人以开发者视角使用产品并交付一份 friction log（devrel-career 推荐它作为作品集物件，这里作为前 30 天的交付物）。
38. Day 31-60 在目标支柱上交付第一个公开或内部产出，与现有团队成员结对完成。
39. Day 61-90 自主负责一个常态化项目的切片，并为该岗位资金驱动对应的指标写出成文计划。
40. 如果用户还没确定去哪里找候选人，用 references/sourcing-channels.md 给出 sourcing 渠道。
41. 交付前对四件套跑质量关卡，迭代直到全部通过。
42. 如果 harness 有持久记忆，把记分卡、冻结的题库、流程设计和 ramp 里程碑存下来，供同岗位后续招聘复用，而不是每次从零开始。
43. 不要把招聘启事模板跨公司类型搬运：同一个 title 在创业公司、成长期公司、大厂和 OSS 优先基金会是完全不同的工作，各自期望的作品集门槛和编码深度都不同（完整对照表、四大支柱与七个资金驱动见 references/company-type-and-driver-lookup.md）。
44. 基金会与 OSS 邻接的大使型角色常常是无偿的、以可衡量贡献而非沟通技巧作为门槛；写带薪岗位的要求前先确认是哪种角色，反之亦然。
45. 质量关卡 1：记分卡有 3-8 个结果，每条都量化并排序，且点名 Q3 的资金驱动。
46. 质量关卡 2：启事通过 gatekeeper/pit-trap 自查——无偏离核心技能、无"有战术无结果"清单、职级与所标薪酬一致。
47. 质量关卡 3：每个面试问题都映射到记分卡上点名的能力；同一套问题适用于该岗位的所有候选人。
48. 质量关卡 4：流程至少含一种真正测目标支柱的形式（outreach 重角色用 presentation round，DX/product 重角色用 coding take-home），绝不照搬通用套件。
49. 质量关卡 5：公开作品集证据已存在时，没有任何环节索取无偿 spec work。
50. 质量关卡 6：面试官在 debrief 前提交独立、带证据的打分；最终按预设权重机械合并。
51. 质量关卡 7：作品集评估按六信号 rubric 打分，按目标子角色加权，存在负面信号时明确点名。
52. 质量关卡 8：若设计了 live work sample，它按固定 rubric 计分且付费，绝不当免费试用劳动。
53. 质量关卡 9：启事陈述真实薪酬立场（公布区间，或明确说明为何设门槛），与 Q7 的司法辖区答案一致——绝不写 "competitive" 却没有数字也没有理由。
54. 质量关卡 10：ramp plan 含 day-30 friction log 交付物、day-60 shipped artefact 里程碑、day-90 自主 ownership 里程碑。
55. 质量关卡 11：本技能输出中每条"什么算好"的说法都可追溯到具名来源，或明确标注为技能自身的工作假设——该领域没有唯一权威的职业阶梯机构，未标注的说法会显得比实际更确定。
56. 修复 gatekeeper 启事：把偏离核心的要求清单砍到支柱组合真正需要的范围，并按真实要求重新定价职级。
57. 修复 pit-trap 启事：明确写出资源、晋升阶梯和 12 个月目标，否则推迟招聘直到它们存在。
58. 修复照抄通用工程或市场 JD 模板：从资金驱动和支柱组合重建；DevRel 的结果和能力不对应这两种模板。
59. 修复凭简历判断：在任何对话轮之前先跑六信号作品集评估。
60. 修复无偿 spec-work 试镜：改为付费 live working session，或直接评估候选人已有的公开作品集。
61. 修复集体 debrief 后给一个混合的直觉分：讨论前先独立、带证据打分，再机械合并。
62. 修复对所有 DevRel 子角色套同一流程：按目标子角色实际被筛选的要求选题型和问题。
63. 修复 "Competitive compensation" 无区间无理由：公布区间或明确说明设门槛的原因，并对照当地现行要求核对。
64. 修复 ramp plan 没有产出物里程碑：day 30 锚在 shipped friction log，day 60 锚在 shipped 支柱产出，day 90 锚在自主 ownership。
65. 修复把 title 视为跨公司类型通用：复用任何旧启事前，先按 Q1 的公司类型行重新校准整个记分卡。

适用边界 · 注意事项

• 用户是在求职/准备 DevRel 面试或评估某个招聘启事是否值得投递时（候选人侧）——改用 samber/developer-relations-skills@devrel-career。
• 需要决定 DevRel 汇报线和团队结构时——组织设计应先由 samber/developer-relations-skills@devrel-team-structure 决定，本技能只负责往既定组织里招人。
• 目标是设计无偿的基金会/OSS 大使或志愿项目时——不要套用带薪岗位的记分卡与要求，反之亦然。