LiveOps Platform Engineer
LiveOps Platform Engineer
Remote | Part-Time (25 hours/week) | Mobile Games Publisher
Summary
- You love automation. You look at work a person does by hand — on a schedule, from memory, one row at a time — and you see a pipeline that should run itself and prove it ran correctly. What is left for your team is no longer busy work but Analysis: what to test, what the analytics say, what is actionable .
- You love games. You have worked in this industry and you play. This is not the place to learn what a battle pass is or why an event calendar matters. That said , you will not be building games, nor writing features core mechanics . The satisfaction from this role is improved efficiency of product teams.
- You work with AI the way an engineer does. Agents write most of the syntax now: knowing what to ask for, catching where the output is confidently wrong, and building the harness that lets one person cover ground that used to take a team.
What you'll do
- Reverse engineer configuration and content pipelines. Using AI, learn how developers modify game configuration and the live event schedule and how that data reaches players on the client — the authoring path, the publish pipeline, the artifacts, the CDN. Make it programmatic, and then validate and version-control instead of manual and undocumented.
- Scheduling and automation. Generate what is currently typed. Event calendars, offer rotations and config publishes expressed as rules and validators rather than hand entry — plus the jobs that run unattended and tell you when they didn't.
- Data and experimentation infrastructure. Get game telemetry into the warehouse and keep it trustworthy. Make cohorts, experiments and KPIs answerable with a query rather than an argument.
- Release and build systems. Takeover and or re-engineer build pipelines, signing, content delivery, platform and store compliance. The part of a live game that automation never removes.
- Observability for live operations. Alarms on the things that actually break a live game: content running dry, config not reaching players, a cohort silently misconfigured, a job that stopped succeeding three weeks ago.
- AI as the primary lever. Multi-agent tooling, agentic code archaeology, agent-assisted pipelines. One engineer covering this surface is only possible because of it, and we expect you to be well past "I sometimes use autocomplete."
What you need to have
Engineering core
- Two to five years in backend or platform engineering. You have written code, not Jira tickets.
- Deep in at least one language — we genuinely do not care which. Python, JavaScript or TypeScript, C#, Kotlin, Go, Java. What matters is that you know one well: where its type system lies to you, which of its idioms are traps, how it fails in production. Agents write syntax now; the scarce skill is the judgement to tell correct output from plausible output.
- You can actually build. You read a compiler or runtime error and know what it is telling you. You know what a linter is for and why most of its complaints are worth hearing. You could write a non-trivial program from a blank file without an agent — you just usually won't.
- You read unfamiliar code fluently in languages you don't write. Almost everything you inherit will be someone else's, in something you did not choose.
- Relational databases to a real depth — PostgreSQL or MySQL. Schema evolution, migrations, and an ORM you have actually fought with.
- A document store — MongoDB, DynamoDB, Firestore or equivalent. Indexes, aggregation, and the judgement not to run an unindexed scan against a live production cluster.
- A caching layer — Redis, Memcached — as a first-class store, not an afterthought.
Infrastructure and delivery
- Docker and Kubernetes — read and reason about manifests and Helm charts, drive kubectl, tell what is self-hosted from what is a managed service.
- A major cloud, AWS or GCP. Object storage, CDN, IAM, secrets management, managed Kubernetes. Enough to be dangerous, and enough to know when not to be.
- CI/CD — TeamCity, Jenkins, GitHub Actions, GitLab CI, Buildkite; any of them, several preferred. Build agents, artifact stores, code signing, and what to do when the build machine is the documentation.
- Scheduled and orchestrated work — cron, Kubernetes CronJobs, Airflow, Dagster, Temporal. Idempotent incremental jobs with watermarks. You should be able to adapt what exists or know what the best way to integrate a new workflow is.
Data and experimentation
- You understand analytics systems and data lakes — BigQuery, Snowflake, Redshift, Databricks or equivalent. Warehouse modelling, partitioning, and what a query costs. We are skipping the analytics tools and going straight to the data. Knowing, at least at a high level, data warehousing is a must.
- Pipelines and event data — ELT and transformation (dbt, Airflow), streaming or batch ingestion, and the mobile/web analytics layer above it: AppsFlyer, Adjust, Amplitude, Firebase, GA4, Kafka.
- SQL to depth. Window functions and cohort queries are routine, not a stretch.
- Experimentation, mechanically and statistically. Assignment, stickiness, holdouts, sample ratio mismatch, stacked variants, and enough statistics to know when a result is not one. Feature-flag and experiment platforms — LaunchDarkly, Statsig, Optimizely, GrowthBook — are a plus.
- Comfortable deriving a rule from a year of historical data, and stating how confident you are in it.
Games
- You have shipped or operated a live free-to-play game and know what an event calendar, a battle pass, an offer window and a soft-currency economy are without a glossary.
- Unity or web/HTML5, mobile or browser. This is live-service free-to-play, not AAA. If your background is exclusively PC, console or Steam engine work, this is probably not a fit — and if it is exclusively Unity gameplay programming, see "not this role" below.
- Unity at read level — you can navigate a project of several thousand files, find where a config is fetched, and say whether a change needs a client build. You do not need to be a gameplay programmer.
AI
- You work with coding agents daily and have opinions about it.
- You have built something agent-driven, not just prompted one.
- You are not a prompt engineer. You review what the agent produced, catch where it is confidently wrong, and could have written it yourself. That is the whole difference.