> Markdown version of [/jobs/ext/3520854-data-platform-engineer](https://www.wearedevelopers.com/jobs/ext/3520854-data-platform-engineer). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Data Platform Engineer

- **Company:** Comind
- **Location:** UK (Remote available)
- **Experience:** Expert
- **Contract:** Permanent contract
- **Skills:** Artificial Intelligence, Amazon Web Services, Cloud Computing, Data Security, Python (Programming Language), Signal Processing
- **Published:** October 1, 2026
- **Apply:** https://startup.jobs/senior-data-platform-engineer-comind-10243274

## About the Role

* Substantial software or platform engineering experience, a good deal of it building tooling for scientists, researchers or quants rather than for end customers
 * Deep Python, and pipeline or workflow systems where correctness and reproducibility mattered as much as throughput
 * Cloud compute and storage (AWS preferred), containerisation, infrastructure-as-code, cost-aware provisioning
 * Tooling you built that people chose to use. Adoption you earned rather than mandated is the strongest single signal for this role
 * The ability to sit with a scientist, understand the analysis well enough to abstract it correctly, and push back when the evaluation itself looks wrong
 * A record of raising the standard of the engineers around you without formal authority over them
 * Comfort defining a function rather than joining one, on a small team with a real deadline: shipping a usable road early and widening it, rather than designing the complete platform first

Nice to have:

 * Regulated environment experience (medical devices, diagnostics, pharma, aerospace), particularly IEC 62304 or software as a medical device
 * Time-series or signal processing workloads, physiological data, or scientific instrumentation
 * Experiment tracking, model registries or MLOps tooling, aimed at research reproducibility rather than production inference
 * Behaviour-driven testing or specification-by-example as an interface between research and engineering
 * Introducing agent-assisted workflows into a technical team's actual day-to-day practice
 * Having been the first platforms hire into a science organisation before

## Description

Problems, not specifications. How they get solved is yours to decide.

 * Reprocessing. Change one stage of the pipeline and you currently pay for a full re-run. Re-running a six-month-old analysis with new parameters should be routine and cheap.
 * Evaluation. Comparison and simulation harnesses are rebuilt bespoke every time. They should be something a scientist calls, not something a scientist commissions, including scientists who don't write code, and agents running analysis strands on their behalf.
 * Compute and data access. Reproducible environments, sensibly-sized cloud resource, and datasets you can find and trust without asking whoever made them.
 * Engineering standards. Testing, CI and repository structure across a codebase written largely by scientists. Knowing where to enforce and where to reduce friction instead matters more than the tooling does.
 * The research-to-software boundary. We already have a real interface contract with our software team, which is more than most research groups can say. It should become a gate a method passes, not an event that consumes weeks.
 * Regulatory evidence as a by-product. IEC 62304 traceability artefacts generated from CI rather than written alongside it.
 * Growing the capability. Mentoring junior developers in the team, and shaping this function as it grows.

AI is fundamental to our culture. It's not just a tool, but a core part of how we work, collaborate, and innovate. We expect all team members to embrace AI in their daily work and continuously find new ways to use it effectively.