developer-platform-hiring

{
  "skill_name": "developer-platform-hiring",
  "evals": [
    {
      "id": 1,
      "prompt": "I run engineering at Meridian Freight Cloud, a logistics SaaS. About 400 customer dev teams build against our public shipment-tracking API and we want that to become a real business line, so I opened a req for a Senior Platform Engineer six weeks ago. Our recruiter sponsored a booth at PlatformCon and has been posting in the Backstage community Slack every week. We've had 31 applicants and every single one wants to talk about Kubernetes operators, Argo CD and internal golden paths. Nobody has ever shipped anything a customer integrates against. Where should we actually be fishing, and what do I change?",
      "expected_output": "Establishes that the role's consumer is external developers, classifies it as an external-API platform hire rather than internal developer platform work, explains that PlatformCon and Backstage serve the internal-IDP population, and redirects sourcing to apidays plus general senior-backend-engineering channels with open-source contribution history as a screen.",
      "files": [],
      "expectations": [
        "Asks or states explicitly whether the primary consumer of what this role builds is the company's own engineering teams or developers outside the company",
        "Classifies the role as an external/public-API platform hire rather than internal developer platform (IDP) work",
        "Identifies PlatformCon as serving the internal-developer-platform audience rather than this role's audience",
        "Identifies the Backstage community as an internal-IDP channel and therefore the wrong applicant pool for this hire",
        "Recommends apidays as a sourcing venue for API platform engineers",
        "States that apidays names API platform engineers and API product managers among its stated audience",
        "Recommends general senior-backend-engineering sourcing channels such as referral networks and senior-IC pipelines for this track",
        "Names open-source contribution history as a screening signal reviewable as existing evidence rather than tested live",
        "Does not recommend DevRel-adjacent channels (developer-advocate job boards, DevRel Slack or Discord, conference speaker circuits) as the primary pool for this role",
        "States that the posting itself must say explicitly whether the role means internal-IDP or external-API platform engineering",
        "Attributes the six weeks of irrelevant applicants to a channel and audience mismatch rather than only to compensation or job-title wording"
      ]
    },
    {
      "id": 2,
      "prompt": "Calder Analytics here, 60 people, B2B analytics product that's been selling for seven years. Four months ago we shipped a public REST API because three enterprise accounts demanded it. Right now two backend engineers keep it alive on top of their normal roadmap work. Our CEO wants to get serious about it and has signed off budget for three hires starting in Q1: an API Product Manager, a Platform Architect, and a Partner Engineer. Can you write me the three scorecards so I can hand them to the recruiter on Monday?",
      "expected_output": "Classifies the company as the bolt-on public API archetype, cites the 84% small-teams finding, pushes back on the three-role split as oversized for a two-person API surface, and only produces scorecards that name the archetype, the measured metric, and quantified outcomes.",
      "files": [],
      "expectations": [
        "Classifies Calder Analytics as the bolt-on public API archetype rather than infra/API-first or enterprise partner ecosystem",
        "Cites Postman's finding that 84% of API teams operate in groups of 1-9 people",
        "Pushes back on hiring three specialized roles at once and recommends sizing the hire to the current two-person API surface",
        "States that at a bolt-on company API design is typically one line item inside a general backend-engineering role rather than a dedicated platform team's sole mandate",
        "Notes that splitting API PM, platform architect and partner engineer into three separate people is the exception rather than the norm",
        "Asks or establishes how many people currently own the API surface end to end before producing any scorecard",
        "Frames a first dedicated platform hire at this company as a real resourcing shift rather than a routine backfill",
        "Does not apply the infra/API-first bar (staff level, 12+ years, prior leadership of API-design teams) as the bar for this company",
        "Any scorecard produced names the company archetype and the specific metric the role is measured on",
        "Any scorecard produced lists quantified outcomes rather than vague responsibilities such as owning the platform"
      ]
    },
    {
      "id": 3,
      "prompt": "Draft req for Nimbus Ledger (Series B fintech), about to go live. Title: Senior API Platform Engineer. Responsibilities: design and ship our v2 public payments API; own the integration architecture for 12 named partner integrations in year one; write the developer blog and run quarterly community office hours; grow monthly active API keys by 40%. Reports to: TBD. Team: solo for now, we'll see how it goes. Comp band already agreed. Does this look hireable? Tighten it up for me and I'll post it this afternoon.",
      "expected_output": "Refuses to approve the posting, names the build-plus-outreach scope collapse and the three-function outcome stack, flags the missing reporting line and headcount plan, distinguishes the pattern from DevRel's gatekeeper taxonomy, states plainly that no named sourced taxonomy exists here, and recommends splitting the scope or stating the resourcing explicitly.",
      "files": [],
      "expectations": [
        "Flags the posting as a scope-collapse red flag rather than approving it as hireable",
        "Names the stacking of build work (API design, partner-integration architecture) with outreach work (developer blog, community office hours) as the specific pattern",
        "Notes the posting carries outcomes belonging to three different functions: a shipped API surface, a named partner-integration count, and a content, community or usage metric",
        "Flags the absence of any stated headcount plan for eventually splitting the scope",
        "Flags the missing reporting line and the absent budget for growing the function past one person",
        "States that the failure here is execution volume across multiple full-time jobs rather than an impossible-skills list",
        "Distinguishes this pattern from DevRel's gatekeeper/pit-trap taxonomy rather than relabeling that taxonomy",
        "States plainly that no named, sourced hiring-red-flag taxonomy exists for developer-platform roles and presents this diagnosis as a structural inference rather than a quoted industry framework",
        "Names the mismatch between the IC-engineering seniority the title implies and responsibilities that read as a product manager's job plus a DevRel job layered on top",
        "Recommends either splitting the scope across more than one hire or stating the resourcing explicitly in the posting before it goes out",
        "Recommends the posting state explicitly that this is external-API platform engineering rather than internal developer platform work"
      ]
    },
    {
      "id": 4,
      "prompt": "Trellis Comms, CPaaS company, our messaging API basically is the product. 140 engineers. We're hiring a Staff Platform Engineer to own the public API surface. We already run a standard loop for senior backend: one 60-minute system design round (the usual prompts, design a URL shortener or design Twitter), two coding rounds, one behavioral. I was planning to just reuse it. Sanity-check me and tell me what to add. Constraint: I can't spend more than 5 interviewer-hours per candidate total, and we do have a recruiter doing the first call.",
      "expected_output": "Adds an API-design round distinct from general system design, describes what it judges and how its scope differs, gives a developer-as-user prompt, sets the infra/API-first bar, fits the 5-hour ceiling by deleting stages, and declines to present any company's posted loop as an industry standard.",
      "files": [],
      "expectations": [
        "Recommends adding an API-design round that is distinct from the general system-design round",
        "States that API design and system design are two separate named interview formats used at major companies",
        "States the API-design round is judged on developer-facing usability and resistance to misuse rather than raw scale trade-offs",
        "Names clarity, predictability, being hard to misuse, or error messages specific enough for a developer to act on, as the bar for the API-design round",
        "Notes the API-design round's scope is deliberately smaller than full system design, with no full architecture to sketch",
        "Offers a concrete API-design prompt whose users are developers integrating the API, such as a card-payment-processing API",
        "Classifies Trellis Comms as the infra/API-first archetype where the API is the product and sets the highest technical-depth bar accordingly",
        "Respects the 5-interviewer-hour ceiling by deleting loop stages rather than only reordering or shortening them",
        "Does not present any named company's posted loop as a universal industry standard",
        "States that no single fully documented developer-platform-specific loop is published for every track and presents the resulting loop as an assembled design"
      ]
    },
    {
      "id": 5,
      "prompt": "Hollis Retail Systems, enterprise retail platform. Roughly 1,200 ISV partners build on our partner API and that ecosystem is where our growth is coming from. We're hiring our first API Product Manager. Head of Product wants to run our standard engineering loop on them: a 45-minute Python coding screen, then a system design round, then two behavioral interviews. No hard deadline, and this will probably be the first of three platform hires over the next year so I want whatever we build to be reusable. Give me the loop, what each stage tests, and the outcomes I should put on the scorecard.",
      "expected_output": "Drops the coding screen for the PM track, weights a scoping and design-thinking round, allows a no-code technical conversation, cites the PM-loop precedent, classifies the enterprise partner-ecosystem archetype, names partner-facing outcome metrics, and builds the loop as a reusable artefact.",
      "files": [],
      "expectations": [
        "Removes or replaces the Python coding screen for the API Product Manager track",
        "Recommends a scoping and design-thinking round weighted over a coding round",
        "States the PM candidate is assessed on how they scope, structure and communicate design thinking rather than on proving deep technical implementation expertise",
        "Allows a technical conversation in which the PM explains APIs and how a system fits together without writing code",
        "Cites Google's or Uber's own PM loop practice as the precedent for that weighting",
        "Recommends a written product exercise only if the company's general PM process already uses one",
        "Classifies Hollis Retail Systems as the enterprise partner-ecosystem archetype",
        "Names partner-facing outcome metrics such as partners supported, integrations shipped or launched, integration usage, or year-over-year growth, rather than a generic own-the-API outcome",
        "Builds the loop as a reusable artefact because this is the first of several hires rather than a one-off"
      ]
    },
    {
      "id": 6,
      "prompt": "Varnhold Systems, 300-person B2B SaaS. I need a number for the req today. Our recruiter pulled Glassdoor and Levels.fyi for 'platform engineer' and got $155k-$210k base, then averaged in postings for 'API developer' and 'integration engineer' to widen the sample size. We're leveling this person as our L5, same as our other senior backend folks. Just give me the offer range to put in the requisition and the one-line justification I can send the CFO.",
      "expected_output": "Refuses the blended crowdsourced figure as market rate, anchors the offer to the company's own general engineering ladder at L5, explains why bespoke title searches return sparse data, cites Stripe's general-ladder title as one sourced example, and requires any figure to carry source, date and level.",
      "files": [],
      "expectations": [
        "Refuses to present the $155k-$210k crowdsourced range as a verified market rate",
        "Rejects blending platform engineer, API developer and integration engineer postings into a single averaged range",
        "Anchors the offer to the company's own general software-engineering ladder at the L5-equivalent level",
        "States that bespoke platform engineer or API product manager title searches return sparse crowdsourced data",
        "Cites Stripe's Staff Software Engineer, API Platform title as evidence that the leveling word is a general-ladder rung with the platform name as a team qualifier",
        "Presents that company example as one sourced data point rather than a universal industry standard",
        "Requires any figure used to carry its source, date and level, and never an undated number quoted from memory",
        "Recommends searching crowdsourced leveling data by the general engineering title plus team name rather than by the bespoke platform title",
        "Gives the general-ladder anchor as the actionable answer rather than hedging the compensation question away as unanswerable"
      ]
    },
    {
      "id": 7,
      "prompt": "Okabe Cloud, Series A. I need to hire a Developer Platform Engineer and I want your help with the scorecard and the interview loop. The job: run our developer community Discord, write tutorials and sample apps for our API, speak at about three conferences a year, and collect feedback from integrators to bring back to the product team. Budget is one headcount. What should the loop look like?",
      "expected_output": "Identifies the responsibilities as a developer-relations role despite the platform title, routes the user to the DevRel hiring skill, explains the screening difference, declines to build an API-design round, and flags the title-versus-responsibilities mismatch.",
      "files": [],
      "expectations": [
        "Identifies the described responsibilities as a developer-relations or advocacy role rather than a developer-platform engineering role",
        "Routes the user to samber/developer-relations-skills@devrel-hiring",
        "States that DevRel roles are screened primarily on communication and community craft while developer-platform roles are screened on API and system design judgment",
        "Does not produce an API-design interview round for this role",
        "Flags the mismatch between the platform engineering title and the responsibilities, and recommends retitling or splitting the role rather than hiring under the platform title as written"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "How do I hire a platform engineer for our public API?", "should_trigger": true },
    { "query": "write a job description for an API product manager", "should_trigger": true },
    { "query": "we need someone to own our partner integrations, what should the job posting say", "should_trigger": true },
    { "query": "design the interview loop for a platform architect on our API team", "should_trigger": true },
    { "query": "what should I screen for when hiring an integration engineer", "should_trigger": true },
    { "query": "our recruiter keeps sending us Kubernetes people for a role on our public API team, how do I fix the search", "should_trigger": true },
    { "query": "scorecard for our first API platform hire", "should_trigger": true },
    { "query": "where do I find candidates who have built public APIs professionally", "should_trigger": true },
    { "query": "is this job posting asking for too much? it's API design plus partner integrations plus developer content", "should_trigger": true },
    { "query": "what do we pay a staff engineer on our API platform team", "should_trigger": true },
    { "query": "hiring an API product manager, what rounds should the loop have", "should_trigger": true },
    { "query": "we're bolting a public API onto our product, do we need a dedicated platform team or can our backend folks own it", "should_trigger": true },
    { "query": "what conferences should we recruit API platform people at", "should_trigger": true },
    { "query": "should there be a coding round for a product manager who owns our developer API", "should_trigger": true },
    { "query": "how many people do companies usually have owning their API surface end to end", "should_trigger": true },
    { "query": "review my req for senior platform engineer before I post it", "should_trigger": true },
    { "query": "our partner ecosystem is growing, what does a partner engineer job family look like", "should_trigger": true },
    { "query": "what interview question tests whether someone can design an API other developers won't misuse", "should_trigger": true },
    { "query": "how should I level and pay someone who will own our external developer platform", "should_trigger": true },
    { "query": "need must-have vs nice-to-have requirements for an API architect role", "should_trigger": true },
    { "query": "who do I hire first if I want our API to become a real product", "should_trigger": true },
    { "query": "my engineering team wants to reuse our system design round for an API platform role, is that ok", "should_trigger": true },
    { "query": "we've had a platform engineer req open for two months and none of the applicants fit", "should_trigger": true },
    { "query": "draft the mission statement and outcomes for an API product manager we're recruiting", "should_trigger": true },
    { "query": "how should I structure the panel for someone who will build integrations with our ISV partners", "should_trigger": true },
    { "query": "i want to hire one person to build our API and also do the devrel side, thoughts", "should_trigger": true },
    { "query": "what's a realistic experience bar for an API platform engineer at an infrastructure company", "should_trigger": true },
    { "query": "help me put together the hiring plan for our developer platform team", "should_trigger": true },
    { "query": "the candidate has no talks or blog posts but 8 years of backend and a big open source project, is that a fit for our public API role", "should_trigger": true },
    { "query": "I'm interviewing for an API product manager job next week, how do I prepare", "should_trigger": false },
    { "query": "how do I break into platform engineering as a backend dev", "should_trigger": false },
    { "query": "review my resume for a partner solutions architect role", "should_trigger": false },
    { "query": "hire a developer advocate for our open source project", "should_trigger": false },
    { "query": "what should our developer relations team structure look like", "should_trigger": false },
    { "query": "design the error code taxonomy for our public API", "should_trigger": false },
    { "query": "should we add a GraphQL layer or stick with REST", "should_trigger": false },
    { "query": "set rate limits per pricing tier for our API", "should_trigger": false },
    { "query": "how should we version our public API and communicate deprecations", "should_trigger": false },
    { "query": "audit our API reference docs for undocumented endpoints", "should_trigger": false },
    { "query": "design a sandbox mode so integrators can test without real charges", "should_trigger": false },
    { "query": "how do we store and rotate the API keys we issue to customers", "should_trigger": false },
    { "query": "build an idempotency key system for our payments endpoints", "should_trigger": false },
    { "query": "write the interview loop for a senior backend engineer on our checkout team", "should_trigger": false },
    { "query": "should we build our own app marketplace or list on other platforms", "should_trigger": false },
    { "query": "write the listing rules third-party apps must meet on our marketplace", "should_trigger": false },
    { "query": "what revenue share should our connector marketplace take", "should_trigger": false },
    { "query": "design the review and approval process for apps submitted to our marketplace", "should_trigger": false },
    { "query": "which languages should we ship official SDKs for first", "should_trigger": false },
    { "query": "design our outbound webhook retry and dead-letter policy", "should_trigger": false },
    { "query": "plan the onboarding journey for partner developers up to their first submitted app", "should_trigger": false },
    { "query": "how do we expose SQL access to customer data safely", "should_trigger": false },
    { "query": "which technology partners should we integrate with next quarter", "should_trigger": false },
    { "query": "improve our listing on the Salesforce AppExchange", "should_trigger": false },
    { "query": "design our OAuth consent screen and scope taxonomy", "should_trigger": false },
    { "query": "what should our MCP server expose to AI agents", "should_trigger": false },
    { "query": "our developer portal's signup to first call takes too long", "should_trigger": false },
    { "query": "hire a platform engineer to build our internal developer platform on Backstage", "should_trigger": false },
    { "query": "we need someone to own our golden paths and CI/CD self-service for our own app teams", "should_trigger": false }
  ]
}

# Company type hiring bar

Contents: the three company archetypes and how the hiring bar differs, the dominant small-team condition, and the structural precondition behind the scope-collapse red flag.

## The three archetypes

- **Infrastructure/API-first companies** (Stripe, Twilio-style) - the API _is_ the product. Bar: highest technical depth, dedicated platform teams, staff-level roles carrying 12+ years experience and 5+ years of strategic technical leadership as a stated minimum. Stripe's own posting explicitly invites candidates "whether they've spent their entire career in infrastructure or are looking to apply their skills... for the first time."
- **Companies bolting a public API onto an existing product** - no single sourced example was directly confirmed, but the shape is implied by the prevalence of small API teams (below) and by postings that ask for "API design and development" as one line item inside an otherwise general backend-engineering role rather than as a dedicated platform team's sole mandate.
- **Enterprise platforms with large partner/ISV ecosystems** - evidenced by GitLab's dedicated, three-level Partner Integration Engineering job family reporting through a Director, Partner Solutions Architecture, with tracked KPIs (partners supported, integrations launched, integration usage, year-over-year growth) - a structurally different hiring pattern because the deliverable is partner-relationship-mediated, not a solo technical build.

## The dominant real-world condition: most API teams are small

Postman's State of the API Report found **84% of API teams operate in groups of 1-9 people**, with API-related work spread across testing (81%), development/implementation (73%), and documentation (58%) inside that small group - and no distinct, centralized "platform product manager" or "platform engineering" function called out separately from general engineering roles at most companies. Ownership of API strategy is described as distributed rather than centralized even in "API-first" organizations (82% report an API-first approach, but only 25% describe themselves as fully API-first).

**This is the single most important company-type finding for hiring**: a dedicated, specialized developer-platform hire (API PM, platform architect, and partner engineer as three separate people) is the exception, not the norm. At the modal company, one or two people on a small team absorb API design, partner integration, and often some developer-facing communication simultaneously. This is the structural precondition behind the scope-collapse hiring red flag in the skill body: it is not a hiring-process mistake so much as a real resourcing constraint a hiring manager needs to name explicitly rather than paper over with an inflated single job title.

## What differs across the three archetypes

| Dimension                      | Infra/API-first                                                                              | Bolt-on public API                                                       | Enterprise partner ecosystem                                                                       |
| ------------------------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- |
| Team dedicated to the platform | Yes, often multiple specialized teams                                                        | Rarely a dedicated team; folded into general backend engineering         | Yes, a named partner-engineering function with its own manager and director                        |
| What a hire is measured on     | API design quality, infra reliability, developer-facing contract stability                   | General engineering delivery, API design as one competency among several | Named partner-facing KPIs: partners supported, integrations shipped, usage growth                  |
| Portfolio bar for a candidate  | Highest - staff-level postings can expect 12+ years and prior leadership of API-design teams | Lower, folded into a general "API design and development" line item      | Relationship plus technical hybrid: open-source contribution history, partner-facing communication |

## What this means for the hiring skill

Ask which archetype the hiring company is - dedicated platform org, general engineering team adding an API line item, or a named partner-ecosystem function - before recommending a role split. Asking a bolt-on company to hire three specialized roles (API PM, platform architect, partner engineer) when their real API surface is maintained by 1-9 people is likely to overshoot both budget and real need.

# Compensation guidance

Contents: why no survey-grade dataset exists, the structural finding that changes how this benchmark works, and what to check for a live figure.

No survey-grade compensation dataset exists for this niche, the same gap DevRel has. Direct lookups (Levels.fyi, Glassdoor, Payscale, BuiltIn) either 404, return no usable content, or block scraping. Never present an undated number as verified.

## The key structural finding: platform comp rides the general ladder, unlike DevRel

This is the one finding worth stating explicitly and prominently, because it flips how this skill's compensation gate should read relative to `devrel-hiring`'s:

- Stripe's own posting for this exact function is titled **"Staff Software Engineer, API Platform"** - the leveling word is "Staff Software Engineer," the general engineering ladder rung, with "API Platform" as a qualifier/team name, not a separate ladder. This is a directly sourced, concrete data point that at least one major infra-first company places platform engineering on its general software-engineering levels rather than carving out a bespoke platform-specific pay scale.
- The API Product Manager literature converges on the same pattern from the PM side: career-progression sources describe API PM levels as "typically company-specific rather than standardized industry-wide, though it generally mirrors general product management career ladders with added emphasis on technical/developer-facing skills at every level."
- This contrasts with DevRel, where compensation has no reliable anchor to an existing ladder at small or mid companies, which is why DevRel pay is comparatively undersurveyed and unpredictable across company sizes.

**Practical implication for a hiring manager:** where `devrel-hiring` must anchor an offer to a dated crowdsourced figure and treat it as directional, this skill can instead anchor an offer to the company's own general software-engineering (or general product-management) comp bands at the equivalent level - the same way any other backend-engineering or PM specialization gets leveled and paid. State this as the actionable answer rather than hedging it away.

## What to check for a live figure

- The company's own published engineering or PM level ladder and comp bands, if public (GitLab publishes both, though the specific compensation figures for its Partner Integration Engineer family were not visible in the fetched handbook page - only the job-level structure was).
- Crowdsourced leveling sites (Levels.fyi) searched by the _general_ engineering or PM title plus team name (for example, "Staff Software Engineer" at the target company, filtered to a platform or API team) rather than by a bespoke "platform engineer" or "API product manager" title, since those bespoke titles return sparse or no data.
- Devtools-focused recruiters, the same channel devrel-hiring names for its own undersurveyed compensation gap.

Never quote an undated figure from memory; if the harness can browse, pull a current figure with its source, date, and level before using it in any deliverable, exactly as devrel-hiring instructs for its own compensation gate.

# Interview loop design

Contents: the API-design-vs-system-design split, PM-vs-engineer loop differences, take-home practices, GitLab's real posted loop.

## API design is a named, separate interview format from general system design

Multiple companies (Meta specifically named) now split what used to be one "system design" round into two distinct interview types:

- **System design** - large-scale distributed-systems architecture.
- **API design** (reported internally at Meta as "Pirate X" in candidate-prep literature) - design decisions and their downstream consequences for the developer consuming the API. Scope is deliberately smaller than full system design: no full architecture to sketch, the bar is that the API must be clear, predictable, and hard to misuse, with error messages specific enough that a developer can act on them.

A commonly cited worked example: design a payments API scoped to card-payment processing, where the "users" are developers integrating it into their own product.

**For a PM candidate**, the bar differs by design from an engineering candidate's: assessed on how well they scope, structure, and communicate the design thinking, not on proving deep technical implementation expertise - echoed at Google, where system-design-flavored PM rounds emphasize estimation and scoping over the technical solution. Some PM loops (Uber) still include a genuine technical conversation with an engineer, where the PM candidate must explain APIs and how a system fits together without hand-waving, though without writing code.

## Take-home and written components

Sourced practice across companies, not developer-platform-specific: Google closes its PM loop with a written product exercise; Meta opens with short-answer questions due back in about 24 hours; Roblox asks candidates to explain their assessment reasoning in a short essay; LinkedIn's product-sense round has historically included a writing sample. No developer-platform-specific take-home (for example, "design this SDK" as a formal artifact) was found as a named, sourced practice - treat it as a plausible format by analogy to the API-design interview type above, not as directly confirmed practice.

## A real, posted engineering-side loop: GitLab's Partner Integration Engineer

Directly sourced from GitLab's public handbook: recruiter call -> hiring-manager interview -> 2 to 5 team interviews -> a possible executive round for senior hires. No API-design-specific round or take-home is named in the posted family description. GitLab's screening substance, per the job family's stated skills, centers on language proficiency, SDLC practice, and a real open-source contribution history that can be reviewed as existing evidence rather than tested live - a lower-cost validity signal a hiring loop can lean on if the candidate already has one.

## Building a loop for this collection's roles

- **API Product Manager** - a scoping/design-thinking round (not a coding round), a stakeholder-management or roadmap-prioritization scenario, and a written exercise if the hiring team's general PM process already uses one.
- **Platform Engineer / Platform Architect** - an API-design round distinct from general system design, a hands-on or architecture-review round matched to seniority, and a technical-leadership conversation at staff level and above.
- **Partner / Integration Engineer** - GitLab's structured sequence above, weighted toward relationship-management scenarios for a Partner Engineer and toward architecture/reliability scenarios for an Integration Engineer.

## What is confirmed vs. what is inferred

Confirmed and directly sourced: the system-design/API-design split as two distinct interview types at major companies; the PM-vs-engineer difference in what's assessed within that split; the general PM-loop take-home pattern (not platform-specific); GitLab's real posted loop structure.

Not confirmed, flagged rather than invented: a named "versioning/backward-compatibility scenario question" as a distinct, formally recognized interview round; any specific SDK-design take-home account from a named company or candidate.

# Sourcing channels

Contents: apidays as the confirmed venue, the PlatformCon near-miss, and why this pool overlaps more with senior backend sourcing than DevRel sourcing.

## The one directly confirmed, named venue for this exact audience

**apidays** (apidays.global) is the clearest sourced answer to "where do API-platform and API-product people gather." It explicitly names its audience as "API platform engineers," "API product managers," and "decision-makers shaping API-first strategies" - the two named roles landing squarely on this skill's tracks. Confirmed scale: 100,000+ past attendees, past speakers including Docker's creator, Twilio's CEO, and AsyncAPI's creator; structured tracks including the OpenAPI Initiative's own OAI track; a running "apiMasters" certification program (see the skill body for the caveat on its hiring weight). This is a legitimate sourcing and community channel to use.

## The confirmed near-miss: PlatformCon serves a different population

PlatformCon (platformcon.com) is real, large (280,000+ practitioners in its community, a six-city world tour, hundreds of speakers), and easy to mistake for the same audience because it also uses the word "platform." It explicitly serves **internal developer platform (IDP)** practitioners - "platform engineers, platform architects, and infrastructure teams... responsible for building and maintaining internal platforms at scale," covering IDPs, agentic development platforms, and organizational scaling for enterprise infrastructure teams. **Do not list PlatformCon as a sourcing channel for external/public API-platform hires without this caveat** - a recruiter fishing there for a Stripe/Twilio-style API platform engineer or an API product manager will draw from the wrong specialization.

## Why this pool overlaps more with senior backend sourcing than DevRel sourcing

The target candidates for platform-engineer and integration/partner-engineer roles are screened on system design and API design judgment - the same axis general senior backend-engineering hiring already screens on, just with an API-design specialization layered in. Stripe's own posting explicitly welcomes candidates "whether they've spent their entire career in infrastructure or are looking to apply their skills... for the first time," implying the sourcing pool is general senior/staff backend engineers, not a separately credentialed specialist pool. DevRel sourcing, by contrast, draws from public content and community output (talks given, blog posts, community roles) as the primary signal - a different pool almost by construction, since the deliverable being screened for is different.

Practical implication: general senior-backend-engineering sourcing channels (engineering referral networks, senior-IC hiring pipelines, open-source contribution history as a screen, per GitLab's explicit requirement) will surface more relevant platform-engineer and integration-engineer candidates than DevRel-adjacent channels (developer-advocate job boards, DevRel Slack or Discord communities, conference speaker circuits) will. The API Product Manager track sources more like a technical product-management hire - general PM pipelines filtered for API or developer-facing product experience - than like either backend engineering or DevRel.

## What was not confirmed

No dedicated, named job board or community specifically for "API Product Manager" hiring, distinct from general technical-PM communities, was found or verified. Treat general product-management sourcing channels, filtered for developer-facing/API product experience, as the working answer until a more specific channel is confirmed. A "Postman certification" community or channel was referenced in passing but could not be verified live - do not cite it as a sourcing channel without re-confirming.

---
name: developer-platform-hiring
description: 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 PlatformCon's internal-IDP audience, builds the loop from the API-design-vs-system-design interview split, and benchmarks compensation against the general engineering/PM ladder rather than a bespoke platform title. Use when the user asks how to hire a platform engineer, API product manager, or partner/integration engineer, write a posting, or design a loop. Do NOT use for candidate prep (samber/developer-platform-skills@developer-platform-career) or DevRel hiring (samber/developer-relations-skills@devrel-hiring).
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# 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](./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](./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](./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](./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](./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.

## 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](./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.

## 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](./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](./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](./references/sourcing-channels.md) - apidays, the PlatformCon caveat, and why this pool sources more like senior backend engineering than DevRel.
- [references/compensation-guidance.md](./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.