Developer Relations Engineer

Andromeda Cluster•San Francisco, CA

2d•Remote

About The Position

Andromeda Cluster was founded by Nat Friedman and Daniel Gross to give early-stage startups access to the kind of scaled AI infrastructure once reserved only for hyperscalers. We began with a single managed cluster — but it filled almost instantly. Since then, we've been quietly building the systems, network, and orchestration layer that makes the world's AI infrastructure more accessible. Today, Andromeda works with leading AI labs, data centers, and cloud providers to deliver compute when and where it's needed most. Our platform routes training and inference jobs across global supply, unlocking flexibility and efficiency in one of the fastest-growing markets on earth. Our long-term vision is to build the liquidity layer for global AI compute. We are expanding to new frontiers to find the brightest that work in AI infrastructure, research and engineering. This is an engineering role, not a marketing one. The output is other people's success on our platform. Today the fastest path to a first successful run at scale on Andromeda is a conversation with one of our engineers. That works for our largest accounts and will keep working. It does not scale, and the knowledge from those conversations stays in Slack threads where a stranger cannot find it at 2am. Your job is to turn that knowledge into artifacts: benchmarks that hold up to scrutiny, reference architectures people deploy, documentation an engineer trusts, and a developer community where the answer is already there before someone has to ask us. You will write code the whole time. The reference implementation for multi-node training on our platform, the preflight script someone runs before their first big job, the integration that makes a popular orchestration framework work cleanly on heterogeneous supply: those are your deliverables. When you write that a configuration gets a certain MFU, you ran it. Three audiences need different things from you. Frontier and AI lab engineering teams want depth and honesty, and they will catch you if you round a number in your favor. Early-stage teams want the shortest path from signup to a run that works, and they are unforgiving of friction. Providers and tooling partners want the platform to be legible enough to build against. You are our first DevRel hire, reporting to the Head of Product. Day to day the role is cross-functional engineering. You work with our product engineers and our solutions team on live customer runs, which gives you a direct line to real workloads and real failures. Reporting into product also puts you next to the people who decide what we build next, so when you find a rough edge you argue for the fix with them directly. You decide what this function becomes.

Requirements

You have run distributed training or large-scale inference in production.
You have debugged a stalled multi-node run, and you know the difference between a fabric problem and a dataloader problem because you have been wrong about it before.
Strong Python, with Go or Bash a plus.
You build and maintain production-grade tools and libraries, and you are comfortable owning a repo other people depend on.
Fluency across the modern stack: PyTorch, NCCL, containers, Kubernetes and/or Slurm, CUDA-adjacent tooling, and at least one serving framework (vLLM, SGLang, TensorRT-LLM, or equivalent).
Excellent technical writing. You explain something hard to a smart audience without condescension or hedging, and people share what you write without being asked.
Public work we can read or watch: blog posts, benchmarks, OSS contributions, docs you owned, talks you gave. A portfolio matters more than a title here.
Judgment about what to build. You can tell which artifact unblocks a hundred teams and which one only looks impressive, and you pick the first.
You ship in ambiguity: No playbook, no team to inherit, and the expectation that you define what good looks like and then hit it.

Nice To Haves

Time embedded with external engineering teams: solutions architecture, professional services, deployed engineering, or technical account ownership at an infrastructure company.
Performance engineering depth: profiling distributed jobs, reasoning about MFU, interconnect behavior, and checkpoint I/O bottlenecks.

Responsibilities

Technical content: Benchmarks, deep-dive posts, performance write-ups, postmortems worth publishing, and reference architectures for common training and serving stacks. Every claim is reproducible and every number is one you measured.
Developer documentation, end to end: Quickstarts, orchestration guides (Slurm, Kubernetes, direct SSH), storage and checkpointing patterns, and troubleshooting runbooks. Docs are a product with users, and you own the roadmap for them.
The developer community: The public channels, the GitHub presence, and the office hours. Set the tone, answer the hard questions yourself, and make it a place experienced infra engineers want to be.
Code that lowers the floor for new users: Example repos, container images, reference configs, and integrations with the frameworks and schedulers people already use.
What we learn from live workloads: Work with our solutions team on onboardings and incidents, work with our product engineers on the fixes, and turn what you learn into public artifacts so the next team avoids the same wall.
The developer's case internally: You will see our rough edges first. File the hard bugs, argue for the roadmap changes, and build the missing pieces yourself when that is the fastest path.
Partner and provider enablement: Integration guides, onboarding material, and the technical explanation that lets them build against the platform without a call.