DEVELOPER RELATIONS ENGINEER LOCATION: NORTH AMERICA REMOTE/SF-HYBRID · FULL-TIME ABOUT ANDROMEDA 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. THE ROLE 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. WHAT YOU'LL DO * 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. WHAT WE'RE LOOKING FOR * 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. NOT A FIT * DevRel as a speaking career: You measure the job in talks given and followers gained. * You need an established program: Here, you are the program. * You want to manage first: This is an IC role and will stay one for a while. STRONG CANDIDATES MAY HAVE * 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. WHAT SUCCESS LOOKS LIKE By the end of your first year: * Time-to-first-successful-run for new teams is measurably shorter, and you can point to the docs, tooling, and reference configs that did it. * Andromeda has a body of public technical work that engineers cite and share, and that our own team links to instead of re-explaining. * Customers reach for our documentation before they reach for us, and our solutions team spends its time on novel problems instead of repeat questions. * There is a real developer community around Andromeda with real technical discussion in it, and increasingly the answers come from members rather than from you. * At least one integration or OSS contribution you shipped is in active use by customers or partners. * At least one developer experience change you argued for made the roadmap and shipped. * The function has a shape: a content cadence, a docs process, and a clear view of what the next hire on this team should own. WHY YOU'LL LOVE IT HERE * You define what developer relations means at Andromeda, and the first version of it is yours. * We are a unicorn, and our customers are leading AI labs and data centers in one of the fastest-growing markets on earth. * Small senior team, a seat at the table with leadership, and impact measured in days, not quarters. * Cross-functional by design: you work with our product engineers and our solutions team, with a direct line to frontier customers and the roadmap. * North America remote, competitive pay, and meaningful equity. Healthcare, dental, and vision coverage for you and your dependents, plus 401(k) and unlimited PTO. Andromeda Cluster is an equal opportunity employer. We celebrate diversity and are committed to creating an inclusive environment for all employees. We do not discriminate on the basis of race, religion, color, national origin, gender, sexual orientation, age, marital status, veteran status, or disability status.

Developer Relations Engineer

Similar jobs

Explore related jobs