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.