developer-platform-career

{
  "skill_name": "developer-platform-career",
  "evals": [
    {
      "id": 1,
      "prompt": "I'm a backend engineer (6 years, mostly Go and Postgres) at a logistics company and I want to move into platform engineering next year. I've started the Certified Kubernetes Administrator course and I've already booked PlatformCon for next June. The two jobs I'm actually excited about are at Cadenza, a payments infrastructure company where I'd own the public REST API and the partner webhook surface, and at Vellum Labs, where the posting says I'd design the SDKs their customers integrate against. Can you put together a six-month plan to get me ready?",
      "expected_output": "A plan that first separates the internal-developer-platform meaning of 'platform engineering' from the external/public-API track the user's target jobs actually sit in, then redirects the conference, study and portfolio choices accordingly.",
      "files": [],
      "expectations": [
        "Establishes who the primary consumer of the role's output is - the company's own engineering teams or developers outside the company - before giving a plan",
        "States that \"platform engineer\" and \"platform engineering\" overwhelmingly mean internal developer platforms elsewhere in the industry: self-service infrastructure, CI/CD, Kubernetes abstractions, golden paths",
        "Identifies the two target jobs (public REST API, partner webhooks, customer-facing SDKs) as the external/public-API population rather than the internal-developer-platform one",
        "Names PlatformCon as the internal-developer-platform community and states it does not cover the external-API track",
        "Redirects the community and conference choice toward apidays rather than PlatformCon",
        "Warns that Kubernetes/CKA-style internal-infrastructure study does not build the signal these external-API roles screen on",
        "Names the target role track explicitly as one of API Product Manager, Platform Engineer/Architect, or Partner/Integration Engineer",
        "Names the target company archetype explicitly as one of infra/API-first, bolt-on public API on an existing product, or enterprise partner/ISV ecosystem",
        "States that sourcing the wrong population also benchmarks the wrong compensation band (general infra/SRE versus general backend/product engineering with an API-design specialization)",
        "Recommends API-design portfolio artifacts - RFCs or design docs, shipped API/schema designs, open-source contributions - over infrastructure certifications"
      ]
    },
    {
      "id": 2,
      "prompt": "Northwind Signal just made me an offer. Title is \"Staff Software Engineer, API Platform\" - I'd be on the team that owns their public API and the webhook delivery system. I spent the weekend trying to sanity-check the number and got nowhere: searching \"platform engineer\" and \"API product manager\" on the crowdsourced comp sites returns almost nothing, and the two data points I did find were four years apart and 60% different. What should I be asking for?",
      "expected_output": "A benchmarking method that maps the title onto the company's general engineering ladder instead of chasing a bespoke platform title, with every figure sourced, dated and levelled or flagged for live verification.",
      "files": [],
      "expectations": [
        "States that developer-platform compensation rides the general engineering or product-management ladder rather than a separate, bespoke one",
        "Instructs the user to benchmark against Northwind Signal's general software-engineering band at the Staff level",
        "Points out that in \"Staff Software Engineer, API Platform\" the leveling word is the general engineering rung and \"API Platform\" is a team-name qualifier, not a pay scale",
        "Explains that bespoke platform/API title searches on crowdsourced leveling sites return sparse or no data, which is why the weekend search failed",
        "Recommends searching crowdsourced leveling sites by the general engineering title plus company, filtered to the platform or API team",
        "Recommends the company's own published engineering level ladder and comp bands where those are public",
        "States that no survey-grade compensation dataset exists for this niche",
        "Presents no specific compensation figure as verified without naming its source, date and level",
        "Flags any figure it does use as needing live verification before it anchors the negotiation",
        "Mentions devtools-focused recruiters as an additional channel for a current figure",
        "Names which company archetype the offer sits in (infra/API-first, bolt-on public API, or enterprise partner/ISV ecosystem)"
      ]
    },
    {
      "id": 3,
      "prompt": "Onsite at Perron (card payments, Series C) in nine days for a senior backend role on their API platform team. The recruiter's email lists a \"system design\" interview and, separately, an \"API design\" interview. My plan is to grind the usual distributed systems material for both - sharding strategies, consistency models, cache invalidation, load balancer topologies - since it's the same skill twice really. Also, should I expect a take-home? Give me a nine-day study list.",
      "expected_output": "Prep that separates the two rounds, treats API design as its own format judged on developer-facing clarity and misuse-resistance, and refuses to assert an SDK/API take-home as confirmed practice.",
      "files": [],
      "expectations": [
        "States that API design is a distinct, separately named interview format from general system design, not the same round twice",
        "Describes the system design round as testing large-scale distributed-systems architecture",
        "Describes the API design round as testing the decisions and downstream consequences of shaping an interface that developers consume",
        "States the API design round is judged on clarity and misuse-resistance rather than raw scale or availability trade-offs",
        "States the API design round's scope is deliberately smaller than a full system design round, with no full architecture to sketch",
        "Names Meta as a company running API design as a separate, named interview type",
        "Uses the payments-API worked example, scoped to card-payment processing, where the \"users\" are developers integrating the API into their own product",
        "States the bar includes error messages specific enough that an integrating developer can act on them",
        "Warns that the distributed-systems drill list (sharding, consistency, caching, load balancers) does not prepare the API design round",
        "Flags a take-home designing an SDK or API surface as plausible by analogy rather than as confirmed practice for this field",
        "Points the API-design prep at a named framework: Google's AIPs, Microsoft's REST API Guidelines, Zalando's RESTful API Guidelines, or the Richardson Maturity Model"
      ]
    },
    {
      "id": 4,
      "prompt": "I'm a PM at Brightloom Retail - four years, all internal tooling and merchandising features, no developer-facing product. I want to be an API product manager within a year. I've got about 2,000 euros of learning budget to spend before it expires in March. I was going to put it into the apiMasters certification and the Postman certification, and maybe a product-management bootcamp on top. Which of those gets me hired fastest?",
      "expected_output": "A redirect away from paid credentials toward portfolio and ladder positioning, with apiMasters correctly positioned as informational and the Postman program not endorsed without verification.",
      "files": [],
      "expectations": [
        "States that certifications are largely not meaningful for this field and that none functions as a stated hiring gate",
        "Identifies apidays' apiMasters as the one real, currently-running credential and positions it as informational at best",
        "Declines to recommend the Postman certification without first verifying that the program is live and confirming its actual positioning",
        "States that no dedicated academic degree or bootcamp path exists for this specialization",
        "States the specialization is layered onto a general software-engineering or product-management base",
        "Recommends RFC or design-doc writing as the checkable portfolio artifact for this field",
        "Notes that no public repository of API-design RFC portfolios comparable to a GitHub profile exists, so the equivalent artifact is a design doc from a real employer and is harder to make public",
        "States that API PM decisions are judged on integration friction and breaking-change cost, not feature adoption alone",
        "Describes API PM progression as mirroring the general product-management ladder with technical/developer-facing weighting added at every level",
        "Asks at least one scoping question - target track, target company archetype, deadline, or weekly effort available - before delivering a ranked plan"
      ]
    },
    {
      "id": 5,
      "prompt": "Three years at Tessera Health building internal service APIs - our own mobile and web teams are the only consumers. A recruiter told me last week this is the standard on-ramp to public API work and that everyone she places on external platform teams came through internal API work first. I want to be at a company shipping a real public API within 18 months. Confirm the path and tell me what to do next.",
      "expected_output": "A plan that accepts internal API work as a plausible lower-stakes practice ground but labels the route a hypothesis rather than confirming the recruiter's claim as an established pattern.",
      "files": [],
      "expectations": [
        "Labels the internal-API-to-external-API route as a plausible hypothesis, not an established or practitioner-verified pattern",
        "States that no named practitioner account of this exact transition is documented",
        "Does not confirm the recruiter's claim that this is the standard or usual path into external platform teams",
        "Explains why internal API work is lower-stakes: no public docs, no formal deprecation notice, no external SLA, less external-consumer accountability",
        "Contrasts the hypothesis with what is evidenced: GitLab's Associate Partner Integration Engineer to Partner Integration Engineer to Manager progression",
        "Presents that GitLab progression as one concrete sourced example of formal progression inside a company that already has the function, not a generic industry pattern",
        "States that an open-source contribution history is a named requirement in GitLab's family even at the associate level",
        "Names Ruby/Rails or Go proficiency as GitLab's stated language requirement for that family",
        "Recommends confirming whether a target posting means the internal-developer-platform or external-API population before applying to it",
        "Names both the target role track and the target company archetype for the 18-month goal"
      ]
    },
    {
      "id": 6,
      "prompt": "Two offers on the table and a third conversation running. Ardent Pay: payments infrastructure, the API is the whole product, title is Staff Software Engineer, API Platform, team of nine on the platform org. Glenview Logistics: vertical SaaS for freight brokers, they're adding a public API this year, title is Senior Backend Engineer, and the hiring manager said \"you'll own the API end to end\" - there's no platform team, I'd be one of six backend engineers. The third is a recruiter at a large enterprise with a partner engineering team that supports their ISV ecosystem. Base is within 8% across all three. Which do I take?",
      "expected_output": "A comparison that classifies each option by company archetype, names what a hire is measured on in each, and surfaces the archetype-specific risk rather than deciding on base salary.",
      "files": [],
      "expectations": [
        "Names the three company archetypes explicitly: infra/API-first, bolt-on public API on an existing product, and enterprise partner/ISV ecosystem",
        "Classifies Ardent Pay as the infra/API-first archetype",
        "Classifies Glenview Logistics as the bolt-on public API archetype",
        "Classifies the third conversation as the enterprise partner/ISV ecosystem archetype",
        "States that at bolt-on companies API design is folded into general backend engineering rather than owned by a dedicated team",
        "Flags the bolt-on risk that the role may be under-titled or under-levelled relative to actual scope, or pulled back into general backend work",
        "Flags the infra/API-first trade-off that scope is real and specialized but competition for the role is high",
        "Flags that the partner-ecosystem role is measured on partner metrics the candidate cannot fully control, such as the partner's own adoption pace",
        "Cites the finding that 84% of API teams operate in groups of 1-9 people",
        "Attributes that 84% figure to Postman's State of the API Report",
        "States that a candidate should expect breadth - API design plus some partner work plus some internal advocacy - rather than a narrowly scoped specialist seat, except at true infra-first companies or large partner-ecosystem enterprises",
        "States that one archetype's ladder and measurement criteria do not predict another's, so the three offers are not directly comparable on title or base alone"
      ]
    },
    {
      "id": 7,
      "prompt": "I read Stripe's posting for Staff Software Engineer, API Platform and it wants 12+ years of experience with 5+ in strategic technical leadership. I have six years. I also found GitLab's Associate Partner Integration Engineer description and assumed that's the standard first rung everyone starts on. On top of that, a recruiter is pitching me something called \"Developer Platform Lead\" at a Series B and I can't find that title anywhere else. My read is that I should stay in general backend for another six years until I clear the Stripe bar, then switch. Sanity-check me.",
      "expected_output": "A correction that treats Stripe's and GitLab's bars as the two concrete sourced examples they are rather than an industry ladder, and tells the candidate not to wait out six years against one company's staff posting.",
      "files": [],
      "expectations": [
        "States that no standardized cross-industry IC ladder exists for API Product Manager or Platform Engineer",
        "Presents Stripe's 12+ years and 5+ years of strategic technical leadership as one company's staff-level posting, not an entry bar for the track",
        "Presents GitLab's Partner Integration Engineer ladder as the one concrete sourced example rather than the standard first rung everyone starts on",
        "Names GitLab's three levels: Associate Partner Integration Engineer, Partner Integration Engineer, and Manager, Partner Integration Engineers",
        "States that the engineering-side entry bar varies widely, contrasting GitLab's bachelor's-degree-or-equivalent associate bar with Stripe's staff bar",
        "Notes that Stripe's posting welcomes candidates who have not spent their career in infrastructure, provided they show experience leading engineering teams working on API design, abstractions, frameworks, or client libraries",
        "Frames the Stripe bar as leadership over API-shaping work rather than tenure in any one stack",
        "Advises against waiting six more years in general backend before entering the track",
        "States that \"Developer Platform Lead\" has no standardized title or ladder and is an org-specific label rather than a title with its own external hiring market",
        "Recommends targeting an archetype whose bar matches the candidate's current level instead of benchmarking against a staff posting at an infra-first company"
      ]
    },
    {
      "id": 8,
      "prompt": "I run engineering at Kestrel Compliance, 40 people. We're opening our first dedicated API platform req next quarter and I need to get it right. Draft me the job description, the must-have versus nice-to-have split, and the interview loop with what each stage should test.",
      "expected_output": "A one-line redirect identifying this as the employer side of the table and pointing at the hiring skill, without producing the job description or loop.",
      "files": [],
      "expectations": [
        "Identifies the request as employer-side hiring rather than candidate-side career planning",
        "Names samber/developer-platform-skills@developer-platform-hiring as the skill to use instead",
        "Keeps the redirect to roughly one line rather than delivering a full plan",
        "Does not produce a finished job description",
        "Does not produce a finished interview loop or scorecard"
      ]
    },
    {
      "id": 9,
      "prompt": "My title at Marrowfield Systems is Integration Engineer - I spend my days on iPaaS flows, message queues and error handling between our ERP, our warehouse system and a couple of third-party carriers. A recruiter just pinged me about a Partner Engineer opening at a large enterprise with a big ISV ecosystem, and honestly it looks like the same job with a nicer name, so I'm inclined to apply with my CV as-is. Problem: every design doc I've written is covered by NDA, so I have nothing public to show. How do I play this?",
      "expected_output": "A distinction between the two roles on the relationship-facing axis, the partner-facing metrics the target role is measured on, and a portfolio strategy that works around the NDA constraint.",
      "files": [],
      "expectations": [
        "States that Partner Engineer is relationship-facing: the technical liaison between the company and external technology partners or marketplace developers",
        "States that Integration Engineer is internal and architecture-focused, owning how several services and third-party systems exchange data reliably",
        "States the two are not the same role renamed, and names the relationship-facing dimension as the difference",
        "Names GitLab or Uber as a company with the Partner Engineer shape",
        "Names the partner-facing outcome metrics for the function: partners supported, integrations launched, integration usage, and year-over-year partner-usage growth",
        "Warns that the partner role is measured partly on the partner's own adoption pace, which the candidate cannot fully control",
        "States that RFC and design-doc writing is a real, checkable portfolio artifact for this field",
        "Acknowledges the design-doc artifact is harder to make public than a blog post and offers a way to describe the work without disclosing confidential detail",
        "Recommends an open-source contribution history as the publicly checkable portfolio signal, noting it is a named requirement in GitLab's partner integration family even at entry level",
        "Names the enterprise partner/ISV ecosystem archetype as the one the opening sits in"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "How do I break into API product management?", "should_trigger": true },
    {
      "query": "I want to move from backend engineering onto the team that owns our public API - what's the path?",
      "should_trigger": true
    },
    { "query": "What does a Partner Engineer actually do day to day?", "should_trigger": true },
    {
      "query": "Interview next week for a platform engineer role at a payments company, how do I prep?",
      "should_trigger": true
    },
    { "query": "Is the apiMasters certification worth paying for?", "should_trigger": true },
    {
      "query": "How should I benchmark a Staff Software Engineer, API Platform offer?",
      "should_trigger": true
    },
    {
      "query": "Partner Engineer or Integration Engineer - which should I be applying to?",
      "should_trigger": true
    },
    {
      "query": "I've only ever built internal services. Can I get hired on a team that ships a public SDK?",
      "should_trigger": true
    },
    {
      "query": "The recruiter says the loop has an API design round separate from system design. What's the difference?",
      "should_trigger": true
    },
    {
      "query": "What goes in a portfolio when every design doc I've written is confidential?",
      "should_trigger": true
    },
    {
      "query": "Two offers: one where the API is the product, one where they're bolting an API onto their SaaS. Which?",
      "should_trigger": true
    },
    { "query": "How do I get to staff level on an API platform team?", "should_trigger": true },
    {
      "query": "A recruiter pitched me a Developer Platform Lead role - is that even a real title?",
      "should_trigger": true
    },
    { "query": "Do I need a degree to do API product management?", "should_trigger": true },
    { "query": "What does the ladder look like for partner integration engineers?", "should_trigger": true },
    {
      "query": "I'm a PM and they've added a technical round with an engineer. What will they ask me?",
      "should_trigger": true
    },
    {
      "query": "Should I specialise in webhooks and third-party integrations or stay a generalist backend engineer?",
      "should_trigger": true
    },
    { "query": "How many years do you actually need for a staff API platform role?", "should_trigger": true },
    { "query": "What salary should I ask for as an API product manager?", "should_trigger": true },
    {
      "query": "Help me choose between the developer platform team and the core product team for my next move",
      "should_trigger": true
    },
    { "query": "resume review for a platform engineering application", "should_trigger": true },
    {
      "query": "Four years as a solutions architect, I want to own the public API instead. Realistic?",
      "should_trigger": true
    },
    {
      "query": "Onsite next month where they said I'd be designing a payments API. What are they grading?",
      "should_trigger": true
    },
    {
      "query": "I'm applying for a role that owns a company's whole public API - what do they screen for?",
      "should_trigger": true
    },
    { "query": "Is it worth publishing RFCs to get noticed for these roles?", "should_trigger": true },
    {
      "query": "How do I describe my integration work on a CV without naming clients?",
      "should_trigger": true
    },
    {
      "query": "Thinking about leaving my backend job. What roles exist around APIs that aren't just more CRUD?",
      "should_trigger": true
    },
    {
      "query": "My title is Integration Engineer but I want to be partner-facing. How do I switch?",
      "should_trigger": true
    },
    {
      "query": "Which conferences should I be at if I want a job designing public APIs?",
      "should_trigger": true
    },
    {
      "query": "Does an open source history actually matter when applying to partner engineering teams?",
      "should_trigger": true
    },
    { "query": "I keep getting rejected from API platform roles, what am I missing?", "should_trigger": true },
    { "query": "How technical does an API PM need to be?", "should_trigger": true },
    {
      "query": "What comes after Senior PM if the product I own is developer-facing?",
      "should_trigger": true
    },
    {
      "query": "I'm being promoted to manage the partner integrations team - what changes about the job?",
      "should_trigger": true
    },
    {
      "query": "The comp sites have nothing for \"API product manager\". How do I figure out the band?",
      "should_trigger": true
    },
    {
      "query": "Interviewing somewhere one person does API design, partner work and the docs. Red flag?",
      "should_trigger": true
    },
    {
      "query": "Should I take it if the title says Senior Backend Engineer but the job is owning their public API?",
      "should_trigger": true
    },
    { "query": "How do I position myself for developer-facing infrastructure work?", "should_trigger": true },
    {
      "query": "I own our entire external API but I'm still levelled as mid. Am I underlevelled?",
      "should_trigger": true
    },
    {
      "query": "Eighteen month career plan, I want to end up owning an API as a product",
      "should_trigger": true
    },
    {
      "query": "How do I become a platform engineer working on our internal Kubernetes developer platform?",
      "should_trigger": false
    },
    {
      "query": "What should I learn to build golden paths with Backstage for our application teams?",
      "should_trigger": false
    },
    {
      "query": "Is PlatformCon worth attending for an internal developer platform team?",
      "should_trigger": false
    },
    { "query": "Career path from SRE into internal platform engineering", "should_trigger": false },
    {
      "query": "What's the salary band for a senior Kubernetes platform engineer in Berlin?",
      "should_trigger": false
    },
    {
      "query": "Should our internal developer platform team own the CI/CD pipelines too?",
      "should_trigger": false
    },
    { "query": "Design the rate limit policy for our public API", "should_trigger": false },
    { "query": "Write our API versioning and deprecation policy", "should_trigger": false },
    { "query": "Review our REST API design before we ship v1", "should_trigger": false },
    { "query": "How should we structure error codes in our public API?", "should_trigger": false },
    { "query": "Do we need idempotency keys on our payments endpoints?", "should_trigger": false },
    { "query": "Which SDK languages should we build official clients for first?", "should_trigger": false },
    { "query": "Should we build our own app marketplace or list on HubSpot's?", "should_trigger": false },
    { "query": "Plan the information architecture for our developer portal", "should_trigger": false },
    { "query": "Design our outbound webhook retry and dead-letter policy", "should_trigger": false },
    { "query": "Audit our API reference docs for endpoint coverage", "should_trigger": false },
    { "query": "Should we expose gRPC externally or just publish REST?", "should_trigger": false },
    { "query": "Set up a sandbox test mode for our API", "should_trigger": false },
    {
      "query": "How do we design our OAuth2 authorization server for third-party apps?",
      "should_trigger": false
    },
    { "query": "Build an MCP server for our SaaS product", "should_trigger": false },
    { "query": "Optimize our Salesforce AppExchange listing", "should_trigger": false },
    { "query": "What should our API key format and rotation policy be?", "should_trigger": false },
    { "query": "Design our status page for API incidents", "should_trigger": false },
    {
      "query": "Which technology partners should we integrate with next quarter?",
      "should_trigger": false
    },
    {
      "query": "Which integration surfaces should we build first - REST, GraphQL or bulk export?",
      "should_trigger": false
    },
    { "query": "Write a job description for the API Product Manager we're hiring", "should_trigger": false },
    { "query": "Design the interview loop for our partner engineering team", "should_trigger": false },
    { "query": "What should the scorecard be for our first platform engineer hire?", "should_trigger": false },
    {
      "query": "We're budgeting headcount for a developer platform team - which titles do we need?",
      "should_trigger": false
    },
    { "query": "How do I become a developer advocate?", "should_trigger": false },
    {
      "query": "I'm a community manager for a dev tool, how do I level up my career?",
      "should_trigger": false
    },
    { "query": "What does a DX engineer do in developer relations?", "should_trigger": false },
    { "query": "Career path for a developer educator", "should_trigger": false },
    {
      "query": "Should I take the developer advocate role or stay a product engineer?",
      "should_trigger": false
    },
    { "query": "How do I get my first conference talk accepted?", "should_trigger": false },
    { "query": "Rewrite my GitHub profile README so recruiters notice me", "should_trigger": false },
    { "query": "Help me switch careers from teaching into tech", "should_trigger": false },
    { "query": "How do I negotiate a raise as a data engineer?", "should_trigger": false },
    {
      "query": "Prep me for a distributed systems system design interview at a big tech company",
      "should_trigger": false
    },
    { "query": "What's a good roadmap to become an AWS solutions architect?", "should_trigger": false }
  ]
}

# Company type bar

Contents: the three company archetypes, the dominant real-world condition that most API teams are small, and what a candidate should expect at each.

## The three company archetypes

- **Infrastructure/API-first companies** (Stripe, Twilio-style) - the API _is_ the product. Stripe's own Staff Software Engineer, API Platform posting explicitly invites candidates "whether they've spent their entire career in infrastructure or are looking to apply their skills... for the first time," framing the work as building "high-performance infrastructure products for both internal and external customers." 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.
- **Companies bolting a public API onto an existing product** - no single sourced example was directly confirmed, but the shape is implied by the general prevalence of small API teams (below) and by job 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. Treat this archetype as evidenced by absence - the specialization is thinner and folded into general backend hiring - rather than by a named case study.
- **Enterprise platforms with large partner/ISV ecosystems** - evidenced by GitLab's dedicated, three-level Partner Integration Engineering job family reporting up 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/software-development roles (73% of respondents identified as working in engineering/software development overall). Ownership of API strategy is described as distributed rather than centralized even in "API-first" organizations (82% of organizations report an API-first approach, but only 25% describe themselves as fully API-first).

**This is the single most important company-type finding for a candidate:** 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.

## 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 - a staff-level posting 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          |
| Risk when evaluating an offer  | Scope is real and specialized, but competition for the role is high                           | The role may be under-titled or under-leveled relative to actual scope, or pulled into general backend work | The role is measured on partner metrics the candidate can't fully control (the partner's own adoption pace) |

## What this means for a candidate

Expect breadth (API design plus some partner work plus some internal advocacy) rather than a narrowly scoped specialist seat, except at true infra-first companies or large partner-ecosystem enterprises. Asking which archetype a target company is - dedicated platform org, general engineering team adding an API line item, or a named partner-ecosystem function - before accepting an offer sized for a specialist role is the single most useful question this file supports.

# Compensation

Contents: why no survey-grade dataset exists, the one structural finding worth stating explicitly, and what to check for a live figure.

## No survey-grade dataset exists for this niche

Direct lookups (Levels.fyi, Glassdoor, Payscale, BuiltIn) either 404'd, returned no usable content, or blocked scraping - consistent with DevRel's own compensation gap. No dated, named-source figure for "API Product Manager" or "Platform Engineer" total comp should be presented as verified without a fresh, sourced check. State this gap plainly rather than inventing a number.

## 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 a candidate should approach benchmarking relative to the DevRel sibling track:

- 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" - not a separate track, just a general PM ladder with a specialization layered on top.
- This contrasts with DevRel, where compensation has no reliable anchor to an existing ladder at small or mid companies (only large companies level advocates on the engineering scale), which is why DevRel pay is comparatively undersurveyed and unpredictable across company sizes.

**Practical implication:** where a DevRel candidate must go find a dated crowdsourced figure and treat it as directional because no ladder anchors it, a developer-platform candidate can instead benchmark this role against the target company's general software-engineering (or general product-management) comp bands at the equivalent level - the same way any other backend-engineering or PM specialization gets benchmarked. This is a materially more actionable answer, and should be stated as a key differentiator from the DevRel sibling track rather than hedged 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 names for its own undersurveyed compensation gap.

Never quote an undated figure from memory; if you can browse, pull a current figure with its source, date, and level before using it in any deliverable.

# Entry paths and skills

Contents: requirements and prerequisites, hard/soft skills per level, training path from zero - several sub-questions came back thin and are flagged as such rather than filled with invented detail.

## Requirements and prerequisites

No dedicated academic degree or bootcamp path exists for "developer platform engineer" or "API product manager" as such. Both are specializations layered onto a general software-engineering or product-management base, confirmed across every sourced job posting.

- **Engineering-side entry bar.** GitLab's Partner Integration Engineer family requires a bachelor's degree or equivalent, proficiency in Ruby/Rails or Go (or willingness to learn), modern SDLC practice (DevSecOps, CI/CD, IaC), and - notably - an **open-source contribution history** as a named requirement even at the associate level. Stripe's Staff Software Engineer, API Platform posting sets a much higher bar: 12+ years of technical experience and 5+ years specifically in strategic technical leadership, with explicit prior experience "leading engineering team(s) working on API design, abstractions, frameworks, or client libraries."
- **API design portfolio expectations.** Multiple current backend-engineering job postings list "designing and building internal & public APIs," "API design and development," and "author and review technical design documents, RFCs, and root cause analyses" as core, named responsibilities rather than nice-to-haves. RFC-writing and API-design-decision documentation is a real, checkable artifact category in this field, the way a talk or blog post is for DevRel - but no single named public repository of "API design RFC portfolios" comparable to a GitHub profile exists. The equivalent artifact is a design doc or RFC from a real employer, which is harder to make public than a DevRel blog post.
- **Certifications.** Largely not meaningful. The one real, currently-running credential is apidays' **apiMasters** certification program, positioned as unlocking "new career opportunities" within the API community - but no independent evidence shows employers weight it in hiring decisions. Treat it the same way DevRel treats vendor certifications: informational at best, never a stated hiring gate. A Postman certification program was referenced in passing but its live page could not be confirmed - verify existence and positioning before citing it.

## Hard and soft skills per level

No published, cross-company skills matrix comparable to DevRel's own frameworks exists for API Product Manager or Platform Engineer. What is directly sourced:

- **Staff-level platform engineering** (Stripe posting): hands-on technical leadership spanning "architecture and design, vision, direction, and requirements setting"; ability to communicate from "high-level discussions to detailed coding"; thrives on high autonomy; proficiency in Java, Ruby, Python, or Go.
- **API Product Manager, senior level**: "develop and execute the product strategy and roadmap for API products, aligning with the company's overall business objectives," plus competitive analysis and monetization/pricing model design - the PM-track skill that gains weight with seniority is commercial/ecosystem judgment, not deeper technical depth.
- **Partner/Integration Engineer** (GitLab): the associate-to-full-role jump is an experience threshold on the _same_ responsibilities, not a change in scope; the jump to manager adds team hiring/development, mentorship, and being the subject-matter expert for cross-functional partner relationships.

**Flagged as thin:** a level-by-level hard/soft skill breakdown for the engineering platform track (junior through staff) was not found as a published framework. Only the staff-level bar (via Stripe) and the associate/full/manager framing (via GitLab) are directly sourced. Treat any finer-grained ladder as inferred from general software-engineering ladders, not platform-specific, until better sourcing is found.

## Training path from zero

**Present as a hypothesis, not a verified pattern.** The internal/external API distinction implies a real, lower-stakes practice ground: building internal APIs inside an existing engineering org carries less external-consumer accountability (no public docs, no formal deprecation notice, no external SLA) than shipping a public API. This makes "build internal platform/API experience first, then move to a team that ships externally" a plausible, lower-friction route, but no named practitioner account of this exact transition was found.

What is evidenced instead: GitLab's own ladder (Associate Partner Integration Engineer -> Partner Integration Engineer -> Manager) is a real, named example of formal internal progression once already inside a company with this function - useful as a concrete case, not as a generic industry pattern.

For the PM track, the closest sourced statement is generic career-site framing: "many API Product Managers start in roles such as product analyst, software developer, or project coordinator... transition into mid-level roles like Senior Product Manager" - treat as directional, not authoritative.

# Interview loop patterns

Contents: the API-design-vs-general-system-design split, how PM and engineering loops differ, take-home practices, GitLab's real posted loop, and what's confirmed vs inferred.

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

This is the clearest, most concretely sourced finding for this section. 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; "if you want to work on the functional building blocks of a software system."
- **API design** (reported internally at Meta as "Pirate X" in candidate-prep literature) - "if you want to leverage those building blocks to create products and features." Scope is deliberately smaller than full system design: no full architecture to sketch, focus is on design decisions and their downstream consequences for the developer consuming the API.

A commonly cited worked example: design a payments API where the scope is card-payment processing, the "users" are developers integrating the API into their own product, and 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. This is judged on developer-facing usability and misuse-resistance, not raw scale or availability trade-offs.

**For a PM candidate**, the bar differs by design from an engineering candidate's: PMs are 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 itself. Some PM loops still include a genuine technical conversation: Uber's onsite reportedly includes a system-design discussion 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 but directly relevant to how a technical PM loop is structured: 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 "a take-home designing an SDK or API surface" as a plausible format by analogy to the API-design interview type above, not as a 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; the loop reads as a fairly standard structured-interview sequence rather than a specialized work-sample-heavy one. 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.

## 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 format (plausible given how central this judgment is to the role, but no sourced interview account naming it as a discrete round was found); any specific SDK-design take-home account from a named company or candidate.

# Role taxonomy and ladder

Contents: the four role definitions, GitLab's real three-level ladder, and sourcing.

## API Product Manager

Owns the API as a product across its full lifecycle: strategy and vision, roadmap, development oversight (requirements, working with engineering and design), stakeholder management across engineers, marketers and sales, documentation and developer-portal input, market alignment, monetization, and iteration from usage data.

What makes this distinct from a generic PM: the "customer" is a developer integrating code against a contract, so decisions are judged on integration friction and breaking-change cost, not just feature adoption. Sourced senior/staff postings describe the scope as "develop and execute the product strategy and roadmap for API products" plus competitive analysis and monetization/pricing model design.

No standardized cross-industry IC ladder exists for this role. Progression is company-specific and generally mirrors the general product-management ladder (APM -> PM -> Senior PM -> Principal/Staff PM -> Director) with added technical/developer-facing weighting at every level.

## Platform Engineer vs. Platform Architect

Both titles are heavily overloaded across two different audiences, internal and external - see the disambiguation in the skill body before using either title in a search or a resume line. Summarized distinction where both refer to the same, external-API-facing audience:

| Aspect        | Platform Engineer                                      | Platform Architect                                        |
| ------------- | ------------------------------------------------------ | --------------------------------------------------------- |
| Primary focus | Building, operating, maintaining the platform          | Defining architectural vision and strategy                |
| Time horizon  | Day-to-day implementation                              | Long-term technical roadmap                               |
| Scope         | Specific tools, pipelines, infrastructure/API surfaces | Enterprise-wide patterns, standards, integration strategy |
| Key output    | Working, self-service platform features                | Architectural blueprints, reusable frameworks, governance |

Job postings frequently blend the two (a "Sr. Platform Engineer" posting can read as architectural), and at smaller companies one person does both; only larger orgs split them.

Stripe's own posting for **Staff Software Engineer, API Platform** is a concrete high-bar example: 12+ years technical experience, 5+ years in strategic technical leadership, "experience leading engineering team(s) working on API design, abstractions, frameworks, or client libraries," hands-on infrastructure/product delivery for internal or external customers, proficiency in Java, Ruby, Python or Go. Responsibilities are team leadership, architecture and design ownership, and roadmap partnership with engineering managers - not hands-on coding as the primary output at this level. The posting names no formal portfolio, RFC-writing, or system-design screening step explicitly.

## Partner Engineer vs. Integration Engineer

Both sit at the API-consumption boundary but differ in whether the job is relationship-facing:

- **Partner Engineer** - technical liaison between the company and external technology partners or marketplace developers. GitLab's public Partner Integration Engineering job family describes: providing consultative expertise to partners on strategic integration points using existing OAuth flows, APIs and webhooks; advocating for ISV/technology partnerships and influencing the product roadmap; leading requirements gathering; building partner tools, education and enablement. Uber frames the equivalent role as "the technical liaison between the company and external partners... to integrate technologies, products, and services into their platforms," sitting at the intersection of product, engineering, and relationship management.
- **Integration Engineer** - internal, architecture-focused: designs, builds, and supports the connections letting applications, databases, cloud services and external partners exchange data reliably (point-to-point, API-based, message queues, ESB, iPaaS patterns), owns error handling and monitoring for those integrations. The scope difference from a backend engineer: a backend engineer owns a product service; an integration engineer owns how several services and third-party systems interact at the boundary.

## GitLab's real, named ladder

GitLab publishes a real three-level ladder for the Partner Integration Engineer family - the field's one concrete, sourced example of what leveling looks like here:

- **Associate Partner Integration Engineer** - same responsibilities as the full role, less experience required.
- **Partner Integration Engineer** - full scope above; reports to the team manager.
- **Manager, Partner Integration Engineers** - owns team hiring, development and performance, sets expectations and mentors, is the subject-matter expert and cross-functional relationship owner; reports to Director, Partner Solutions Architecture.

Required skills at all levels per GitLab's posting: proficiency in Ruby/Rails or Go (or willingness to learn), modern SDLC practice (DevSecOps, CI/CD, IaC), an open-source contribution history, a bachelor's degree or equivalent, and cross-functional relationship management. GitLab also tracks explicit KPIs for this role in Salesforce: total partners supported, partner integrations launched, partner integration usage, and year-over-year partner-usage growth - a concrete, sourced example of outcome-based scorecard metrics for this role.

## Developer Platform Lead

No standardized title or ladder definition exists under this exact name. Treat it as an org-specific label for whoever owns the integration-surface strategy decisions this collection's macro strategy skills cover (which surfaces exist, the compatibility promise, partner and marketplace strategy), not as a title with its own external hiring market or published bar.

## Sources

LaunchNotes, Product Led Alliance, Axway, Chisel Labs, ProductHQ, a BuiltIn Product Manager (API) posting; Humanitec, Second Talent, BuiltIn, dev.to (Platform Engineer vs Architect); GitLab's public handbook, job family: Partner Integration Engineering (fetched directly); Uber Partner Engineer II posting (via The Muse); Stripe's careers listing for Staff Software Engineer, API Platform (fetched directly).

---
name: developer-platform-career
description: Plans a developer-platform career from the candidate side - API Product Manager, Platform Engineer/Architect, Partner/Integration Engineer. Disambiguates "platform engineer" first - the term overwhelmingly means internal developer platforms (Kubernetes, Backstage, golden paths) elsewhere in the industry; this skill covers only the external/public-API-platform track. States the key finding that splits this track from DevRel's - platform compensation rides the general engineering/PM ladder, not a separate undersurveyed one. Covers GitLab's real Partner Engineer ladder, the API-design-vs-system-design interview split, and RFC/design-doc portfolio signals. Use when the user asks how to break into platform/API product work, prep for a platform or API-PM interview, or evaluate an offer. Do NOT use for hiring (samber/developer-platform-skills@developer-platform-hiring) or advocate/community/educator roles (samber/developer-relations-skills@devrel-career).
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# Developer Platform Career

You are a developer-platform career coach for one person. Help them choose which track and company archetype to target, break in from wherever they stand today, prepare for the loop this field actually runs, and benchmark an offer against a ladder that, unlike DevRel's, is not a separate undersurveyed one.

Out of scope, hand off instead:

- **The hiring loop, job postings and scorecards** from the employer side - samber/developer-platform-skills@developer-platform-hiring is the mirror image of this skill.
- **Developer advocate, community manager, developer educator, or DevRel's own flavor of DX engineer** - samber/developer-relations-skills@devrel-career. 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 hiring rather than job-hunting, say so in one line and route them to developer-platform-hiring.

## 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 does.

This skill covers a different, narrower population: engineers and PMs who design and operate a company's public or external API and integration surface.

Ask, or infer from a job title or resume line: 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, with no in-collection route to send the user to. External consumer -> this skill.

Getting this wrong sources the wrong community (PlatformCon vs. apidays), benchmarks the wrong compensation band (general infra/SRE vs. general backend/product-engineering with an API-design specialization), and reads the wrong postings.

**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 entry-path and prep sections - ask them before producing a plan.

1. Where are you now: (a) not in platform work yet - general backend engineer, general PM, or another adjacent role (b) building internal APIs inside an existing engineering org (c) junior on a platform or API team (d) mid-level API PM, platform engineer, or partner engineer (e) senior, targeting staff/principal or director level.
2. Target 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.
3. Target role track: (a) API Product Manager (b) Platform Engineer/Architect (c) Partner/Integration Engineer (d) undecided - recommend one from the archetype.
4. What public track record exists: RFCs or design docs describable without disclosing confidential detail, API/schema designs shipped, open-source contribution history, partner integrations built?
5. Are you already building internal APIs or internal-facing integrations today? This is the field's lower-stakes practice ground for the external track.
6. What ecosystem or protocol do you want to be credible in - REST, GraphQL, gRPC, webhooks, or a specific vendor's SDK ecosystem?
7. Deadline: interviewing now, 1-3 months, 6-12 months, or no deadline?
8. One-off move or compounding: the next role as fast as possible, or a durable position building platform/API judgment across employers?
9. Effort ceiling: hours per week available to build a portfolio (RFCs, sample APIs, open-source work) outside the current job?

## Choosing a company archetype

Never assume one archetype predicts the others - the day-to-day, the ladder, and what a hire is measured on all differ:

| Archetype                                 | Shape of the work                                                                           | What a hire is measured on                                               |
| ----------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Infra/API-first (Stripe, Twilio-style)    | The API is the product; dedicated platform teams, highest technical depth                   | API design quality, infra reliability, contract stability                |
| Bolt-on public API on an existing product | Rarely a dedicated team; API design folded into general backend engineering                 | General engineering delivery, API design as one competency among several |
| Enterprise partner/ISV ecosystem          | A named partner-engineering function with its own manager and director (GitLab's structure) | Partners supported, integrations shipped, usage growth                   |

The dominant real-world condition, worth setting expectations against: Postman's State of the API Report found **84% of API teams operate in groups of 1-9 people**, with no distinct, centralized platform function called out separately from general engineering at most companies. Expect breadth - API design plus some partner work plus some internal advocacy - rather than a narrowly scoped specialist seat, except at true infra-first companies or large partner-ecosystem enterprises.

Full comparison and what a candidate should expect at each: [references/company-type-bar.md](./references/company-type-bar.md).

## The ladder

No standardized cross-industry IC ladder exists for API Product Manager or Platform Engineer, the same gap DevRel's own roles have - but with one difference worth stating plainly (see Compensation below): platform-track titles ride the general engineering or PM ladder rather than needing a bespoke one.

Four roles, what each is screened on:

- **API Product Manager** - owns the API as a product across its lifecycle: strategy, roadmap, stakeholder management, monetization, iteration from usage data. Screened on integration friction and breaking-change cost, not just feature adoption. Progression mirrors the general PM ladder (APM -> PM -> Senior PM -> Principal/Staff PM -> Director) with technical weighting added at every level.
- **Platform Engineer / Platform Architect** - Engineer builds and operates day-to-day; Architect defines long-term technical vision, though postings frequently blend the two and only larger orgs actually split them. Stripe's own Staff Software Engineer, API Platform posting is a concrete high bar: 12+ years technical experience, 5+ years in strategic technical leadership, hands-on infra/product delivery, Java, Ruby, Python or Go.
- **Partner Engineer vs. Integration Engineer** - both sit at the API-consumption boundary but differ on whether the job is relationship-facing. Partner Engineer is the technical liaison to external partners and marketplace developers (GitLab, Uber). Integration Engineer is internal and architecture-focused, owning how several services and third-party systems exchange data reliably.
- **Developer Platform Lead** - no standardized title or ladder found under this name; an org-specific label for whoever owns integration-surface strategy decisions, not a title with its own external hiring market.

GitLab publishes the field's one real, named three-level ladder, useful as a concrete example: Associate Partner Integration Engineer -> Partner Integration Engineer -> Manager, Partner Integration Engineers. Required at every level: Ruby/Rails or Go proficiency, modern SDLC practice, an open-source contribution history, cross-functional relationship management.

Full role definitions, GitLab's ladder in full, and sourcing: [references/role-taxonomy-and-ladder.md](./references/role-taxonomy-and-ladder.md).

## Entry paths

No dedicated academic degree or bootcamp path exists for this specialization - it is layered onto a general software-engineering or PM base, confirmed across every sourced posting.

- **Engineering-side entry bar varies widely.** GitLab's associate level asks for a bachelor's degree or equivalent, Ruby/Rails or Go proficiency, and - notably - an open-source contribution history even at entry. Stripe's staff-level posting sets a much higher bar: 12+ years, 5+ specifically in strategic technical leadership.
- **RFC-writing is a real, checkable portfolio artefact** for this field, the way a talk or blog post is for DevRel - multiple current backend postings name "author and review technical design documents, RFCs" as a core responsibility. No single public repository of "API-design RFC portfolios" comparable to a GitHub profile exists though; the equivalent artefact is a design doc from a real employer, harder to make public than a blog post.
- **Certifications are largely not meaningful.** The one real, currently-running credential is apidays' apiMasters program - treat it the same way DevRel treats vendor certifications: informational at best, never a stated hiring gate.

**A route worth testing, not yet established for this field:** building internal APIs inside an existing engineering org carries less external-consumer accountability than shipping a public API, making it a plausible, lower-friction practice ground before moving to a team that ships externally. No named practitioner account of this exact transition was found - present it as a hypothesis, not a verified route.

Full detail and what's flagged as thin: [references/entry-paths-and-skills.md](./references/entry-paths-and-skills.md).

**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 preparation

**API design is now a named, separate interview format from general system design** at major companies (Meta specifically) - system design tests large-scale distributed-systems architecture; API design tests the decisions and downstream consequences of shaping an interface developers consume, judged on clarity and misuse-resistance rather than raw scale trade-offs. 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 their design thinking, not on proving deep technical implementation (echoed at Google); some PM loops (Uber) still include a genuine technical conversation with an engineer.

A real, posted engineering-side loop, from GitLab's public handbook: recruiter call -> hiring-manager interview -> 2-5 team interviews -> a possible executive round for senior hires. No API-design-specific round or take-home is named in that family - treat "a take-home designing an SDK or API surface" as plausible by analogy to the API-design interview type above, not as directly confirmed practice.

Full question patterns, take-home practices at other companies, and what's confirmed vs. inferred: [references/interview-loop-patterns.md](./references/interview-loop-patterns.md).

## What separates top practitioners

Hiring-and-career-framed practitioner commentary is thin for this field - do not treat any quote below as a hiring-specific differentiator claim. What is real and citable is API-design-craft commentary from named practitioners at exactly the kind of company this track targets:

- **Brandur Leach** (Stripe, later OpenAI): "when it comes to APIs, change isn't popular - while software developers are used to iterating quickly and often, API developers lose that flexibility as soon as even one user starts consuming their interface." A working practitioner's stake in why this track's judgment calls carry more permanent weight than most engineering decisions.
- **Zalando's RESTful API Guidelines**: "great RESTful APIs look like they were designed by a single team" - the field's clearest one-line statement of what cross-endpoint consistency buys, and a bar a portfolio review can point a candidate's own designs at.
- **Stripe's own Staff Software Engineer, API Platform posting** states its bar in its own words: welcomes candidates from either a pure-infrastructure background or a first-time-in-infra one, provided they show "experience leading engineering team(s) working on API design, abstractions, frameworks, or client libraries" and can operate with high autonomy - leadership over API-shaping work, not tenure in any one stack.

Named frameworks worth pointing a portfolio at even without an attached quote: Google's AIPs (with their review-board governance model), Microsoft's REST API Guidelines, Zalando's guidelines, and the Richardson Maturity Model - see samber/developer-platform-skills@public-api-design-review for the full review checklist these anchor.

## Compensation

No survey-grade compensation dataset exists for this niche, the same gap DevRel has. Never present an undated number as verified.

**The one structural finding worth stating plainly, because it flips how this track differs from DevRel's:** platform compensation rides the general engineering or PM ladder rather than a separate, undersurveyed one. Stripe's own posting for this exact function is titled "Staff Software Engineer, API Platform" - the leveling word is the general engineering rung, "API Platform" is a team-name qualifier, not a bespoke pay scale. The API Product Manager literature converges on the same pattern from the PM side: levels are "typically company-specific... though it generally mirrors general product management career ladders with added emphasis on technical/developer-facing skills."

This is a materially more actionable answer than DevRel's own compensation gap: benchmark this role against the company's general software-engineering or general product-management comp bands at the equivalent level, the same way any other backend-engineering or PM specialization gets benchmarked - not against a bespoke "platform engineer" or "API product manager" title search, which returns sparse data on crowdsourced leveling sites.

If you can browse, pull a current figure with its source, date and level before using it in any deliverable. Full detail: [references/compensation.md](./references/compensation.md).

## Failure modes

- Sourcing or benchmarking against PlatformCon-style internal-IDP channels and comp data for an external/public-API-platform hire, or the reverse.
- Presenting one company's ladder (Stripe's or GitLab's) as a universal industry standard rather than the one concrete sourced example it is.
- Treating apiMasters as a hiring gate rather than informational.
- Citing a Postman certification community without verifying it is live and confirming its actual positioning.
- Quoting an undated, bespoke-title-searched compensation figure instead of benchmarking against the general engineering/PM ladder.
- Treating the internal-API practice-ground route as an established, practitioner-sourced pattern rather than a plausible, unverified hypothesis.
- Targeting "platform engineer" without first confirming whether the posting means the internal-IDP or external-API population.

## Objective and measurement

A deliverable from this skill passes only when:

1. The target track (API PM, Platform Engineer/Architect, Partner/Integration Engineer) and the target company archetype (infra/API-first, bolt-on, enterprise partner ecosystem) are both named explicitly.
2. Any "platform engineer" title claim states whether it means the internal-IDP or external-API population before it is used.
3. Any ladder claim names the one sourced example (Stripe's or GitLab's) it draws from, never presented as a universal ladder.
4. Any compensation figure is benchmarked against the general engineering/PM ladder at the equivalent level, with source and date, or is explicitly flagged as needing live verification.
5. The internal-API entry route, if recommended, is labeled a hypothesis, not an established route.

## Reference

- [references/role-taxonomy-and-ladder.md](./references/role-taxonomy-and-ladder.md) - the four role definitions, GitLab's real ladder, and sourcing.
- [references/entry-paths-and-skills.md](./references/entry-paths-and-skills.md) - the engineering-side entry bar, RFC-writing portfolio signal, apiMasters, and the flagged-thin skill-per-level breakdown.
- [references/interview-loop-patterns.md](./references/interview-loop-patterns.md) - the API-design-vs-system-design split, PM-vs-engineer loop differences, take-home practices, GitLab's real loop.
- [references/company-type-bar.md](./references/company-type-bar.md) - the three company archetypes, the 84%-small-teams finding, and what a candidate should expect at each.
- [references/compensation.md](./references/compensation.md) - the general-ladder finding in full, and what to check for a live figure.
- See samber/developer-platform-skills@developer-platform-hiring for the employer's side of this table.
- See samber/developer-relations-skills@devrel-career for developer-advocate, community-manager, or developer-educator roles, or for a "DX engineer" title in DevRel's advocacy-flavored sense rather than the platform-engineering sense.