Crusoe is on a mission to accelerate the abundance of energy and intelligence. As the only vertically integrated AI infrastructure company built from the ground up, we own and operate each layer of the stack — from electrons to tokens — to power the world's most ambitious AI workloads. When you join Crusoe, you join a team that is building the future, faster.

We're in the midst of the greatest industrial revolution of our time. The demand for AI compute is boundless, and power is a bottleneck. We're solving that — with an energy-first approach that makes AI infrastructure better for the world and faster for the people innovating with AI.

We're looking for problem-solving, opportunity-finding teammates with a sense of urgency, who believe in the scale of our ambition and thrive on a path not fully paved — people who want to grow their careers alongside a team of experts across energy, manufacturing, data center construction, and cloud services.

If you want to do the most meaningful work of your career, help our customers and partners advance their AI strategies, and be part of a high-performing team that believes in each other, come build with us at Crusoe.

About the Role

The Client Interfaces team owns every surface customers and internal users touch when they use Crusoe Cloud: the Console and Admin Console, customer and admin CLIs, MCP servers, the Terraform provider, our docs, and the Intelligence Foundry / AI Studio. We're the glue between product, design, and the platform teams that power Crusoe Cloud.

In 2026 our focus is one experience, one quality bar across every surface; a shared design system, a single API/CLI style guide extended to MCP and Terraform, and a foundation solid enough to support the polish, defaults, and micro-interactions that make a developer cloud feel great to use.

You'd be the first dedicated quality engineer on the team, and the person who defines what "one quality bar" means in practice.

What You'll Be Working On

Test Strategy Ownership: Own end-to-end test strategy across the Console, CLIs, Terraform provider and MCP servers. This includes Playwright E2E suites, Go-based integration and acceptance tests (with real plan/apply/destroy lifecycles through terraform-plugin-testing), and contract tests against generated API clients.

Framework Development: Build automation frameworks from scratch and keep them reliable through parallel execution, flakiness reduction and GitHub Actions CI integration, so a red build always means a real bug.

Cross-Surface Consistency: Verify that features shipping to Console, CLI, Terraform and MCP at the same time behave like one product, and build harnesses that catch drift automatically.

Release Readiness: Define quality gates and release criteria with engineering and product, balancing shipping speed against reliability.

AI-First Testing: Use agents to generate test suites from OpenAPI specs and tickets, review AI-generated tests to make sure the assertions are meaningful, and use AI triage to separate real failures from flakes.

Exploratory Testing: Cover what automation can’t, including micro-interactions, empty states, error copy, accessibility, upgrade paths and docs that don’t match the product.

Complex Problem Solving: Tackle issues that span every surface, such as breaking-change management in the Terraform provider, API contract changes that ripple through generated clients, and design system migrations.

Coaching and Collaboration: Help software engineers get better at test design through code review and pairing, and work directly with design, product and platform teams.

Measurable Quality: Turn “this should feel great to use” into concrete, testable criteria the team can build against.

What You'll Bring to the Team

Quality Engineering Experience: 5+ years in quality engineering, test automation or SDET roles on customer-facing products.

Framework Building: You’ve built, or helped build, a TypeScript automation framework from scratch and run it in CI. You can talk specifics about parallelization, retries, network interception, flakiness and what you’d do differently next time.