Developer Platform Hiring

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.

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.

Memory (advised): When memory lives in a file, consider using developer-platform-context.md; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

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?

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.

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

1. 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

1. 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