OpenAI Compute Infrastructure Engineer Interview Questions & Process (2026)

The Compute Infrastructure team owns the full stack that gets a GPU from a rack to a running training or inference job: capacity planning and cluster lifecycle, bare-metal provisioning and automation, Kubernetes and scheduling, high-performance networking and storage, fleet health, and the workload profiling and benchmarking that inform capacity decisions. It's the layer every research and product team depends on but rarely sees directly.

Based on the pattern OpenAI uses across its engineering roles, expect roughly 5 stages: a recruiter screen (30 min), a technical phone screen covering coding and systems fundamentals (60 min), a distributed-systems/infrastructure design round (60 min), a deep-dive technical round on cluster or scheduling internals (60 min), and a values/mission-alignment conversation, sometimes folded into a final cross-functional loop. Confirm the exact sequence with your recruiter — infra-specific loops can substitute a live-troubleshooting or on-call scenario for one of the design rounds.

Strong distributed-systems fundamentals (consensus, failure modes, backpressure), hands-on experience with Kubernetes at scale (custom schedulers, admission control, resource quotas), bare-metal or hybrid-cloud provisioning and automation, and comfort reasoning about GPU cluster topology — NVLink/InfiniBand interconnects, network-aware scheduling, and storage throughput for checkpointing large models. Prior experience keeping a large fleet healthy under continuous load (not just designing it on a whiteboard) is highly valued.

Practice designing systems for the specific failure modes of ML infrastructure: multi-tenant GPU scheduling with fairness and preemption, checkpoint storage that survives node failure without losing a multi-week training run, and capacity allocation across competing training and inference workloads. Be ready to reason about trade-offs between utilization, latency, and blast radius, not just throughput.

Standout candidates combine deep systems fundamentals with direct experience operating infrastructure at scale — they can describe an incident they diagnosed under pressure, not just a system they'd design in theory. They show genuine interest in how infrastructure choices affect research velocity and model training reliability, and they can talk concretely about GPU utilization, networking, or scheduling trade-offs rather than generic cloud-infrastructure patterns.