Make model progress measurable

Post-training and evaluation research sits between experimental design and model behaviour. Depending on the team it covers preference data, reward models, reasoning benchmarks, and the analysis that separates a real capability change from a measurement artefact.

What these postings actually ask for

Counted from 219 of the 233 open post-training & rl roles on this board whose description this board can read, on 2026-11-10. Every figure below is a count of employers' own words. Where a requirement is not stated, that is reported as not stated rather than assumed.

Named tools. python in 127, pytorch in 105, jax in 50, kubernetes in 26, tensorflow in 25, rust in 19, vllm in 15, spark in 14. Counted where the description names them, which understates any tool a team uses without writing it down.
Doctorate. 130 of 219 (59%) never raise one. 89 of 219 (41%) mention one, and how many of those require it is not reported here: telling a requirement from an alternative or a description of the team is a reading this board does not yet do reliably, and the page on it explains why the count was withdrawn.
Years of experience. 31 postings state a number; the median is 4, running from 1 to 10. The other 188 state none.
On call. 5 of 219 (2%) mention an on-call rotation.
Published pay. 144 of 233 open post-training & rl roles advertise a comparable annual USD base band; the rest publish nothing or publish something that is not base pay.
Remote. 31 of 233 say remote in the listing. Geography restrictions usually sit in the posting itself.

See the 233 open post-training & rl roles →

Suggested by this board, not by an employer

Nothing in this section was asked for by anyone hiring. It is one editor's suggestion for demonstrating the work above, and no posting on this board requires it.

A project

Test whether a benchmark measures what you think it does.

Take a small public benchmark. Vary prompt wording or task format, measure how much the score moves, and inspect the failures rather than the average. Report uncertainty and possible contamination instead of concluding that one model is better.

Deliverable: Share the project, your decision criteria, and a short record of what you changed after feedback.

Self-check: Can someone else reproduce your result? Are assumptions and failure cases clear? What evidence would change your conclusion?