What should a machine learning engineer put on a resume?

Model outcomes a nonprofit reviewer can quote back

Model metrics don't survive the trip to a nonprofit hiring panel. Outcomes do. Rewrite each deployed-model entry so the result names who got reached, served, or seen sooner — not the benchmark score that got it there. An ML lead may sit on the panel, but a program director usually sits beside them, and that reader repeats whatever your line says in a funding meeting.

The metric-to-outcome translation is yours to do before anyone reads the page. Keep the technical line (model type, data, serving setup), but don't let it end there: close each entry with the operational change — fewer missed follow-ups, faster intake triage, shorter outreach lists.

When a metric must stay, pair it with the decision it changed, because a mission-side reader trusts decisions more than curves.

Owning the pipeline end to end on a nonprofit résumé

Nonprofit data teams run lean, and a lean team hires for range. Show that you've carried a model from raw data to production without a platform team underneath you: name the stages you owned alone (collection, labeling decisions, training, deployment, monitoring) and say plainly which you didn't. A machine learning engineer who claims the whole pipeline gets asked about the whole pipeline.

Attach the artifacts that settle doubt: a model card, an eval harness, and a serving path — proof the model ran in production, not in a notebook. Link a repo README that explains the tradeoff you made when the data was thin. Mission datasets usually are.

On a nonprofit résumé, the eval harness earns its line by naming who the model could fail, not by raising a leaderboard score. Vulnerable users aren't an edge case in this work; they're the population.

What each model costs to run, written for nonprofit review

Serving cost is a résumé line in nonprofit work, not an ops footnote. A model that's expensive to run is a model a small organization quietly turns off, so state the serving-latency budget you hit and how you kept inference cheap — distillation, batching, a smaller model that did the job. You're telling a funder's budget that the work won't outgrow it.

Write the cost line the way the reader budgets — by what it takes to keep the model answering, in plain words rather than instance specs. A line like 'kept the deployed model on the cheapest serving tier by distilling it' reads as stewardship.

An ML lead will still probe the engineering in the interview. The cost line exists so the person guarding the budget doesn't have to ask.

Scale trophies to cut, and what the cover letter carries instead

Cut the scale flex first: training-cluster sizes, engagement lifts, ad-targeting wins, and any percentage that measured revenue instead of people. On a nonprofit application those lines don't impress — they raise the quiet question of how long you'll stay once the novelty wears off. Keep the engineering depth, lose the trophies that only made sense at production volume.

Your reasons for wanting mission work go in the cover letter, where they have room to breathe. On the résumé itself, motive shows up as choices — a volunteer data project, a civic-tech contribution, a deployment you kept alive after the contract ended. The résumé argues with evidence. The cover letter gets to argue with conviction.

Set a nonprofit listing beside a corporate listing, pull a few from Browse Machine Learning Engineer jobs, and let each posting's verbs decide what stays.

Run the outsider test before you send anything: hand a deployed-model entry to someone who's never trained a model and ask what changed for the people served. If they answer in their own words, that entry is done; if they recite your metric back, translate and try again.