developer-platform-hiring

开发者平台招聘

构建招聘经理招募开发者平台岗位所需的材料：依据公司自身类型校准的评分卡、基于该领域实际采用的 API 设计与系统设计划分构建的面试流程、寻访计划，以及参照通用工程或产品经理职级体系而非专门的平台职称制定的薪酬立场。

以下内容不在范围内，请转交给其他技能：

• 辅导候选人 - samber/developer-platform-skills@developer-platform-career 是此技能的镜像。
• 招聘开发者布道师、社区经理、开发者教育者，或 DevRel 专属类型的 DX 工程师 - samber/developer-relations-skills@devrel-hiring。这些岗位主要考察沟通和社区运营能力；此技能涉及的岗位主要考察 API 和系统设计判断力。

如果用户是在求职而非招聘，请用一句话说明，并引导他们前往 developer-platform-career。

先厘清“平台工程师”的含义

在业内其他地方，“平台工程师”和“平台工程”绝大多数指的是内部开发者平台：自助式基础设施、CI/CD、Kubernetes 抽象层，以及为公司自己的应用工程师打造的黄金路径。PlatformCon 是这一领域的旗舰社区，服务的正是这类群体，规模达 280,000 多名从业者——其涵盖的内容与此技能负责招聘的岗位毫无关联。

在开始构建任何内容之前，先问：这个岗位所构建产品的主要使用者是谁——公司的内部工程团队，还是公司外部的开发者（客户、合作伙伴、第三方应用开发者）？内部使用者 -> 内部平台工程，完全不在此技能范围内。外部使用者 -> 适用此技能。

在 PlatformCon 相关渠道（Backstage 社区、内部 IDP 招聘网站）发布岗位或搜寻候选人，会为外部 API 平台招聘带来错误的候选人群体。

**记忆（建议）：**如果记忆保存在文件中，可以考虑使用 developer-platform-context.md；如果使用其他记忆系统，则以该系统为准。该文件仅供参考，并非强制要求。将不同任务的信息分别放在不同章节中。完成的任务应予以删除。为任务添加日期；一般项目背景无需添加日期。有些面试答复可能会因任务不同而有所差异。

面试

一次只问一个问题，尽可能采用选择题。跳过已回答的问题。问题 7-9 用于重新排列下方材料的优先级。

1. 公司类型：(a) 基础设施/API 优先型公司，API 就是产品 (b) 在现有产品上附加公共 API 的公司 (c) 拥有大型合作伙伴/ISV 生态系统的企业平台 (d) 尚未确定——根据岗位描述推荐一种。
2. 目标岗位方向：(a) API 产品经理 (b) 平台工程师/架构师 (c) 合作伙伴工程师，面向合作关系 (d) 集成工程师，侧重架构 (e) 尚未确定。
3. 目前有多少人端到端负责 API？这是第一个专职招聘，还是现有平台团队的扩员？（Postman 的数据显示，84% 的 API 团队有 1-9 人；对于附加 API 的公司而言，首个专职招聘会实质性改变资源配置，并非例行补员。）
4. 这个岗位需要以什么指标衡量——API 设计质量和契约稳定性、路线图和变现成果，还是明确的合作伙伴指标（支持的合作伙伴数量、交付的集成数量、使用量增长）？
5. 这个岗位实际会有多少人力和预算——独立负责、小型团队，还是与现有工程人员共享？
6. 薪酬立场：你有大致范围吗？薪酬是参照公司的通用工程/产品经理职级体系，还是依据专门的“平台工程师”招聘标准？
7. 截止时间：本月、本季度，还是没有硬性日期？
8. 这是一次性招聘，还是首次招聘多人，并且会重复使用评分卡和面试流程？
9. 工作量上限：每位候选人可以投入多少面试官小时？是否有招聘人员？

解读答案

• Q1 决定评分卡模板和合理门槛 - 加载 references/company-type-hiring-bar.md。基础设施/API 优先型招聘需要最高的技术深度；附加型招聘通常会纳入常规后端招聘，而不是单独寻找专才；企业生态系统型招聘则需要 GitLab 职位序列所筛选的关系维护与技术能力兼备的人才。
• Q2 决定适用哪种面试流程设计 - 各招聘方向的面试形式见下文的“工作流”。
• Q3 是检查范围是否过度收缩，而不只是收集一项数据。 如果答案是“一个人将负责设计、合作伙伴集成和面向开发者的内容”，那么这份招聘启事很可能是在一个职位上要求完成三份全职工作 - 下文“解读招聘启事”中的危险信号部分对此有说明。
• Q4 确定评分卡的结果指标 - 绝不要写泛泛的“负责 API”；应明确指出衡量此职位的实际指标。
• Q5 用于检查是否存在该领域真实的危险信号模式：要求一名独立招聘的人同时负责 API 设计、合作伙伴集成和面向开发者的营销，却不给团队或预算，这种整合模式正是该领域的结构性数据所反映的情况。
• Q6 会触发质量门槛中的薪酬审核 - 以同等职级的通用工程或 PM 薪酬阶梯为基准，绝不要参照专门搜索平台职位名称的结果。
• Q7 倾向于复用现有面试流程，而不是从头设计。
• Q8 决定面试流程是保持精简（一次性需求），还是完善构建（可复用需求）。
• Q9 会删除面试流程环节，而不是调整顺序，这与销售招聘和 DevRel 招聘在面试官时间预算紧张时的做法相同。

工作流

1. 开展访谈。用一段简短的话说明公司类型和岗位方向的校准结果，供用户否决。
2. 产出物 1 - 岗位评分表。 根据 references/company-type-hiring-bar.md 编制：
   • 用一句话写明使命，并点出公司类型和 Q4 中的指标
   • 列出 3-8 项可衡量的成果，切勿使用“负责平台”等含糊的职责描述
   • 根据岗位方向确定各项能力的权重：API PM 评分表应侧重路线图和变现判断；Platform Engineer/Architect 评分表应侧重 API/系统设计和基础设施交付；Partner Engineer 评分表应侧重关系管理；Integration Engineer 评分表应侧重架构和可靠性
3. 产出物 2 - 面试流程。 根据 references/interview-loop-design.md 编制：
   • 工程岗位招聘采用 API 设计面试形式（不同于大型公司的通用系统设计面试），评估重点是面向开发者的易用性和抗误用能力，而非纯粹的规模权衡
   • 对于 API PM，按照 Google 和 Uber 各自开展 PM 面试的方式，将范围界定和设计思维轮次的权重设得高于编程轮次
   • 对于 Partner/Integration Engineer，采用 GitLab 实际发布的招聘流程：招聘人员电话面试、招聘经理面试、2-5 轮团队面试，高级岗位还可能有高管面试
   • 明确说明：目前没有任何地方发布了适用于所有岗位方向、完整记录且专门针对开发者平台的单一面试流程——这是整合设计，不是对行业标准流程的照搬
4. 产出物 3 - 招聘渠道计划。 根据 references/sourcing-channels.md 编制：
   • 确认将 apidays 作为招募 API 平台工程师和 API 产品经理的活动场地；切勿选择服务内部 IDP 群体的 PlatformCon
   • 对于 Platform Engineer 和 Integration Engineer 岗位方向，通用高级后端工程师招聘渠道（推荐网络、高级个人贡献者人才库、以开源贡献记录作为筛选条件）比邻近 DevRel 的渠道更有效
   • 对于 API PM 岗位方向，使用通用技术产品管理招聘渠道，并筛选具有 API 或面向开发者的产品经验的人选
5. 产出物 4 - 薪酬立场。 根据 references/compensation-guidance.md 编制：
   • 以公司同级别通用软件工程或通用产品管理薪酬区间作为报价基准；切勿依据专门搜索“platform engineer”或“API product manager”职位名称得出的数据，因为这类数据来自众包且十分稀少
   • 将 GitLab 或 Stripe 自身的职级体系作为有来源依据的示例，切勿将其说成通用标准
6. 执行下方的质量关卡。反复迭代，直至通过。
7. 如果你的执行环境具备持久化记忆，将评分表、面试流程设计和招聘渠道计划保存起来，以便重复招聘时复用。

阅读招聘信息，识别危险信号

目前还没有适用于开发者平台岗位、具名且有来源的招聘危险信号分类体系，不同于 DevRel 已有记录的把关者／陷阱框架——应当坦率说明这一点，而不是引用不存在的来源。现有结构性数据支持的是一种不同的模式，而非换个标签套用同一种模式：

• 这种模式：一则招聘信息把构建工作（API／架构设计、合作伙伴集成架构）和外联工作（开发者营销、内容）叠加在一起——这是跨学科的职责范围坍缩，而非同一学科内的职责坍缩。与 DevRel 的把关者模式不同，其中列出的每项技能，确实都可能由一位优秀候选人掌握；问题在于三个全职岗位的执行工作量被塞进了一个岗位，而不是列出了一份不可能胜任的技能清单。
• 症状：招聘信息列出的成果分属三个不同职能（已发布的 API、明确数量的合作伙伴集成，以及内容或社区指标），却未说明未来拆分职责所需的人员编制计划；职位名称暗示 IC 工程师的资深程度，但职责读起来却像是产品经理的工作，再叠加 DevRel 的工作；没有说明明确的汇报关系，也没有列出将团队从一人扩大的预算。

应当坦率说明，这种模式是根据 Postman 小团队数据以及与 DevRel 分类体系的跨仓库类比得出的结构性推断，并非有名称且被引用的行业诊断——除非后续核查找到了真实且有来源的案例。发布招聘信息前，应按照这一模式进行自查；若未通过，就应把职责拆分到多个招聘岗位，或明确说明资源配置，再发布招聘信息。

公司类型与岗位轨道校准

切勿认为同一套评分卡模板适用于所有公司类型——完整对比及 84% 小团队这一发现见 references/company-type-hiring-bar.md。

质量门槛

最终交付前，按照以下检查项对招聘材料进行评分。

1. 招聘信息或评分卡明确说明，该岗位指内部 IDP 还是外部 API 平台工程。
2. 评分卡列出实际的公司类型以及该岗位的衡量指标，并量化每项成果。
3. 招聘信息通过职责范围坍缩自查——没有未说明人员编制计划的构建与外联工作叠加。
4. 面试设计与岗位轨道相匹配——工程轨道采用 API 设计形式；PM 轨道采用范围界定／设计思维环节；Partner/Integration Engineer 采用 GitLab 的结构化流程。
5. 根据需要通过 apidays 或通用资深后端／PM 渠道寻找候选人——招聘外部 API 岗位时，绝不使用 PlatformCon。
6. 薪酬定位以公司的通用工程师或 PM 职级体系为基准，并注明来源和日期；绝不把混合数据或按定制职位名称搜索得出的数字当作市场薪酬。

常见失败模式

失败情况	解决方法
为招聘外部 API 平台人才，在 PlatformCon 或内部 IDP 渠道寻找人选	改用 apidays 和通用的资深后端／PM 渠道
预期一名员工在没有团队或预算的情况下，独自负责 API 设计、合作伙伴集成和面向开发者的内容	将工作范围拆分给多名员工，或在招聘信息中明确说明所需资源
为考察 API 设计判断力的职位照搬通用的系统设计面试	采用 API 设计面试形式，以面向开发者的易用性和抗误用能力作为评判标准
引用众包网站上针对定制化“平台工程师”职位的薪资数字	以公司通用的工程／PM 职级体系中相当级别的薪酬为基准
将 GitLab 或 Stripe 发布的职级体系视为全行业通用标准	将其表述为一个有来源的案例，而非标准
在已有 1-9 人负责整个 API 范围的公司招聘三个专业岗位（API 产品经理、架构师、合作伙伴工程师）	先确认公司类型，再根据实际团队规模确定招聘人数，参照公司类型说明

参考资料

• references/company-type-hiring-bar.md - 三种公司类型、84% 小团队这一发现，以及职责范围收缩的前提条件。
• references/interview-loop-design.md - API 设计与系统设计的区别、各岗位的面试流程设计，以及 GitLab 实际发布的面试流程。
• references/sourcing-channels.md - apidays、PlatformCon 的注意事项，以及为何这类人才更常通过资深后端工程渠道而非 DevRel 渠道招募。
• references/compensation-guidance.md - 通用职级体系相关发现的完整内容，以及获取实时薪酬数据时需要核查的事项。
• 另请参阅 samber/developer-platform-skills@developer-platform-career，了解候选人一方在这张表中的情况。
• 另请参阅 samber/developer-relations-skills@devrel-hiring，了解招聘信息可能与平台岗位混淆的 DevRel 型职位——上文提到的职责范围收缩风险信号，通常就是这种混淆的表现。