Software Engineer, Product Velocity

About the Team The ChatGPT Velocity team owns the health of the end-to-end developer and deploy loop for ChatGPT-facing services. Our mission is to help ChatGPT engineers ship confidently with a fast, lightweight development cycle and a trusted path to production. ChatGPT development depends on a long chain: local environments, Bazel builds, CI, tests, merges, release candidates, deploys, synthetics, alerts, and production health. When any link is slow, flaky, or unclear, engineers lose hours, fixes reach users later, and on-call load rises. This team turns that cross-cutting drag into owned, measured, and durable improvements. About the Role We are hiring an experienced infrastructure engineer to make ChatGPT development dramatically faster and more reliable. You will work across local development, build systems, CI, deployment infrastructure, test ownership, and production safety signals to reduce the time and attention required to move a healthy change from development to production. This is not a narrow tooling role. The best person for this job will be comfortable diagnosing messy distributed systems, reading developer pain signals from Slack and metrics, building reliable automation, negotiating ownership across teams, and making tradeoffs between velocity and production safety. You should enjoy treating engineers as users and turning confusing workflow failures into clear, measured systems. In this role, you will: Reduce local development startup and iteration latency for ChatGPT engineers Improve Bazel and build performance for local machines, devboxes, and CI, including cache effectiveness, reproducibility, disk usage, remote cache behavior, and observability into invalidations. Improve CI reliability and merge throughput by reducing unrelated failures, tail latency, flaky or mis-owned tests, quarantine friction, and repeated manual reruns. Build agents that help PRs make forward progress: rebasing, conflict resolution, CI triage, safe reruns, owner routing, and clear identification of external blockers. Make deploy pipelines more self-healing, especially when transient alerts, known-bad clusters, recovered synthetics, stale RCs, or noisy gates should not require human babysitting. Improve deploy observability so engineers can quickly tell where a change is, what is blocking it, whether the signal is trustworthy, and who owns the next action. Establish lightweight metrics for before-and-after impact, such as commit-to-prod latency, deploy-window throughput, CI tail latency, local bootup time, failure rates, manual interventions, false-positive gates, and developer-reported pain. You might thrive in this role if you: Have strong experience with large-scale developer infrastructure, build systems, CI/CD, deployment systems, or production reliability. Can debug across local machines, devboxes, remote caches, monorepos, service dependencies, auth systems, and distributed deploy pipelines. Are comfortable with systems like Bazel, Buildkite, Kubernetes, Temporal, Python/TypeScript services, GitHub workflows, and large monorepo tooling, or can ramp quickly on equivalents. Think in product loops as much as systems loops: you care whether developers can understand and trust the workflow, not just whether a subsystem is technically healthy. Know how to replace repeated manual intervention with policy-backed automation while preserving production safety. Communicate well across teams and can turn ambiguous "this is slow/broken/flaky" reports into crisp owners, hypotheses, metrics, and shipped fixes. Prefer practical measurement over vibes, while still knowing that developer frustration is often the first signal of a real systems problem. Are energized by high-leverage work where a small improvement can save hundreds of engineering hours. Nice to have: Experience improving developer experience in a very large monorepo. Experience with remote execution, remote caching, hermetic builds, or cache reproducibility. Experience designin