Platform Support Engineer

Platform Support Engineers are PhysicsX’s first technical responders for enterprise customers and internal users of the Platform. You’ll own the path from intake to resolution: triage, first-pass investigation, customer updates, and, where you can’t fix it yourself, a high-quality escalation to Product, SRE, FDSE or Deployment Engineering. This isn’t a service desk. You’re building the repeatable front door into PhysicsX’s deeper technical capability. This is a hybrid role working from our New York City office 3 days per week.

Own it, investigate it, fix it where you can. You’re the first engineer on every issue, and you own it until it’s closed, whether you resolve it yourself or bring in Product, SRE, FDSE or Deployment Engineering. Your goal is to resolve a growing share of issues without escalation, and to hand over a root-cause diagnosis rather than a symptom when you do escalate.

• Triage incoming issues, classify severity, and run the first-pass investigation across product, platform, infrastructure and customer environment to find where the problem most likely lies.
• Resolve what you can. When you can’t, hand over with the logs, events, config, timeline, what you’ve already tried, and a recommended next step.
• Work within a structured incident process: response targets, clean handovers, and post-mortems.

Debug inside the platform.

• Navigate Kubernetes (EKS, AKS and others): inspect workloads, ingress, permissions and cluster health, read events and logs, and work out what’s failing and why. You don’t need to be a cluster admin, but you do need to know when to hand over.
• Use Linux, container and Helm knowledge, monitoring signals (logs, metrics, alerts, Prometheus-style) and cloud fundamentals (networking, compute, storage, IAM) to tell whether a symptom points at the application, the cluster or the cloud layer.
• Time-box investigations and escalate promptly when progress stalls.

Work the GitOps way.

• Use the cluster to look and Git to change. Fixes go through reviewed pull requests (or a ready-to-review change handed to the owning team), because live edits get reverted by reconciliation (e.g. Argo CD) or drift from Git. Call out drift when you see it.
• When urgent action is needed to stabilise things (like restarting a workload), take it deliberately, record it on the ticket, and capture the lasting fix in Git.

Communicate clearly.

• Give customers and internal stakeholders plain-language updates: what’s known, what isn’t, and what happens next.
• Coach customer engineers step by step when you can’t access their environment, as with air-gapped deployments.
• Keep a defensible priority order across competing issues, and say explicitly what’s being deprioritised, why, and when it will be revisited.

Build the function.

• Write runbooks, capture repeatable fixes, and feed recurring issues back to Product and Platform teams so they’re fixed at the source.
• Work across SaaS, hosted/VPC and air-gapped deployments, and understand how release, scanning and promotion differ in each and what that means for resolution time.
• PhysicsX support is being stood up now, and tools (including ticketing) will change. Help shape what comes next.
• You’ll work with a globally distributed team. Coverage includes planned evening shifts and a weekend rota, with the pattern evolving as demand grows.

Must have

• Clear communication with non-technical stakeholders, including during live incidents and when guiding someone remotely
• Sound triage and escalation judgement: distinguishing PX defects from deployment/config issues and customer-side dependencies, knowing what justifies out-of-hours contact, and staying calm when something is broken
• Working Kubernetes familiarity: investigating pods that won’t start or keep restarting, and knowing when to hand over
• A GitOps mindset: Git as source of truth, PR-based change, environment promotion (Argo CD experience helps, but the mindset matters more than the tool)
• Strong Linux and troubleshooting fundamentals
• Cloud fundamentals (networking, compute, storage, IAM) and comfort reading logs, metrics and alerts
• Comfort working across teams and with change in a fast-moving, new function

Nice to have

• Experience with structured support or incident management (ITSM, severity classification, post-incident reviews)
• Hands-on Argo CD, Helm, Docker or YAML troubleshooting
• Deeper EKS/AKS experience
• Experience across SaaS, VPC and air-gapped deployments
• A habit of writing runbooks and improving playbooks

What we use today (a snapshot, not a requirement): Kubernetes, Argo CD, Docker, Helm, Prometheus-style monitoring, Linear for engineering work, Slack for coordination, and Zendesk for our ticketing platform.