Employer-side hiring for developer-platform roles - API Product Manager, Platform Engineer/Architect, Partner/Integration Engineer. Disambiguates "platform engineer" first, since the term overwhelmingly means internal developer platforms elsewhere in the industry. Calibrates the scorecard to company archetype (infra/API-first, bolt-on public API, enterprise partner ecosystem), flags a scope-collapse pattern distinct from DevRel's gatekeeper/pit-trap taxonomy, sources from apidays, not PlatformCo
Install
npx skills add https://github.com/samber/developer-platform-skills --skill developer-platform-hiringDeveloper 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.
- 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.
- Target role track: (a) API Product Manager (b) Platform Engineer/Architect (c) Partner Engineer, relationship-facing (d) Integration Engineer, architecture-focused (e) undecided.
- 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.)
- 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)?
- How many people and what budget will this role actually have - solo ownership, a small team, or shared with existing engineering staff?
- 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?
- Deadline: this month, this quarter, or no hard date?
- One-off hire or the first of several where the scorecard and loop get reused?
- 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
- Run the Interview. State the company-archetype and role-track calibration in one short paragraph the user can veto.
- 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
- 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
- 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
- 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
- Run the Quality gate below. Iterate until it passes.
- If your harness has persistent memory, store the scorecard, loop design and sourcing plan for reuse on a repeat hire.
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.
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.
Quality gate
Score the artefacts against these checks before final delivery.
- The posting or scorecard states explicitly whether the role means internal-IDP or external-API platform engineering.
- The scorecard names the actual company archetype and the metric this role is measured on, and every outcome is quantified.
- The posting passes the scope-collapse self-audit - no build-plus-outreach stack with no stated headcount plan.
- 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.
- Sourcing uses apidays or general senior-backend/PM channels as appropriate - never PlatformCon for an external-API hire.
- 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.
Common failure modes
| Failure | Fix |
|---|---|
| Sourcing on PlatformCon or internal-IDP channels for an external-API-platform hire | Use 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 budget | Split 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 role | Use the API-design format, judged on developer-facing usability and misuse-resistance |
| Quoting a bespoke "platform engineer" salary figure from a crowdsourced site | Anchor to the company's general engineering/PM ladder at the equivalent level |
| Treating GitLab's or Stripe's posted structure as a universal industry standard | State 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 surface | Confirm the archetype first and size the hire to the actual team, per the company-type reference |
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.