> Markdown version of [/jobs/ext/4710487-research-engineer-rl-environments-synthetic-data-all-genders](https://www.wearedevelopers.com/jobs/ext/4710487-research-engineer-rl-environments-synthetic-data-all-genders). 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).

---

# Research Engineer, RL Environments & Synthetic Data (all genders)

- **Company:** ellamind
- **Location:** Bremen, Germany
- **Contract:** Permanent contract
- **Skills:** Spreadsheets, Software Debugging, Python (Programming Language), Open Source Technology, Graphics Processing Unit (GPU), Kubernetes, Free and Open-Source Software, Docker
- **Published:** November 14, 2026
- **Apply:** https://www.adzuna.de/details/5963509702

## About the Role

* Your Python is solid and your engineering habits are real. Containers, sandboxes and async code don't worry you. Bugs that only show up at scale annoy you, in a motivating way.
 * You read the data. Actual samples, actual trajectories. And you come back with opinions about what's wrong with them.
 * You have a feel for what makes a task worth training on: it's realistic, you can verify it, and it's hard to game.
 * You write clearly enough that the rest of us can trust a result without re-running it.
 * You live in the EU and are allowed to work here. English is all you need; German is a bonus.

Things that would make us happy but that nobody needs to have: RL experience (GRPO- or PPO-style training, reward design); real knowledge of a field where agents do actual work, like law, finance, insurance or public administration; sandboxing infrastructure (Docker, Firecracker, Kubernetes); open-source contributions. German is handy in this role, because a lot of our tasks start life as German-language processes.

Why us?

What you build gets trained on almost immediately, and you'll see what it did. GPUs are only as useful as the tasks we spend them on, so in practice your work sets the ceiling for the next model. A good share of it goes public too, the way our Terminal-Bench 4.0 tasks did. And we're small: if you have a good idea on Tuesday, nobody makes you write a proposal about it.

## Description

A model only gets good at work it has practiced. Ours practice on thousands of made-up tasks: a caseworker's queue that needs triaging, a spreadsheet that refuses to reconcile, a policy that has to be applied to a document nobody formatted properly, a broken repo in a sandbox.
Somebody has to build those worlds, and then find an honest way to tell whether the model did the job or only looked like it did. We'd like that to be you.
In plenty of places, environment work is treated as plumbing for the "real" researchers. We see it the other way round. Most of what our models can do, they learned from their tasks. So you'd work directly with the people running training, you'd see what your tasks did to the model one run later, and you'd have a say in what the next one learns.

What you'll work on

 * Environments for long, multi-step work with tools, documents and code. The raw material is what European companies and public offices do all day, which gets a lot more interesting once a model has to do it.
 * Generators that turn one good task idea into thousands, hard ones included. You'll want a difficulty dial, and a way to be sure the set isn't quietly full of duplicates or leaked answers.
 * The checks that decide whether the work got done: tests, state checks, rubric-based judges. Whatever tells the truth.
 * Catching the model cheating. You read rollouts, spot the shortcut it found (it will find one), close it, and build QA so the next environment is harder to fool.
 * Measuring what a task set really did to the model, and saying out loud which ones to scale and which to drop.
 * Helping decide what we publish. Environments, datasets and benchmarks are part of our releases, starting with the first open-source one in Q1 2027.