Careers

Summary

CaML is hiring a Research Engineer to run our training experiments: synthetic document midtraining, RL post-training on top of it, and the evals that measure the compassion personas we care about. Our research scientists decide what to test, and you make it run well, reproducibly and without needing many questions answered. We want someone who has finetuned open-weight LLMs, can implement and debug an RL pipeline, and will tell us when a run or an eval is broken.

What CaML does

CaML is a small California-based AI safety nonprofit. We study how values get into models during training and whether they survive the training that comes after: how to instill a specific set of values through mid-training data and RL, how to measure whether it worked, and how to keep it from being trained back out.

So far we’ve built the TAC benchmark (NeurIPS 2026 AI4Good workshop), the Manager Coercion Bench, HarvestBench in UK AISI’s Inspect evals, and the leaderboard at compassionbench.com. Our current open question is whether values instilled in mid-training survive later RL, and when they don’t.

What you’ll do

• Run training experiments end to end as set by a research scientist. If they say “post-train this model on this data”, you’ll choose the hyperparameters, build or adapt the pipeline, and split the work into well-scoped tasks. Our researchers can describe a set of experiments and you run them well without needing to ask many questions.
• Midtraining runs on synthetic document corpora, and RL post-training on top of them (for example RLVR with GRPO on verifiable tasks), on open-weight models mostly around the 12B scale.
• Build synthetic corpus generation pipelines, including well-matched control conditions, at the scale and quality the experiments need.
• Run evaluations, mostly on UK AISI’s Inspect, and interpretability methods under a researcher’s guidance.
• Direct AI coding agents such as Claude Code and Codex for much of the implementation, and check their code quickly but carefully enough to catch bugs.
• Keep configurations reproducible, checkpoint runs, log thoroughly and track experiments cleanly, so that every result can be traced and rerun.
• Debug training instabilities and infrastructure failures.

You’d work day to day with our research scientists in a small team with no management layers.

How we work

We want to be told when we’re wrong, by the people who work here. That includes being wrong about things the EA and alignment communities mostly agree on. A lot of that agreement rests on a few influential but untested posts, and we’d rather find out than assume.

In practice this means reporting the negative result, saying “I don’t know” when that’s the truth, flagging when one of our own evals is broken even if it hurts a paper we’ve already published, and disagreeing with well-known people on the merits.

Requirements

We check these against the application before reading anything else.

• You’ve trained or finetuned (7B+) LLMs as part of research: a paper or preprint, a research programme (MATS, ASTRA, SPAR or similar), an academic lab, or an industry ML team, where the results were evaluated and written up.
• You’re comfortable with Unsloth, RunPod and the Hugging Face ecosystem.
• You can implement, run and debug an RLVR or GRPO pipeline, and you understand the algorithms well enough to notice when a run is quietly broken.
• You’re familiar with literature on RL post-training, synthetic document midtraining and self-fulfilling (mis)alignment.
• Reproducibility, versioning and thorough logging are things you do by default, not on request.
• You can work independently in a small remote team and write clearly about what you ran, what you found and what went wrong.

If your experience with LLM training is mainly tutorials or personal projects that weren’t evaluated, this role probably isn’t the right fit yet.

Things that help but aren’t required:

• Ideas about values training and how midtraining data persists through later training.
• Experience with Inspect, OLMo models, or open post-training frameworks such as TRL or verifiers.
• Basic interpretability skills.
• Public technical work: papers, preprints, open-source contributions or posts.
• Familiarity with EA and discussions on LessWrong and the Alignment Forum.

This role suits someone who wants to take an experiment plan and execute it well. If you’d rather set the research direction yourself, see our Senior Research Scientist role.

Applying

The initial application form takes about 15 minutes. The bulk of it is three short questions, which we look at before your CV.

1. Your training experience. The largest or most involved training run you’ve done yourself: model size, method (fine-tuning, RL, GRPO etc.), the tools you used, and how you evaluated whether it worked. Two or three sentences.
2. A hard debugging problem. The hardest bug or technical problem you’ve solved in ML work, ideally from a different project than your answer above. What was going on, and how did you track it down? Two or three sentences.
3. Something you built. A research output you contributed to (paper, preprint, write-up or research codebase), and which part was yours.

If you’re a good fit, we’ll aim to reach out within three weeks. The rest of the hiring process consists of:

• An initial cultural interview and technical screening (~30 minutes)
• Technical interview (~45 minutes)
• Paid test task (~3 hours)
• Offer

We aim to send offers in early December for a late December or January start.

Pay and terms

• $120,000 to $150,000 depending on experience
• Full-time
• Fully remote (overlap with California working hours for calls), with travel to the San Francisco Bay Area if needed
• Open to applicants in any country; no visa sponsorship needed

Apply now →