Back to Details

developer-platform-hiring

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Developer Platform Hiring

开发者平台岗位招聘

Build the artefacts a hiring manager needs to recruit a developer-platform role: a scorecard calibrated to the company's own archetype, an interview loop built on the API-design-vs-system-design split this field actually uses, a sourcing plan, and a compensation stance anchored to the general engineering or PM ladder rather than a bespoke platform title.
Out of scope, hand off instead:
  • Coaching the candidate - samber/developer-platform-skills@developer-platform-career is the mirror image of this skill.
  • Hiring a developer advocate, community manager, developer educator, or DevRel's own flavor of DX engineer - samber/developer-relations-skills@devrel-hiring. Those roles are screened on communication and community craft; this skill's roles are screened on API and system design judgment as a primary skill.
If the user is job-hunting rather than hiring, say so in one line and route them to developer-platform-career.
构建招聘经理在招募开发者平台岗位时所需的交付物：根据公司自身类型校准的评分卡、基于本领域实际使用的API设计与系统设计之分的面试流程、寻源方案，以及锚定到通用工程或产品管理职级体系而非自定义平台头衔的薪酬定位。
不在范围内，改由以下skill处理：
  • 辅导候选人 - samber/developer-platform-skills@developer-platform-career 是本skill的镜像。
  • 招聘开发者布道师、社区经理、开发者教育者，或DevRel自身的DX工程师 - samber/developer-relations-skills@devrel-hiring。这些岗位以沟通和社区能力为筛选标准；本skill的岗位以API和系统设计判断作为主要筛选标准。
如果用户是在求职而非招聘，请用一句话说明，并将他们引导到developer-platform-career。

Disambiguate "platform engineer" first

先澄清“平台工程师”

"Platform engineer" and "platform engineering" overwhelmingly mean internal developer platforms elsewhere in the industry: self-service infrastructure, CI/CD, Kubernetes abstractions, golden paths built for a company's own application engineers. PlatformCon, the flagship community for that term, serves exactly that audience at a scale of 280,000+ practitioners - and covers none of what this skill hires for.
Ask, before building anything: who is the primary consumer of what this role builds - the company's own engineering teams, or developers outside the company (customers, partners, third-party app builders)? Internal consumer -> internal-platform engineering, entirely outside this skill's scope. External consumer -> this skill.
Posting a role or searching for candidates on PlatformCon-adjacent channels (Backstage community, internal-IDP job boards) surfaces the wrong applicant pool for an external-API-platform hire.
“平台工程师”和“平台工程”这个术语在业内绝大多数情况下指的是内部开发者平台：自助服务基础设施、CI/CD、Kubernetes抽象层、为公司自己的应用工程师构建的黄金路径。PlatformCon是该术语的标志性社区，服务的正是这一人群，规模超过280,000名从业者——与本skill所招聘的岗位完全无关。
在构建任何内容之前，先问：这个角色所构建的东西，主要使用者是谁——公司自己的工程团队，还是公司外部的开发者（客户、合作伙伴、第三方应用开发者）？内部使用者 -> 属于内部平台工程，完全不在本skill范围内。外部使用者 -> 属于本skill。
在PlatformCon相关渠道（Backstage社区、内部IDP招聘板）发布岗位或搜索候选人，会为外部API平台岗位带来错误的候选人池。

Interview

访谈

Ask one question at a time, multiple-choice where possible. Skip anything already answered. Questions 7-9 re-rank the artefacts below.
  1. Company archetype: (a) an infrastructure/API-first company where the API is the product (b) a company bolting a public API onto an existing product (c) an enterprise platform with a large partner/ISV ecosystem (d) undecided - recommend one from the description of the role.
  2. Target role track: (a) API Product Manager (b) Platform Engineer/Architect (c) Partner Engineer, relationship-facing (d) Integration Engineer, architecture-focused (e) undecided.
  3. How many people currently own the API surface end to end - is this a first dedicated hire, or an addition to an existing platform team? (Postman's data puts 84% of API teams at 1-9 people; a first dedicated hire for a bolt-on company is a real resourcing shift, not a routine backfill.)
  4. What does this role need to be measured on - API design quality and contract stability, roadmap and monetization outcomes, or named partner-facing metrics (partners supported, integrations shipped, usage growth)?
  5. How many people and what budget will this role actually have - solo ownership, a small team, or shared with existing engineering staff?
  6. Compensation stance: do you have a range in mind, and is it anchored to the company's general engineering/PM ladder or to a bespoke "platform engineer" search?
  7. Deadline: this month, this quarter, or no hard date?
  8. One-off hire or the first of several where the scorecard and loop get reused?
  9. Effort ceiling: how many interviewer-hours per candidate, and is there a recruiter?
一次问一个问题，尽可能使用选择题。已经回答过的跳过去。问题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人；对附加型公司来说，第一个专职岗位意味着真正的资源投入转变，而不是常规补缺。）
  4. 这个岗位需要用哪些指标来衡量——API设计质量和契约稳定性、路线图和变现成果，还是具体的合作伙伴指标（支持的合作伙伴数、上线的集成数、使用量增长）？
  5. 这个岗位实际会有多少人和多少预算——独立负责、一个小团队，还是与现有工程人员共享？
  6. 薪酬定位：你心里有区间吗？是对齐公司通用工程/产品管理职级体系，还是自定义“平台工程师”搜索？
  7. 截止时间：本月、本季度，还是没有硬性日期？
  8. 是一次性招聘，还是多次招聘中的第一次（评分卡和面试流程会被复用）？
  9. 投入上限：每个候选人有多少面试官小时，是否有招聘官？

Reading the answers

解读回答

  • Q1 decides the scorecard template and realistic bar - load references/company-type-hiring-bar.md. An infra/API-first hire needs the highest technical depth; a bolt-on hire is usually folded into general backend hiring rather than a dedicated specialist search; an enterprise-ecosystem hire needs the relationship-plus-technical hybrid GitLab's job family screens for.
  • Q2 decides which loop design applies - see Workflow below for the per-track interview shape.
  • Q3 is the scope-collapse check, not just a data point. If the answer is "one person will own design, partner integrations, and developer-facing content," the posting is very likely asking for three full-time jobs in one seat - see Reading a posting for red flags below.
  • Q4 sets the scorecard's outcome metrics - never write a generic "own the API" outcome; name the actual thing this role is measured on.
  • Q5 is the check against the field's real red-flag pattern: a solo hire expected to own API design, partner integrations, and developer-facing marketing simultaneously with no team or budget is the consolidation pattern this field's structural data implies.
  • Q6 triggers the compensation gate in the Quality gate - anchor to the general engineering or PM ladder at the equivalent level, never to a bespoke platform-title search.
  • Q7 promotes reusing an existing loop over designing one from scratch.
  • Q8 decides whether the loop stays thin (one-off) or gets built properly (compounding).
  • Q9 deletes loop stages rather than reordering them, the same way sales-hiring and devrel-hiring treat a tight interviewer-hour budget.
  • Q1决定评分卡模板和现实标准——加载references/company-type-hiring-bar.md。基础设施/API优先的招聘需要最高的技术深度；附加型招聘通常并入通用后端招聘，而不是专门的专家搜索；企业生态招聘需要GitLab岗位族所筛选的关系加技术混合型人才。
  • Q2决定采用哪种面试流程设计——各方向的面试形态见下方Workflow。
  • Q3是范围坍缩检查，而不仅仅是数据点。 如果答案是“一个人将负责设计、合作伙伴集成和开发者面向内容”，那么该岗位很可能是在一个职位里要求三个全职工作——见下方“识别岗位描述中的危险信号”。
  • Q4设定评分卡的结果指标——永远不要写泛泛的“负责API”这类结果；要明确指出这个岗位实际被衡量的内容。
  • Q5是对该领域真实危险信号模式的检查：一个没有任何团队或预算的独立岗位，却要同时负责API设计、合作伙伴集成和面向开发者的营销，这就是该领域结构性数据所暗示的岗位合并模式。
  • Q6触发Quality gate中的薪酬关卡——对齐同等职级的通用工程或产品管理职级体系，绝不要用自定义平台头衔搜索。
  • Q7倾向于复用现有面试流程，而不是从零设计。
  • Q8决定面试流程是保持精简（一次性）还是好好构建（可复用、持续增值）。
  • Q9会删除面试流程中的环节，而不是重新排序，这与sales-hiring和devrel-hiring在处理紧张的面试官小时预算时的方式相同。

Workflow

工作流程

  1. Run the Interview. State the company-archetype and role-track calibration in one short paragraph the user can veto.
  2. Artefact 1 - role scorecard. Build from references/company-type-hiring-bar.md:
    • a one-sentence mission naming the archetype and the metric from Q4
    • 3-8 measurable outcomes, never vague responsibilities like "own the platform"
    • competencies weighted per track - API PM scorecards weight roadmap and monetization judgment; Platform Engineer/Architect scorecards weight API/system design and infra delivery; Partner Engineer scorecards weight relationship management; Integration Engineer scorecards weight architecture and reliability
  3. Artefact 2 - interview loop. Build from references/interview-loop-design.md:
    • use the API-design interview format (distinct from general system design at major companies) for engineering-track hires, judged on developer-facing usability and misuse-resistance rather than raw scale trade-offs
    • for an API PM, weight a scoping and design-thinking round over a coding round, per how Google and Uber run their own PM loops
    • for a Partner/Integration Engineer, reuse GitLab's real posted sequence: recruiter call, hiring-manager interview, 2-5 team interviews, a possible executive round for senior hires
    • state plainly that no single, fully-documented developer-platform-specific loop exists published anywhere for every track - this is an assembled design, not a copy of an industry-standard one
  4. Artefact 3 - sourcing plan. Build from references/sourcing-channels.md:
    • use apidays as the confirmed venue for API platform engineers and API product managers - never PlatformCon, which serves the internal-IDP population
    • for Platform Engineer and Integration Engineer tracks, general senior-backend-engineering sourcing channels (referral networks, senior-IC pipelines, open-source contribution history as a screen) outperform DevRel-adjacent channels
    • for the API PM track, use general technical product-management sourcing filtered for API or developer-facing product experience
  5. Artefact 4 - compensation stance. Build from references/compensation-guidance.md:
    • anchor the offer to the company's general software-engineering or general product-management comp bands at the equivalent level - never to a bespoke "platform engineer" or "API product manager" title search, which returns sparse crowdsourced data
    • name GitLab's or Stripe's own leveling structure as the sourced example, never as a universal standard
  6. Run the Quality gate below. Iterate until it passes.
  7. If your harness has persistent memory, store the scorecard, loop design and sourcing plan for reuse on a repeat hire.
  1. 执行访谈。用一小段话说明公司类型和岗位方向校准，用户可否决。
  2. 交付物1 - 岗位评分卡。 基于references/company-type-hiring-bar.md构建：
    • 一句话使命，点明公司类型和Q4中的指标
    • 3-8个可衡量的成果，绝不用“负责平台”这类模糊职责
    • 按方向加权的胜任力——API产品经理评分卡侧重路线图和变现判断；平台工程师/架构师评分卡侧重API/系统设计和基础设施交付；合作伙伴工程师评分卡侧重关系管理；集成工程师评分卡侧重架构和可靠性
  3. 交付物2 - 面试流程。 基于references/interview-loop-design.md构建：
    • 工程方向使用API设计面试形式（区别于大厂通用系统设计），以面向开发者的可用性和抗误用性为评判标准，而不是原始规模权衡
    • 对于API产品经理，按照Google和Uber自己的PM流程做法，将范围界定和设计思维环节权重提高到编码环节之上
    • 对于合作伙伴/集成工程师，复用GitLab真实的公开招聘流程：招聘官电话、招聘经理面试、2-5轮团队面试、高级岗位可能的高管轮次
    • 明确说明：目前没有任何一个针对所有方向、已完整公开的开发者平台专属面试流程——这是一个组装出来的设计，不是行业标准的复制品
  4. 交付物3 - 寻源方案。 基于references/sourcing-channels.md构建：
    • 将apidays作为API平台工程师和API产品经理的确定渠道——绝不用PlatformCon，因为它服务的是内部IDP人群
    • 对于平台工程师和集成工程师方向，通用高级后端工程寻源渠道（内推网络、高级IC人才管道、开源贡献历史作为筛选条件）优于DevRel相关渠道
    • 对于API产品经理方向，使用通用技术产品管理寻源，并筛选有API或面向开发者产品经验的人
  5. 交付物4 - 薪酬定位。 基于references/compensation-guidance.md构建：
    • 将Offer对齐公司同等职级的通用软件工程或通用产品管理薪酬带宽——绝不要使用自定义“平台工程师”或“API产品经理”头衔搜索，因为那只会返回稀少的众包数据
    • 将GitLab或Stripe自己的职级结构作为一个有出处的示例，绝不能当作通用标准
  6. 运行下方的Quality gate。迭代直到通过。
  7. 如果你的harness有持久化记忆，请保存评分卡、面试流程设计和寻源方案，以便在重复招聘时复用。

Reading a posting for red flags

识别岗位描述中的危险信号

No named, sourced hiring-red-flag taxonomy exists yet for developer-platform roles, unlike DevRel's documented gatekeeper/pit-trap framework - say this plainly rather than citing a source that doesn't exist. What the structural data does support is a distinct pattern, not the same one relabeled:
  • The pattern: a posting stacking build work (API/schema design, partner integration architecture) with outreach work (developer marketing, content) - a scope-collapse across disciplines rather than within one discipline. Unlike DevRel's gatekeeper pattern, each individual skill listed can be genuinely held by one strong candidate; the failure is an execution-volume mismatch across three full-time jobs, not an impossible-skills list.
  • Symptoms: the posting names outcomes belonging to three different functions (a shipped API surface, a named partner-integration count, a content or community metric) with no stated headcount plan to eventually split them; the title implies IC-engineering seniority but the responsibilities read as a product-manager's job plus a DevRel job layered on top; no named reporting line or budget is stated for growing the function past one person.
State plainly that this pattern is a structural inference from Postman's small-team data and cross-repo analogy to DevRel's taxonomy, not a named, quoted industry diagnosis - unless a follow-up check finds a genuine sourced account. Before publishing a posting, self-audit against it; a posting failing the test needs the scope split across more than one hire, or the resourcing stated explicitly, before it goes out.
目前尚不存在针对开发者平台岗位的、有名有姓且有出处的招聘危险信号分类法，这与DevRel有记录的守门人/陷阱框架不同——请直说这一点，而不是引用一个并不存在的来源。结构性数据实际支持的是一个独特的模式，而不是同一个模式重新贴标签：
  • 模式：岗位描述把构建类工作（API/schema设计、合作伙伴集成架构）和外联类工作（开发者营销、内容）堆在一起——这是跨职能领域的范围坍缩，而不是单个职能领域内的范围坍缩。与DevRel的守门人模式不同，这里列出的每一项技能都确实可能由一个优秀候选人掌握；问题在于三个全职工作的执行量不匹配，而不是技能列表不可能实现。
  • 症状：岗位描述列出了属于三个不同职能的成果（一个已上线的API面、一个具名的合作伙伴集成数量、一个内容或社区指标），却没有说明最终拆分它们的编制计划；头衔暗示IC工程高级别，但职责读起来像是产品经理的工作加上一层DevRel工作；没有说明在超过一个人之后该职能的汇报线和预算。
请明确说明：这一模式是从Postman的小团队数据和与DevRel分类法的跨仓库类比中得出的结构性推断，而不是一个有名字、可引用的行业诊断——除非后续检查找到真正有出处的记录。在发布岗位描述之前，要对照它做自我审查；未通过测试的岗位描述在发布之前必须把范围拆分到多个岗位上，或明确说明资源配置。

Company type and role-track calibration

公司类型与岗位方向校准

Never treat one scorecard template as portable across company archetypes - the full comparison and the 84%-small-teams finding live in references/company-type-hiring-bar.md.
切勿将同一个评分卡模板视为可跨公司类型移植——完整对比和84%小团队的数据发现都在references/company-type-hiring-bar.md中。

Quality gate

质量关卡

Score the artefacts against these checks before final delivery.
  1. The posting or scorecard states explicitly whether the role means internal-IDP or external-API platform engineering.
  2. The scorecard names the actual company archetype and the metric this role is measured on, and every outcome is quantified.
  3. The posting passes the scope-collapse self-audit - no build-plus-outreach stack with no stated headcount plan.
  4. The interview design matches the role track - the API-design format for engineering tracks, a scoping/design-thinking round for the PM track, GitLab's structured sequence for Partner/Integration Engineer.
  5. Sourcing uses apidays or general senior-backend/PM channels as appropriate - never PlatformCon for an external-API hire.
  6. The compensation stance is anchored to the company's general engineering or PM ladder, with a named source and date, never a blended or bespoke-title-searched figure presented as market rate.
在最终交付前，用以下检查项评估交付物。
  1. 岗位描述或评分卡明确说明该岗位是内部IDP还是外部API平台工程。
  2. 评分卡明确指出公司实际类型和该岗位被衡量的指标，并且每个成果都可量化。
  3. 岗位描述通过范围坍缩自检——不能有构建加外联的堆叠且没有明确的编制计划。
  4. 面试流程设计与岗位方向匹配——工程方向使用API设计形式，PM方向使用范围界定/设计思维环节，合作伙伴/集成工程师使用GitLab的结构化流程。
  5. 寻源使用apidays或合适的通用高级后端/PM渠道——外部API岗位绝不用PlatformCon。
  6. 薪酬定位锚定到公司通用工程或产品管理职级体系，并带有具名来源和日期，绝不能用混合的或通过自定义头衔搜索得到的数字当作市场行情。

Common failure modes

常见失败模式

FailureFix
Sourcing on PlatformCon or internal-IDP channels for an external-API-platform hireUse apidays and general senior-backend/PM channels instead
Solo hire expected to own API design, partner integrations, and developer-facing content with no team or budgetSplit the scope across more than one hire, or state the resourcing explicitly in the posting
Copying a general system-design interview for an API-design-judgment roleUse the API-design format, judged on developer-facing usability and misuse-resistance
Quoting a bespoke "platform engineer" salary figure from a crowdsourced siteAnchor to the company's general engineering/PM ladder at the equivalent level
Treating GitLab's or Stripe's posted structure as a universal industry standardState it as the one sourced example, not a standard
Hiring three specialized roles (API PM, architect, partner engineer) at a company where 1-9 people already run the whole API surfaceConfirm the archetype first and size the hire to the actual team, per the company-type reference
失败模式修复方法
为外部API平台岗位在PlatformCon或内部IDP渠道寻源改用apidays和通用高级后端/PM渠道
独立岗位被期望在没有团队或预算的情况下负责API设计、合作伙伴集成和面向开发者的内容将范围拆分到多个岗位上，或在岗位描述中明确说明资源配置
为API设计判断类岗位照搬通用系统设计面试使用API设计形式，以面向开发者的可用性和抗误用性为评判标准
从众包网站引用自定义“平台工程师”薪资数字对齐公司同等职级的通用工程/产品管理职级体系
将GitLab或Stripe公开发布的结构当作通用行业标准将它作为一个有出处的示例，而不是标准
在已经只有1-9人负责整个API面的公司，招聘三个专业角色（API PM、架构师、合作伙伴工程师）先确认公司类型，并根据实际团队规模决定招聘规模，参考公司类型文档

Reference

参考资料

  • references/company-type-hiring-bar.md - the three company archetypes, the 84%-small-teams finding, and the scope-collapse precondition.
  • references/interview-loop-design.md - the API-design-vs-system-design split, per-track loop designs, and GitLab's real posted sequence.
  • references/sourcing-channels.md - apidays, the PlatformCon caveat, and why this pool sources more like senior backend engineering than DevRel.
  • references/compensation-guidance.md - the general-ladder finding in full, and what to check for a live figure.
  • See samber/developer-platform-skills@developer-platform-career for the candidate's side of this table.
  • See samber/developer-relations-skills@devrel-hiring for a DevRel-shaped hire that a posting may be conflating with a platform hire - the scope-collapse red flag above is this collision's usual symptom.
  • 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。
  • 如果一个岗位描述可能把DevRel形态的招聘与平台岗位混为一谈，参见samber/developer-relations-skills@devrel-hiring——上面的范围坍缩危险信号正是这种混淆的常见症状。