Principal Engineer, Anthropic

• A strong track record building and operating production systems. This is a hands-on engineering role with a devops flavor
• Python and SQL at production quality. Most pipeline code is Python; the presentation layer is BigQuery SQL, including table-valued functions and views. Both need to be idiomatic, well-tested, and maintainable
• Deep experience with at least one major cloud provider (Amazon Web Services, Google Cloud, or Microsoft Azure) and its operations
• Experience with observability tooling stack, including Prometheus, PromQL, and Grafana, including writing recording rules and building monitoring that engineering teams rely on
• Ability to gather your own requirements and work across organizational boundaries in an ambiguous environment with limited direction
• Minimum education: Bachelor’s degree or an equivalent combination of education, training, and/or experience
• Required field of study: A field relevant to the role as demonstrated through coursework, training, or professional experience
• Minimum years of experience: Years of experience required will correlate with the internal job level requirements for the position
• Location-based hybrid policy: Currently, we expect all staff to be in one of our offices at least 25% of the time. However, some roles may require more time in our offices
• Visa sponsorship: We do sponsor visas! However, we aren't able to successfully sponsor visas for every role and every candidate. But if we make you an offer, we will make every reasonable effort to get you a visa, and we retain an immigration lawyer to help with this
• We encourage you to apply even if you do not believe you meet every single qualification

Desirable

• Anthropic manages one of the largest and fastest-growing infrastructure fleets in the industry — spanning multiple accelerator families, cpu families and clouds
• The Capacity Engineering team is responsible for making sure all our infrastructure resources are accounted for, well-utilized, and efficiently allocated
• We own the data, tooling, and operational systems that let Anthropic plan, measure, and maximize utilization across first-party and third-party compute
• As an engineer on Capacity Engineering, you will build the production systems that power this work: data pipelines that ingest and normalize telemetry from heterogeneous cloud environments, observability tooling that gives the org real-time visibility into fleet health, and performance instrumentation that measures how efficiently every major workload uses the hardware it’s running on
• You will be expected to write production-quality code every day, operate alongside Kubernetes-native infrastructure at meaningful scale, and directly influence decisions around one of Anthropic’s largest areas of spend
• You’ll collaborate closely with research engineering, infrastructure, inference, and finance teams
• The work requires someone who can move between data engineering, systems engineering, and observability with comfort — and who thrives in a high-autonomy, high-ambiguity environment
• This is a pipeline role feeding four areas
• Depending on your background and business priority, you’ll focus primarily in one, but the boundaries are fluid and the problems overlap:
• Data platform Pipelines that ingest occupancy and utilization telemetry from Kubernetes clusters, normalize billing and usage across cloud providers, and serve the BigQuery tables the rest of the org queries against. Correctness, completeness, and latency are the job, not a footnote. Consumers range from research engineers to finance to leadership, so it's product work as much as engineering: defining schema contracts, making data discoverable, and figuring out what people actually need
• Planning Knowing what the fleet has, where it's going, and what's in the way. Making the state of the fleet legible and actionable in real time: cluster health tooling, capacity planning platforms, alerting on occupancy drops and allocation problems, and systemic fixes to scheduling and fragmentation. Kubernetes operations on one side, cross-team coordination on the other
• Efficiency Measuring and improving how effectively every major workload uses the hardware it runs on. Instrumenting utilization across training, inference, and eval systems, building benchmarking infrastructure, establishing per-config baselines, and working directly with system-owning teams to close the gaps. The metric has to be good enough that the team on the hook for it agrees with the number
• Attribution and forecasting Connecting what the fleet costs to what the business is doing with it. Reconciling CSP billing exports against vendor telemetry and internal systems with mismatched schemas, attributing spend to the workloads and teams that generate it, and turning inference demand signals and research roadmaps into a defensible compute plan. Efficiency metrics have to survive contact with finance: stripped of pure demand and unit-price effects, reproducible month over month, and legible to a CFO
• Build the planning and allocation stack — the tools leadership uses to allocate capacity, teams use to plan against their allocations, and the scheduler enforces. Cross-region and cross-provider placement, guardrails, queueing, occupancy KPIs
• Drive the efficiency programs: stranding and rightsizing, unused capacity recovery, and job-level utilization across training, inference, and eval. Establish per-config baselines and work with system-owning teams to close the gaps. Utilization improvements are worth enormous sums at our scale
• Own attribution and forecasting — reconcile billing across ten-plus providers against telemetry and internal systems, attribute spend to the workloads that generate it, and turn demand signals and research roadmaps into a defensible compute plan and supply pipeline
• Build the data platform underneath all of it: pipelines ingesting occupancy, utilization, and cost from a rapidly diversifying fleet into BigQuery, with real ownership of completeness, latency SLOs, and gap detection. Every new provider is a net-new integration
• Operate Kubernetes-native systems at scale — collection agents, workload labeling, and the taint/reservation/scheduling behavior that determines what capacity is actually usable
• Treat the output as a product, not a pipeline. Gather your own requirements, define schema contracts, and design for consumers ranging from research engineers to a CFO — including on-call and SLOs, because these surfaces are load-bearing for the company