Competency Benchmarking: What to Highlight on Your Resume

One-line pitch: this page translates "RL skills" into resume language — how an RL resume differs from a general ML resume, the four elements of environment–algorithm–metrics–reproducibility, a STAR template for project descriptions, before/after rewrites, and ten common mistakes.

Most RL resumes get filtered out not because the candidate lacks ability, but because the resume presents no evidence. A general ML resume says "improved accuracy by 3%," and the interviewer gets it instantly. An RL resume says "significantly improved results," and the interviewer can only extract three signals: which algorithm you used, which library you tuned, and that you never evaluated anything. Starting from your self-assessment in the Knowledge Map, this page teaches you how to turn "I know it" into "you can believe me."

1. How an RL Resume Differs from a General ML Resume

Dimension	General ML Resume	RL Resume	Why the Difference
Core metrics	Accuracy / recall / F1 / AUC	Mean return, success rate, sample efficiency, the distribution across seeds	RL metrics have huge variance — a single number isn't credible
Method names	A model name suffices (ResNet, XGBoost)	An algorithm name isn't enough — you need "why this one" (on/off-policy, discrete/continuous actions)	There's no silver bullet in RL; algorithm choice is the skill
Reproducibility	Rarely mentioned	Must be mentioned (seeds, configs, code link, experiment management)	RL is extremely seed-sensitive — no reproducibility, no credibility
Evaluation	Train/test split	Multiple seeds + learning curves + baselines + generalization	RL has no fixed "test set"
View of success	Good metric = success	Good metric and trustworthy evaluation = success	Evaluation cheating is rampant in RL

Bottom line

A general ML resume proves "I made the metric better." An RL resume has to prove "I know how to make the metric better, and the improvement is trustworthy." That trust comes from the four elements — the subject of the next section.

2. The Four Elements: Environment · Algorithm · Metrics · Reproducibility

Of everything that goes into an RL project description, interviewers only want four pieces of information. The rest is noise.

Element 1: Environment — what task you worked on

State "environment + task + action/state space" in one sentence, but be specific down to the version:

✗ "Trained a MuJoCo robot"
✓ "Trained a policy on MuJoCo HalfCheetah-v3 (continuous action space, 17-dimensional state)"

Why the version? MuJoCo's default parameters changed with the Gymnasium upgrade, and reward scales differ across versions — skip the version and your numbers can't be compared. How you state the environment reflects your grasp of evaluation and benchmarks.

Element 2: Algorithm — what method, and why

Algorithm name + a one-sentence rationale for choosing it. The rationale proves more than the name:

✗ "Trained with PPO"
✓ "Trained with PPO (clip=0.2, GAE λ=0.95) — for continuous actions under a sample-efficiency constraint, PPO is more stable than SAC and a better fit for continuous control than DQN"

If you can't write the rationale, you haven't really understood the algorithm — and that gap will surface the moment comparison questions come up in the interview question bank.

Element 3: Metrics — make the result measurable

RL results follow a fixed formula: mean ± std across multiple seeds + a baseline comparison + sample efficiency:

✗ "Significantly improved results"
✓ "Mean return 9800 ± 320 across 5 seeds (SB3 PPO default baseline: 9700), reached within 1M steps — 2× the baseline's sample efficiency"

The full conventions for metric details — fixed seed matrices, multiple runs, median/IQR, learning curves — live in evaluation in practice.

Picking one headline metric: how?

Task Shape	Headline Metric	Why
Clear success criterion (end-to-end delivery, keeping a pendulum upright, clearing a game level)	Success rate	It's the number the business cares about most — and it's intuitive
No clear success line (continuous control, dense reward)	Mean return ± variance	Captures overall level and stability
Cost-conscious (limited training budget / interaction count)	Sample efficiency (steps to reach a given score)	Deployment scenarios care most about data cost

The most common metrics mistake on RL resumes is reporting only the final return, never sample efficiency — yet hiring teams almost always want to know "how much interaction did it take you to reach this level?" Sample efficiency maps to the two-axis view (sample efficiency × final performance) in evaluation and benchmarks.

Element 4: Reproducibility — can someone else rerun your result

One line plus one link:

"Full config (Hydra), seed list, learning curves, and code at the GitHub repo link (README includes reproduction commands)"

All four are mandatory

The two most often omitted elements are metrics and reproducibility — which happen to be the two RL interviewers care about most. Together they send one signal: your results can withstand scrutiny. And since the RL community has been burned by too many "irreproducible papers," interviewers are instinctively suspicious of results that can't be reproduced.

3. The STAR Project Description Template

Structure each project description with the four-part STAR format, adapted for RL — merge S/T into "environment and goal," align A with "algorithm and rationale," and R with "metrics and evaluation":

Part	Original Meaning	RL Adaptation	Example
S (Situation)	Background	Environment and task	"On Gymnasium CartPole-v1"
T (Task)	Goal	Learning objective and business goal	"Keep the pole balanced for 500+ steps, reproducible on new seeds"
A (Action)	Approach	Algorithm + engineering work	"Compared DQN vs PPO, added experience replay and a target network, tuned hyperparameters across 5 seeds"
R (Result)	Outcome	Metrics + evaluation + deliverables	"PPO averaged 495±8 steps over 500k training steps; code and configs open-sourced"

The final form of a complete project entry (about 3–4 lines — one bullet on your resume):

[RL Project] HalfCheetah continuous-control policy (2025.09-2025.11)
- Implemented and tuned PPO (clip=0.2, GAE λ=0.95) on MuJoCo HalfCheetah-v3, benchmarked against a SAC baseline
- Mean return 9800±320 across 5 seeds (baseline: 9700), converged within 1M steps, 2× sample-efficiency gain
- Built a 5×seed evaluation matrix with learning-curve monitoring; configs / code / repro commands all open-sourced (link)

One project = one story

Treat each project as a "story" you'll tell in the interview: environment → algorithm choice → metrics → reproducibility. Whatever direction the interviewer probes is dictated by the four elements on the page. Anything you don't write on the resume won't come up in the interview by default; anything you do write will be dug into by default — so only list projects whose four elements you can defend.

4. Rewrite Examples (Before / After)

Anti-example 1: algorithm name only, no metrics, no environment

Before:
"Used the PPO algorithm to train an agent in a MuJoCo environment and achieved excellent results."

After:
"Implemented and tuned PPO (clip=0.2, GAE λ=0.95) on MuJoCo HalfCheetah-v3 (continuous control, 17-dimensional state):
mean return 9800±320 across 5 seeds, converged within 1M steps; compared against a SAC baseline — final performance on par,
training noticeably more stable (return variance −38%); full configs and learning curves on GitHub (link, includes repro commands)."

What changed: the environment is pinned to a version, key hyperparameters are added to the algorithm, the metrics are given as mean ± std with a baseline comparison, "excellent results" is replaced by verifiable numbers, and "open-sourced" is backed by reproducibility.

Anti-example 2: ten algorithm names dumped, none explained

Before:
"Familiar with DQN, PPO, SAC, TD3, DDPG, A2C, A3C, Rainbow, C51, HER…"

After (the only way this works on a resume):
"Algorithms: PPO / SAC / DQN (implemented and tuned — see projects below); working knowledge of TD3, DDPG, Rainbow (reproduced paper baselines)"

What changed: ten names collapsed into "implemented + reproduced," and credibility actually doubles. Every algorithm name on a resume is an entry point for interviewer questions — write ten names and you've dug yourself ten holes.

Anti-example 3: papers read, but no hands-on evidence

Before:
"Read many RL papers and have a deep understanding of the field's frontier."

After:
"Reproduced InstructGPT's three-stage RLHF pipeline (SFT → RM → PPO) with alignment experiments on a 1B open-source model;
reward score correlated 0.87 with human evaluation; identified and mitigated reward over-optimization (KL divergence ran away beyond 3 rounds);
experiment logs at the link."

What changed: "read papers" is unverifiable; "reproduced a pipeline and hit real pitfalls" is verifiable. The general rule for RL resumes: replace every "understand / familiar with / read" with "implemented / reproduced / tuned / evaluated."

Anti-example 4: irreproducible miracle numbers

"PPO reached 10000 return on Humanoid. SOTA."

In the RL community this is career suicide: 10000 return on Humanoid — no seed count, no environment version — the interviewer's first reaction is "evaluation cheating." Better to write "5000±800, on par with the paper's baseline" than an unsupported SOTA claim.

Anti-example 5: a business project that lists only the algorithm, not the business value

Before:
"Used a context bandit to optimize the recommendation strategy; the A/B test showed a significant effect."

After:
"Deployed a contextual bandit (Thompson sampling) in the item-ranking layer of the recommender, replacing the legacy ε-greedy policy:
a 14-day online A/B test showed +1.8% click-through rate (p<0.01), exploration traffic cut from 10% to 5% (budget-constrained),
validated with offline replay before full rollout."

What changed: for business roles (recommendations, ads, risk control), interviewers don't care which bandit you used — they care about how much business lift you delivered and how you verified it. The last common gap in RL resumes is "right algorithm, no business closed loop": A/B test duration, effect size, statistical significance, and cost constraints — those four things are often more persuasive than the algorithm name.

5. Top 10 Common Mistakes

#	Mistake	Why It's Fatal	The Fix
1	Dumping algorithm names	Every name is an opening for follow-ups you can't handle	Only list ones you've implemented or reproduced — five max
2	No evaluation protocol	"Good results" isn't credible	Mean ± std over multiple seeds + a baseline comparison
3	No environment version	Numbers can't be compared	State the environment and version (HalfCheetah-v3, etc.)
4	Writing "understand / familiar with / read"	Unverifiable	Replace with "implemented / reproduced / tuned / evaluated"
5	No code/config link	Can't be reproduced	Public repo + reproduction commands
6	Boasting SOTA	Interviewers immediately suspect evaluation cheating	"On par with the paper's baseline" is persuasive enough
7	Project lists the algorithm without the "why"	Looks like you only know how to tune libraries	Add a rationale (on/off-policy, action space)
8	No learning curves / visualizations	Interviewers want trends, not single points	Attach learning-curve screenshots or link to curves in the repo
9	No seed information	Single-seed results aren't credible	State the seed count (3 or more)
10	Projects misaligned with the target role	The interviewer can't see the fit	Reorder projects for the target role per the Knowledge Map

Tailoring by role: the same experience, three different framings

The same "tuned PPO on HalfCheetah" experience should be framed completely differently for three types of roles:

Target Role	How to Title the Project	Emphasize	De-emphasize
Algorithm researcher (research track)	"Sensitivity analysis of PPO's entropy coefficient"	Ablations, mechanistic understanding, method comparisons	Engineering details
RL algorithm engineer (applied track)	"HalfCheetah policy: deployment and tuning"	Multi-seed evaluation, sample efficiency, reproducible engineering	Math derivations
Simulation / platform engineer	"Parallelizing the RL training pipeline"	Environment parallelization, data pipelines, performance numbers	Algorithm details

Core principle: a resume isn't a list of everything you've done — it's "evidence organized for a specific target role." Use a different version for each role you apply to (same facts, different emphasis). This is the direct application of "identify the role archetype first" from the module guide & job landscape.

Skills section and extras: the other two blocks on the resume

The four elements only cover the projects block. RL resumes typically also carry a skills block and an extras block, and both are frequent trouble spots.

Skills block: organize into four groups — theory / algorithms / engineering / business (aligned with the self-assessment quadrants in the Knowledge Map), 3–6 items per group, and include only things you can defend under follow-up questioning:

Algorithms: PPO, SAC, DQN (implemented and tuned); TD3, DPO (reproduced baselines)
Theory: MDPs and Bellman equations, policy gradients and GAE, the three-stage RLHF pipeline
Engineering: PyTorch, Gymnasium/MuJoCo, distributed sampling, W&B experiment management

Three frequent mistakes in the skills block: (1) listing everything in one undifferentiated blob, so the interviewer can't quickly locate your ability profile; (2) writing "proficient / expert" without evidence — every word in the skills block should be corroborated by a project; (3) piling up framework names (Redis/Kafka) with no algorithm names — for RL roles, the skills block should star algorithms and theory, with generic middleware in a supporting role.

Extras block (optional — when in doubt, leave it out):

Content	Only Include	Avoid
Papers / reproductions	Papers you actually reproduced and understand mechanistically — 1 to 3	A long list of titles you never read
Open-source projects	Portfolio repos whose READMEs pass muster (all four elements present)	Half-finished, README-less code
Competitions	Results that demonstrate hands-on RL ability	Generic competitions unrelated to RL

One page vs. two

RL resumes (research roles especially) can run to two pages, but page two must be more worth reading than page one — reproduction details, evaluation tables, full project case studies — not overflow crammed in because page one ran out of room. Campus recruiting in China generally prefers one page; two pages are acceptable for experienced-hire research roles. The principle: every line must pass the test "would an interviewer follow up on this?" — a line you can't defend in follow-up is a line that costs you points.

6. Connecting to the Portfolio

A resume is a summary of the evidence; portfolio projects are the evidence in full. The division of labor:

Medium	Length	Content
Resume	3–4 lines per project	Four-element summary + link
Portfolio (GitHub README)	1–2 pages per project	The full text of the four elements — environment, algorithm, evaluation, reproducibility — plus learning curves, repro commands, and pitfall notes

Every four-element line on the resume must have full support in the portfolio. There's a ~90% chance the interviewer clicks through to your GitHub after reading the resume — a README containing the complete four elements (environment–algorithm–metrics–reproducibility) is the portfolio standard. The resume's job is to make the interviewer want to click; the portfolio's job is to make the clicker convinced.

Final resume checklist

1. Does every project have all four elements? (environment / algorithm / metrics / reproducibility)
2. Any algorithm-name dumps, or any "familiar with / understand"?
3. Do the metrics state the seed count and a baseline comparison?
4. Does every link open? (A dead link = negative points)
5. Does the project order match the target role in the Knowledge Map?
6. After 30 seconds, can the interviewer say what this person is strong at?

Further Reading

• Portfolio Projects — the full evidentiary form of the resume's four elements: how to write the README, and pitfalls to avoid.
• Knowledge Map — the basis for which skills to highlight: reverse-engineer them from the target job description.
• Build Your Own RL Evaluation — the concrete recipe for the "5×seed evaluation matrix" on your resume.
• Module Guide & Job Landscape — back to role positioning; confirm the direction your resume should emphasize.
• Interview Question Bank — every word on your resume can turn into an interview follow-up.

References

• OpenAI Spinning Up in Deep RL — a reference for algorithm selection and implementation: https://spinningup.openai.com
• Gymnasium official documentation (environment versions and API): https://gymnasium.farama.org
• Stable-Baselines3 (common RL baseline implementations): https://github.com/DLR-RM/stable-baselines3
• Hugging Face Deep RL Course (course and example projects): https://huggingface.co/learn/deep-rl-course