Role Description
One of the engineers on the live request path of an ad-serving bridge between a supply-side platform and a Japanese broadcaster’s programmatic linear exchange. The path runs from the incoming ad opportunity through deal matching and pacing, creative and restriction filtering, selection, and the response the broadcaster receives. The client has settled on C++ for this path and treats the choice as closed.
Their reason for C++ is reuse rather than raw speed. The client is modularising its existing C++ ad server so components can be linked into this new application instead of called across a service boundary; their example was an audience and segment library, and their stated aim is that everything is bundled together and the latencies are very strict. So the engineer in this seat writes new code and consumes a library estate they did not write, inside a build system belonging to someone else. That modularisation work sits on the client’s side and carries no data, which makes it a dependency rather than a given.
The request timing comes from the broadcaster. Slots with a fixed broadcast time receive the request about a minute before air; untimed slots receive it one to three seconds before air. A single slot can produce three or more sequential sub-requests, with the request for the next segment issued while the previous commercial is still playing, so break-level state has to survive that chain. The client describes the work as high-throughput system design. The specification discloses neither a target request volume nor the response timeout, so treat the throughput requirement as stated by the client and unquantified in the documentation.
Full-time from the first milestone through production handover. Reports to our solution architect, who owns the internal model and the interface contracts, and works alongside a Go engineer on the settlement side.
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, settled by the client, with Go on the settlement and reconciliation side. The system deploys into the client’s own 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.
Key Responsibilities
Request path
- Build the ad request handler and the break-level state that survives a split playlist, where the request for the next segment goes out while the previous commercial is still on air.
- Build deal matching and the pacing engine against a budget ceiling and an audience figure that does not settle until the following business day.
- Build creative and restriction filtering: time-band, slot-allocation, position and adjacency rules over an ordered commercial break.
- Build selection and the response builder in the broadcaster’s format, including the preferred position within the break. First-price evaluation is the client’s current expectation rather than a fixed decision.
- Auction engine (first-price)
Integration with the client’s existing platform
- Link and consume components from the client’s existing C++ ad server as their modularisation makes them available, rather than calling them across a service boundary.
- Keep the internal request and response model aligned to oRTB, a decision the client has already taken, so the optional second phase stays an edge-mapping job.
- Build cloud-ready for a system that deploys into data centres the team does not operate.
Correctness under a broadcast deadline
- Treat the airtime window as the deadline it is. A late response means a commercial slot the platform did not fill.
- Filter conservatively against restriction rules the exchange revalidates on its own side, excluding any creative that fails. A wrong rule costs delivery.
- Hold state across the sub-request chain within a single slot, where one decision runs while the previous advertisement plays.
Required Qualifications
Experience
- 6+ years of production C++, including at least one service that ran under a latency budget someone else set.
- Has worked inside a large C++ codebase written by other people, its build system included, and has linked against internal libraries rather than only writing standalone services.
- Has built or maintained a component on the live path of an ad server, an exchange, or a bidder.
- Has implemented against a protocol specification owned by another organisation, where the contract could not be changed.
Technical Acumen
- Modern C++ with ownership, lifetime, and concurrency handled deliberately rather than by habit.
- Build systems and dependency management for a large native codebase, including linking against internal libraries supplied by another team.
- Latency-sensitive service design: timeouts, deadline propagation, backpressure, and what the service does when the deadline arrives first.
- Stateful request handling across a sequence of related calls, rather than stateless request and response.
- OpenRTB object semantics, enough to keep an internal model aligned to them without shipping a conversion layer.
- Constraint evaluation over an ordered sequence: adjacency, position, and competitive-separation rules.
- Building for an environment the team deploys into but does not operate.
Judgement & Soft Capabilities
- Reads the specification before writing against it, and asks when it is ambiguous instead of picking an interpretation quietly.
- Understands that a filtering rule which is wrong loses delivery without raising an error, so treats restriction logic as a correctness problem.
- Works to an architect’s model, and pushes back in writing when it does not survive contact with the code.
- Comfortable being blocked by another organisation’s timeline, and says so early with a named owner and a date.
Domain Knowledge — required
This seat needs adtech domain knowledge, for a specific reason. The request path decides which advertisement runs in a commercial break on national television, under rules a broadcaster sets and revalidates downstream. An engineer strong in C++ and empty on the domain will write correct code against a wrong reading of the specification, and nothing will look broken. The particulars of this broadcaster are learnable in weeks. The reasoning underneath is not.
Required and portable across adtech platforms:
- Programmatic auction mechanics from the sell side: what an ad opportunity, a bid, a win, and a delivered impression each are, and why a won bid is not a delivered impression.
- OpenRTB request and response object semantics, and the conventions around extensions.
- Ad pod and commercial break composition: duration constraints, position within a break, and competitive separation between advertisers.
- Pacing: spending a budget evenly against inventory whose available volume varies.
- Creative eligibility and restriction rules as a filtering problem that runs before the auction.
Specific to this engagement, and expected to be ramped rather than pre-held:
- The broadcaster’s exchange dialect and its restriction taxonomy.
Depth in ad serving, exchange, or bidder engineering is expected. A candidate strong in C++ and empty on the domain is the slower and riskier hire here.
Nice to Have
- CTV ad podding, or linear traffic and scheduling systems where competitive separation is enforced rather than advisory.
- Pacing or budget-delivery engines running against inventory of varying volume.
- Go, since the settlement side is written in it and the boundary between the two is not settled.
- Prior work against technical documentation in translation.
- Having built a system later absorbed into a larger platform’s library estate.