​​Platform Engineer, Onboard Compute

We need to output HTML fragment with sections: About the role, Responsibilities, Requirements (or Qualifications), Skills? The posting includes "Required Qualifications" and "Nice-to-Have Skills". Also "Salary" section. Also maybe "About Muon Space" and "Taking Care of Our Team" but those are boilerplate? The instruction: remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. The "About Muon Space" and "Taking Care of Our Team" might be considered boilerplate? Not exactly; they are about company and benefits. Benefits are described there. The instruction: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text. Benefits: they list medical, dental, vision, 401k, disability, life insurance, three weeks paid vacation, 12 paid holidays, unlimited sick time, paid parental leave. That's specific. So we should include Benefits section. Pay: they have salary range $190,000 - $212,000 plus equity grant. So include Pay section. Schedule: they mention hybrid, requires working on-site three days per week. That's schedule info. So include Schedule section. We need headings:

for section headings (About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). However they say "Prefer a few substantive sections over many thin ones." We can combine Requirements and Qualifications? The posting has "Required Qualifications" and "Nice-to-Have Skills". Could have sections: Responsibilities, Required Qualifications, Nice-to-Have Skills, Benefits, Pay, Schedule. Also About the role maybe not needed because they said do NOT repeat the job title as a heading (the page already shows it) and do NOT put Job ID / requisition numbers as headings. About the role is a section heading; we can include it if there is substantive content. The "About The Role" paragraph at start is substantive. So include About the role. Thus sections: About the role, Responsibilities, Required Qualifications, Nice-to-Have Skills, Benefits, Pay, Schedule. We must use

• for any list of duties/requirements/benefits, and

  for prose. We need to preserve all substantive information, not invent or summarize away detail. Remove boilerplate: cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. Also remove ITAR/EAR Requirements? That's legal/export control; likely considered boilerplate? It's a requirement but maybe legal. The instruction says remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate. ITAR/EAR is legal export control; likely should be removed. Also "About Muon Space" and "Taking Care of Our Team" maybe considered boilerplate? But they contain benefits specifics; we already extracted benefits. The rest of that text is generic company description; could be considered boilerplate. Safer to remove it, as it's not specific to the role. The instruction: "Prefer a few substantive sections over many thin ones." So we can omit About Muon Space and Taking Care of Our Team. Thus we will produce:

  About the role

  Muon Space is looking for a Platform Engineer to own the shared technical foundation of our High Performance Compute (HPC) team. This is an engineering-track, individual-contributor role. You'll own the build flows, test environments, and delivery pipelines that turn FPGA and GPU engineering output into flight-ready artifacts, and the planning and reporting rhythm that keeps the team predictable across a growing portfolio of missions. As Muon takes on more missions with more varied compute needs, your job is to keep the platform coherent while maximizing reuse across missions, minimizing variations, and making sure our delivery methods and planning methods evolve together. This position is hybrid and requires working on-site in our San Jose, CA office three days per week.

  Then Responsibilities: we have bullet points under "Platform, Build & Delivery", "Planning, Delivery & the Intersection Between Them", "Knowledge & Enablement". We'll combine into a single
  with items. We need to preserve all substantive information; not invent or summarize away detail. So we need to include each bullet as
  • . Let's extract bullet points: From Responsibilities: Platform, Build & Delivery - Maintain and evolve the technical build flows, test environments, and delivery and integration pipelines for both FPGA and GPU code, ensuring reproducible, reliable, and fast turnaround from commit to lab-ready artifact. - Own the toolchain environments (synthesis, simulation, cross-compilation, containerized builds) and keep them up-to-date, documented, and consistent across engineers. - Manage the complexity of delivering into a growing variety of future missions, actively working to keep mission-to-mission variations as small as possible, and promoting shared components. Planning, Delivery & the Intersection Between Them - Operate at the intersection of delivery methods and planning methods, ensuring the way we plan reflects how we actually build and deliver, and that both evolve together as the team and mission portfolio grow. - Own the team's roadmap in Jira: keep it accurate and trackable at all times; enable on-demand snapshot reporting that shows progress, priorities, and resource utilization. - Partner with tech leads and engineers to estimate incoming work packages for upcoming missions and inbound requests from other teams and departments. - Establish and track planning-accuracy metrics and use them to improve estimation quality. - Publish weekly reports on the team's state of health: successes, risks, opportunities, blockers, and highlights: for team-internal and cross-company audiences and be the single source of truth for status, progress, and Jira reporting for the Onboard Compute organization. Knowledge & Enablement - Own the team's Confluence space: keep it representative of the team's actual work and focus, and support engineers in contributing content. - Partner with the engineering managers to maintain a comprehensive set of onboarding and training material, including tooling, build-flow, and platform documentation. We'll put all these as
  • items. Next Required Qualifications: list: - Bachelor's degree in Computer Science, Computer Engineering, Electrical Engineering, or a related technical field, plus 3+ years of professional engineering experience. - Hands-on development experience with FPGA and/or GPU workflows, including synthesis or compilation toolchains, simulation or profiling environments, and build/release pipelines. Direct experience on both is a strong plus; deep experience on one plus willingness to learn the other is acceptable. - Experience owning or significantly contributing to build systems, test environments, and integration pipelines for embedded or hardware-adjacent codebases. - Demonstrated ability to manage variation and complexity across multiple products, missions, or configurations, for example by defining shared components, reference flows, or platform contracts that reduce one-off work. - Comfort scripting to automate toolchains, orchestrate pipelines, and generate reports. - Demonstrated fluency with Jira (structuring epics/stories, dashboards, JQL, reporting) and Confluence. - Proven ability to drive estimation and planning discussions with engineers, and to translate technical work into clear roadmaps and reports for non-engineering stakeholders. - Excellent written and verbal communication skills, with a talent for making complex work legible to executives, adjacent teams, and new hires. We'll put each as
  • . Nice-to-Have Skills: - Prior role as a Platform, Engineering Productivity, Developer Experience, DevOps, or Build/Release engineer supporting an FPGA, embedded, or GPU team. - Hands-on experience with FPGA build flows (Vivado, Quartus, or similar) and/or GPU cross-compilation for embedded platforms (e.g., NVIDIA Jetson/IGX-class). - Experience managing a shared platform, product line, or reference design across multiple downstream consumers or missions. - Experience with hardware-in-the-loop test automation and lab-bench regression infrastructure. - Familiarity with containerization and development pipeline tooling. - Prior exposure to space, aerospace, or other mission-critical engineering environments. We'll put as
  • . Benefits: from "Taking Care of Our Team": medical, dental, vision insurance, 401k retirement plan, short & long term disability and life insurance, three weeks paid vacation for new employees, 12 paid holidays, unlimited sick time, paid parental leave. Also equity compensation mentioned earlier. We'll list as
  • . Pay: Salary range $190,000 - $212,000, plus a competitive equity grant. We'll put as

    maybe but could be

    with one item? The instruction: Use
    • for any list of duties/requirements/benefits, and

      for prose. Pay is not a list; we can use

      . But we could also use

      with one
      • . Safer to use

        . Schedule: hybrid, requires working on-site in San Jose, CA office three days per week. We'll put as

        . We must not include any markdown code fences. Output only HTML fragment. Let's craft. Check for any duplicated lines: we have not duplicated. Ensure we didn't include boilerplate like "About Muon Space", "Taking Care of Our Team", ITAR/EAR, EEO statements. We included About the role paragraph (which includes hybrid mention; but we also have Schedule section repeating hybrid? The About the role includes "This position is hybrid and requires working on-site in our San Jose, CA office three days per week." That's schedule info. To avoid duplication, we could remove that sentence from About the role and keep only in Schedule. But we must preserve ALL substantive information; we can't remove it. However we could keep it in About the role and not have a separate Schedule section, but then we lose a dedicated schedule heading. The instruction: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text. If we put schedule info in About the role, we could still have a Schedule section but it would be duplicate. Better to keep schedule info only in Schedule section and remove from About the role? That would be removing substantive information (the hybrid requirement). Not allowed. So we need to keep it somewhere; we could keep it in About the role and not have a Schedule section. But then we lose a Schedule heading; but the instruction says we can have few substantive sections; we could omit Schedule heading if we already covered schedule in About the role. However they said "Prefer a few substantive sections over many thin ones." Having schedule info in About the role is fine; we can omit Schedule section. But they also said use headings for sections like Schedule if present. If we omit Schedule heading, we are not violating any rule because we are not emitting a heading with filler. It's okay to omit a section if its content is covered elsewhere. However we must ensure we don't lose the schedule info. We'll keep it in About the role. Thus we will not have a separate Schedule section. We'll keep About the role paragraph as is (includes hybrid). Then we will not add Schedule heading. Similarly, Benefits we have. Pay we have. Thus sections: About the role, Responsibilities, Required Qualifications, Nice-to-Have Skills, Benefits, Pay. Check if any other sections like Skills? We have Nice-to-Have Skills. Now produce HTML. Let's write:

        About the role

        Muon Space is looking for a Platform Engineer to own the shared technical foundation of our High Performance Compute (HPC) team. This is an engineering-track, individual-contributor role. You'll own the build flows, test environments, and delivery pipelines that turn FPGA and GPU engineering output into flight-ready artifacts, and the planning and reporting rhythm that keeps the team predictable across a growing portfolio of missions. As Muon takes on more missions with more varied compute needs, your job is to keep the platform coherent while maximizing reuse across missions, minimizing variations, and making sure our delivery methods and planning methods evolve together. This position is hybrid and requires working on-site in our San Jose,