DevOps Engineer
Role Description
The engineer who owns everything the delivery team needs in order to build, test, and ship, up to the point where the system enters the client’s own environments.
The client has drawn that line in writing: they own infrastructure setup in their data centres for UAT and production, and during the development phase, before UAT, we address it on our end.
So the scope is bounded, and inside its bounds it is the whole job. Development and test environments, continuous integration for a mixed C++ and Go codebase, build and dependency management, artefact production, and the observability the team needs while building. It ends at a handover across an organisational boundary, into data centres this role never operates.
The client will allocate one infrastructure person to work with the team, and their stated intent is that this person understands the architecture upfront rather than meeting it at UAT. Making that collaboration work early is part of the job. A late handover blocks the path to production, and there is a November readiness date behind it.
Full-time, with the load heaviest at the start while the pipeline and environments are established.
About the Project
Client: an established supply-side platform operating at scale. The engagement is a fully outsourced build. The client supplies a product manager for requirements and scope, an architect in review and supervision mode, and an infrastructure specialist for the UAT and production environments. We own delivery, the architecture, and everything before UAT.
Product: an ad-serving bridge connecting the client to a Japanese broadcaster’s programmatic linear platform, built apart from the client’s core RTB stack. It works as a translation layer and as a lightweight supply-side platform running the auction. Three parties define its edges:
- The broadcaster’s exchange is the source of ad opportunities, reached through a connection specification the broadcaster defines and we implement against, with no leverage to change it.
- An external viewing-rating system decides how many people saw each commercial. We never call it. The exchange derives impression counts from those ratings and reports them back twice: preliminary shortly after air, confirmed the following business day.
- The client’s configuration surface supplies demand as activated direct deals. An optional second phase adds third-party demand-side platforms over oRTB.
Phasing: a mandatory first phase runs entirely in the broadcaster’s native protocol and needs no protocol conversion. An optional second phase adds oRTB conversion and direct communication with demand-side platforms. The internal model is oRTB-aligned from the first phase, so the second becomes an edge-mapping job.
Position today: greenfield. Nothing is built. The broadcaster’s connection specification exists and is versioned, though its revision history shows continued amendment. The requirements document does not exist yet.
Stack: C++ on the request path, Go on the settlement side. The system deploys into the client’s private data centres and must be built cloud-ready, in the client’s words, so that moving it to the cloud later is not a separate project. Repository layout, continuous integration tooling, observability stack, and environment topology have not been discussed with the client and are open for this seat to establish.
Key Responsibilities
Build and continuous integration
- Establish the build for a mixed C++ and Go codebase, including dependency management and linking against libraries the client’s existing platform supplies.
- Build the pipeline: compilation, test execution, artefact production and versioning, with reproducible results.
- Keep build times short enough that the request-path engineers are not waiting on them.
Environments before UAT
- Provide and maintain development and test environments for the whole team, since the client owns nothing before UAT.
- Provide the infrastructure that test automation runs on, once the shape of that automation is agreed. Test tooling was never discussed with the client and falls to us by default.
- Make the system reproducible and deployable so that the handover into the client’s environments is a configuration exercise rather than a discovery exercise.
Packaging & Observability
- Package and document the deployment so the client’s infrastructure specialist can stand up UAT and production from it.
- Establish observability during development that survives into the client’s operating environment rather than being rebuilt there.
- Handle credentials across an organisational boundary. The exchange interface uses separate API keys in each direction, issued by different parties.
Working across the boundary
- Engage the client’s infrastructure specialist from the start, which is what they have asked for, rather than at handover.
- Track the UAT and production handover as a dated dependency and raise it the moment it slips.
- Get repository layout, pipeline tooling, observability, and environment topology agreed with the client, since none of it has been discussed.
Required Qualifications
Experience
- 5+ years in build, release, and infrastructure engineering, with at least one project taken from nothing to a working pipeline.
- Has owned continuous integration for a compiled-language codebase, C++ specifically or a close equivalent, where build time and dependency management were real problems rather than afterthoughts.
- Has delivered a system into infrastructure another organisation operates, and has run that handover rather than watching it.
- Has worked against an on-premises or private-cloud target, not only a public-cloud account they controlled end to end.
Technical Acumen
- Continuous integration for C++ and Go: toolchains, build caching, reproducible builds, artefact versioning.
- Containerisation and orchestration, with judgement about what a private data centre will actually accept.
- Infrastructure as code and configuration management, applied to environments that outlive the person who made them.
- Observability wired in during development: metrics, logs and traces as a build-time concern rather than a production retrofit.
- Secrets and credential handling where keys are issued by two organisations and rotate on their schedule, not ours.
- Environment parity, and the failure modes when development and target diverge.
- Cloud-agnostic
Judgement & Soft Capabilities
- Bounds their own scope. This seat ends at UAT and the client owns what lies past it. Someone who cannot hold that line either does the client’s work unpaid or leaves a gap nobody covers.
- Builds for handover from the first week, because the person who runs this system in production works for someone else.
- Treats a counterpart at another company as a colleague rather than a ticket queue, and gets what they need by asking early.
- Raises a dependency risk with a named owner and a date.
- Writes things down. The client has no documented expectations for tooling, so whatever this seat decides becomes the standard by default.