devrel-hiring

DevRel 招聘

构建招聘经理招募 DevRel 人员所需的四项材料，并遵循该领域自身招聘研究建议的严谨标准：岗位评分卡与招聘启事、结构化面试流程与问题库、作品集与工作样本评估，以及 30-60-90 天成长计划。

DevRel 没有标准的职位描述或职业阶梯（CNCF CTO Chris Aniszczyk），其招聘文献也记录了两种特定的失败模式：招聘启事若缺乏这种严谨性，便会出现这些问题——参见「阅读答案」。正因如此，我们应有意构建这四项材料，而不是套用通用的工程或市场招聘模板。

以下内容不在范围内，请另行处理：

• DevRel 的汇报关系和团队构成——samber/developer-relations-skills@devrel-team-structure 会先确定组织架构，本技能再据此开展招聘。
• 为候选人提供辅导——samber/developer-relations-skills@devrel-career 与本技能互为镜像，面向接受评估的人士。

如果用户是在求职，而不是招聘（“我该如何准备 DevRel 面试”“这份招聘启事值得申请吗”），请用一句话说明，并引导他们查看 devrel-career。

访谈

一次只问一个问题，尽可能使用选择题。跳过已回答的问题。问题 8-10 会在构建任何材料之前重新确定以下材料的优先级——请先问这些问题。

记忆：记录当前任务或项目背景的少量信息。如果记忆保存在文件中，请使用 devrel-context.md；如果使用其他记忆系统，则依赖该系统。将不同任务的信息放在不同的部分。任务完成后删除相关信息。为任务添加日期；一般项目背景不添加日期。不同任务的部分访谈回答可能不同。

1. 公司类型：(a) 早期创业公司，pre-seed-A 阶段，DevRel 团队只有一人；(b) 成长期/规模化阶段，B-D 轮；(c) 大型科技企业；(d) 开源优先的公司或基金会。
2. 目标岗位：(a) 开发者布道师，侧重对外拓展；(b) 开发者布道师，侧重产品；(c) 社区经理；(d) 开发者教育者；(e) DX 工程师；(f) 不确定——根据资金驱动因素推荐一个岗位。
3. 什么因素为这个岗位提供资金支持——即预算背后的驱动因素：开发者采用、销售赋能、开发者赋能、产品反馈、生态系统/合作伙伴关系、贡献者社区，还是雇主品牌？
4. go-to-market 模式：销售驱动型 B2B、产品驱动增长（PLG）B2B、面向消费者/个人，还是没有购买门槛的开源/基金会模式？
5. 编码深度要求：这个岗位是否需要交付 SDK 示例并审查 API 设计，还是只需具备公开沟通能力，只涉及少量代码？
6. 团队阶段：这是首位 DevRel 招聘，没有现任员工可供校准；还是重复招聘，可依据现有优秀员工建立画像？
7. 薪酬政策：是否会在招聘启事中公布薪资范围？是否了解招聘所在地的薪酬透明度要求？
8. 截止时间：本月、本季度，还是没有硬性日期？
9. 是一次性招聘，还是后续还会招聘多位，并重复使用评分卡和问题库？
10. 工作量上限：每位候选人的面试官总投入时间是多少小时？是否有招聘人员或经过培训的面试小组？

解读答案

• 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 贡献、技术写作、社区建设和活动组织经验，却按入门级薪酬招聘。
  • 陷阱岗位——“无需经验的创始 DevRel 岗位”，实际却要求一个人负责文档、SDK、社区、支持、销售工程和培训，既没有资源，也没有晋升阶梯，更没有明确目标。
  • 两者有三个共同症状：强调非核心技能、罗列策略却没有明确成果，以及职级与薪酬不符。招聘启事只要出现其中任何一种症状，就必须在发布前重写，而不是等到招聘无法转化后再改。
• Q6 决定候选人画像。 首位员工：招聘一位能在没有现有团队的情况下证明该职能存在价值的建设者，类似公司的首位销售员工——相比专业深度，更看重自主性和广度。后续招聘：根据组织内在该岗位实际负责支柱上的顶尖员工来确定画像。
• Q7 触发下方质量门槛中的薪酬检查——绝不臆测某司法辖区的法律要求；发布前确认招聘所在地当前的薪酬透明规则。
• Q8 优先选择能快速执行的方案：如果截止日期在本月内，优先复用现有题库并缩短流程，而不是从头设计新的定制工作样本。
• Q9 决定工作样本是否保持精简。 一次性招聘：以低成本设计一次即可。长期持续招聘：冻结的评分标准和题库可用于该支柱未来的每次招聘，因此应优先把两者都做好。
• Q10 应删除面试流程环节，而不是调整顺序。 如果每位候选人可投入的面试官工时屈指可数：精简为评分卡、一轮结构化对话和作品集评估；完全跳过现场工作样本，也不要进行不评分的现场测试。

工作流

按顺序生成四份产物。每完成一份，就交付给用户并请其验证，然后再继续下一份。

1. 进行访谈。用一段简短的话说明职位和支柱组合建议，并允许用户否决。
2. 产物 1——职位记分卡和招聘启事。 根据 references/company-type-and-driver-lookup.md 和 references/scorecard-and-posting-template.md 编写：
   • 用一句话写明使命，并指出 Q3 中提到的资金驱动因素
   • 列出 3-8 项按重要性排序且量化的可衡量成果（例如：“通过发布一项摩擦日志修复，将排名前三的入门支持帖减少 25%”“第一年从社区征集到 40 份获接纳的 CFP”），绝不写含糊的职责
   • 根据 Q1-Q2 中的职位和公司类型，为 5-7 项能力设定权重
   • 发布前，先运行上文的守门人／陷阱自查
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；本技能从评估者的角度应用该标准
   • 作品集内容较少或候选人刚进入该领域时，应设计有评分且有偿的工作样本，而不是只凭简历判断——可选用简短的闪电演讲轮、文档编辑练习，或“向开发者解释这项 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. 如果你的运行环境支持持久化记忆，请保存记分卡、定稿的问题库、面试流程设计和融入计划的里程碑，以便之后招聘同一职位时复用，而无需从头开始。

公司类型和资金驱动因素

切勿将招聘模板视为可在不同公司类型间通用：同一个职位名称，在初创公司、成长期公司、大型科技供应商和 OSS 优先的基金会中代表的工作各不相同，而且每种公司对作品集门槛和编码深度的要求也不同。完整的对比表、四大支柱，以及用于预测职位考核内容的七个资金驱动因素，请参阅：references/company-type-and-driver-lookup.md。

基金会和 OSS 相关的品牌大使类职位通常不带薪，录用依据是可量化的贡献，而非沟通能力。在将带薪职位的要求写入无薪项目，或反向操作之前，务必先确认职位类型。

质量门槛

在最终交付前，根据以下检查项评估四项产出。不断迭代，直至所有检查项均通过。

1. 评分卡包含 3–8 项成果，每项都经过量化和排序，并且指出 Q3 中的资金驱动因素。
2. 招聘启事通过把关者／陷阱自查：不强调核心工作以外的技能，不罗列缺乏成果支撑的策略，职级与所述薪酬一致。
3. 每道面试题都对应一项具名的评分卡能力；该职位的所有候选人均使用同一组问题。
4. 面试流程至少包含一种能实际检验目标支柱的形式（例如，针对外联工作占比较高的职位，设置演讲环节；针对 DX／产品导向的职位，设置编码带回作业），绝不无视职位特点而照搬通用题目。
5. 如果已有公开作品集证据，任何环节都不得要求候选人无偿完成定制测试任务。
6. 面试官须在任何复盘讨论前独立提交附有证据说明的评分；最终综合评分须严格按照预设权重机械计算。
7. 作品集评估须按照六项信号的评分标准进行，并根据目标子职位加权；如有负面信号，须明确指出。
8. 如果设计了现场工作样例，须按固定评分标准进行评分并支付报酬，绝不能将其视为免费试用工作。
9. 招聘启事须说明实际的薪酬安排（公布薪酬范围，或明确说明薪酬为何受限），并与 Q7 中关于司法管辖区的回答一致——绝不能在没有具体金额且未说明原因的情况下，仅写“有竞争力”。
10. 入职计划须包含第 30 天提交的摩擦记录、第 60 天交付的已上线成果，以及第 90 天达成的自主负责里程碑。
11. 本技能自身输出中关于“优秀表现”的所有说法，都须能追溯到明确列出的来源，或明确标注为本技能的工作假设——该领域没有唯一权威的职业发展阶梯体系，因此未标注的说法会显得比实际更确定。

常见失败模式

不作排名，刻意如此：每一行都是一项缺陷，并且都必须修复。

失败	修复
把关式招聘信息	将非核心要求列表精简至支柱组合实际需要的程度；根据真实要求重新评定职级
设陷阱式招聘信息	明确说明资源、晋升阶梯和十二个月目标，否则等条件具备后再招聘
复制通用的工程或营销职位描述模板	根据资金驱动因素和支柱组合重新编写；DevRel 的成果和能力与这两种模板都不匹配
根据简历而非已交付的工作进行评判	在任何对话轮次之前，先进行六项信号的作品集评估
无偿试做面试	提供有偿的现场工作环节，或直接评审现有的公开作品集
小组复盘后给出一个混合的直觉评分	讨论前独立评分并记录证据，再以机械方式合并
对所有 DevRel 子角色采用相同的面试流程	根据目标子角色实际筛选的要求选择形式和问题
只写“有竞争力的薪酬”，不写范围，也不说明原因	公布薪酬范围，或明确说明为何暂不公开，并根据所在司法辖区当前的具体要求核查
入职计划没有交付物里程碑	将第 30 天锚定为交付摩擦日志，第 60 天锚定为交付支柱成果，第 90 天锚定为自主负责
认为职位头衔在不同类型的公司之间通用	在复用任何过往招聘信息前，先根据 Q1 的公司类型行重新校准整套评分卡

参考资料

• 有关公司类型比较表、四大支柱和七项资金驱动因素，请参阅 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。
• 有关完整的 30-60-90 模板，请参阅 references/ramp-plan-template.md。
• 有关实际寻找 DevRel 候选人的渠道，请参阅 references/sourcing-channels.md。
• 候选人侧的相关内容——作品集构建、面试准备、录用通知评估——请参阅 samber/developer-relations-skills@devrel-career；此技能不会为候选人提供指导。
• 有关此职位所属的组织设计和汇报关系，请参阅 samber/developer-relations-skills@devrel-team-structure；这些内容应在此技能应用前决定，而非由此技能决定。
• 有关录用后评分卡成果应保持一致的衡量框架，请参阅 samber/developer-relations-skills@devrel-metrics。
• 有关候选人在接受录用前会查看的雇主品牌展示面，请参阅 samber/developer-relations-skills@tech-employer-branding。