Software Engineer, Conduit

• 5+ years building and operating production backend systems
• Systems breadth: you reason across several interacting systems at once — how they fail, where the seams belong, how they stay consistent
• Experience designing APIs and contracts that other teams depend on — versioning, backward compatibility, deprecation
• Comfort with asynchronous and event-driven systems: idempotency, retries, partial failure, eventual consistency
• Experience debugging complex issues across the stack — networking, performance, data integrity — and good instincts for where security boundaries belong
• Self-directed: comfortable with ambiguity, able to take a loosely-defined problem and drive it to done
• Able to become productive in an unfamiliar language quickly — our services are Go today
• Are drawn to questions like: how do we know what's actually running? How do we make a change safely when several systems have to agree? How do we let products evolve without the control plane needing to know?
• Would rather build the abstraction that makes the next ten integrations easy than hand-wire the eleventh
• Want to work somewhere that writes real design docs — arguing a position, naming the tradeoff, and disagreeing in writing before the code gets written
• Are excited about building robust, large-scale, always-on services
• Love building and iterating on new technologies in a fast-paced environment

Desirable

• Conduit's Control Plane team owns the coordination layer of the Conduit Platform: the services that provision, update, and retire everything customers run on us — rollups, RPC nodes, indexing, and whatever comes next — meter what those products consume, and give both customers and our own team a trustworthy picture of what is actually running
• The core of it is a control loop. We're building a lifecycle service that observes what's actually running and reconciles toward the desired state, rather than writing a status field and hoping it stays true. It treats each product as opaque: its shape and configuration come from schema read at runtime, so onboarding a new product type is a description, not a pull request
• If you've worked on Kubernetes controllers, provisioning APIs, deployment systems, or any platform where the hard part is keeping many systems consistent with one another, this will feel familiar. It's a web2 stack in service of web3 technology — we don't require blockchain experience, and people on the team picked up the domain here
• A small, senior team with a large charter. Control Plane is small and entirely senior — this layer is critical enough that everyone on it operates independently. The surface area — lifecycle, usage reporting, the customer-facing API, internal tooling — is wider than the team can build at once, which is why we spent this year defining what it owns and what it doesn't. The upside is unusual influence: your design decisions become the architecture rather than one input among many
• The mission is automation. Plenty of platform operations still have a human in the loop. Turning those into automated, self-serve paths is the work — and because the first users of what you build are inside the company, the feedback loop is measured in hours, not quarters
• A lot of this work is decoupling before extending. These systems grew organically and carry real coupling. We'd rather pay that down than keep building on top of it
• The team optimizes for correctness and reliability first. Performance matters, but this isn't a role about making one component marginally faster — it's about making sure a change in one system doesn't quietly break three others. Nearly everything here is an integration problem, so breadth of systems judgment counts for more than depth in any one specialty
• Lifecycle as a service. A single, well-defined interface for provisioning, updating, repairing, and retiring what customers run, backed by reconciliation against observed state rather than best-effort writes
• Schema-driven, product-agnostic design. Moving product-specific knowledge out of code and into contracts the service interprets at runtime, so products and the control plane can evolve independently
• Usage and consumption reporting. A product-agnostic path for metering what customers consume and reporting it to the systems that bill for it. We don't build the billing engine — but consumption data is money, and correctness here is unforgiving
• Internal tooling. Admin surfaces that let our own teams operate the platform through the control plane's abstractions. You'll own the services and interfaces behind them, partnering with our UI engineers on the surface itself
• Own the interfaces other teams build against — lifecycle operations, usage reporting, schema contracts — including how they version and migrate as they evolve
• Integrate systems that don't fit together on their own, including third-party billing and partner integrations
• Drive cross-functional coordination when the control plane is the shared point of integration
• Improve the tooling and process that keep the platform maintainable and reliable
• Participate in the team's oncall rotation, covering the control plane services you own rather than the customer data path
• A flavor of technologies in use:
• Languages: Go (primary), Python
• Services: gRPC / protobuf, GCP Pub/Sub, River (Postgres job queue), Watermill
• Data: Postgres, Redis, GCS
• Schema & config: CUE, YAML
• Runtime we integrate with: Kubernetes, ArgoCD, GCP
• While we value experience with these technologies, we're primarily looking for engineers with strong systems judgment and the ability to quickly pick up new tools and frameworks