Skip to the article
Conxfolio
Example · Platform

A DevOps engineer résumé example, measured in deploys and pages

One complete DevOps engineer résumé, written out in full. The person is invented. The reading and the score come from the product itself.

— on-call load is a result. say what it was before.

The devops engineer example résumé drawn as a complete page in the Monoline design: name, summary, the roles with their bullet lines, education and a skills row
The example below, drawn by the builder's own renderer in the Monoline design. The picture was taken by pressing this page's own Use this example door and photographing what the editor rendered.

Platform work is judged by how much friction it removed, and that is measurable in ways most DevOps résumés never use. This example is written out in full so you can read those measures, then put through the tools here so you can see what software takes from them. The candidate is invented. Marisol Trenchard does not exist, neither employer exists, and every figure was chosen to demonstrate a shape.

The example, in full

An invented person. Not a real document, and not yours.

Marisol Trenchard
DevOps Engineer
Barcelona, Spain · [email protected] · +34 93 555 0187

Summary
DevOps engineer with seven years on build systems and production platforms. Works on deploy speed, on-call load and the paved road other teams use.

Experience

Senior DevOps Engineer · Pellworth Health, Barcelona · 2021 to present

  • Cut deploy time from 38 minutes to 6 across 40 services and raised releases from 12 to 90 a week.
  • Reduced infrastructure spend by 29% by right-sizing 260 workloads.
  • Rebuilt on-call so incidents per engineer fell from 6 to 2 a month across 9 teams.
  • Migrated 40 services to a single deployment pipeline with 0 customer-facing outages.

Platform Engineer · Ovingdean Systems, Valencia · 2018 to 2021

  • Built the continuous integration platform running 2 800 builds a day.
  • Cut the average build from 21 minutes to 9 by caching and parallel test shards.
  • Wrote the infrastructure modules used by 14 teams for 3 years.

Education
BSc Software Engineering · Montjuic Polytechnic, Barcelona · 2014 to 2018

Skills
Kubernetes, Terraform, AWS, CI/CD, observability, incident response, Go, Python, cost optimisation, platform engineering

Languages
Spanish · native · Catalan · native · English · C1

Four numbers describe a platform

Deploy time from 38 minutes to six. Releases from twelve to ninety a week. Infrastructure spend down 29% across 260 workloads. Incidents per engineer from six to two a month. Each of those is a before and an after, and together they describe a platform team that changed how a company ships.

The migration line carries the risk half: forty services onto one pipeline with no customer-facing outages. A platform engineer who has moved forty services without breaking anything is making a claim about care, and the absence of an incident is the evidence for it.

Build times are the line juniors should copy

Two thousand eight hundred builds a day, average build from 21 minutes to nine by caching and parallel test shards. It names the volume, the improvement and the method in one sentence, and every engineer reading it knows exactly what work that was.

The modules line is the quiet one: infrastructure modules used by fourteen teams for three years. Longevity is a result. Something other teams still depend on after three years is a stronger signal than a migration that was reversed.

What the reading found

The door below hands the document to the résumé builder as plain text, through the same import an uploaded file goes through, and the review shows every field beside the line it came from. Here the completeness pass found four readable sections, 111 words of experience evidence and ten distinct skills.

The Conxfolio import review after the door opened, showing Marisol Trenchard's example read into fields beside the rendered page, with the line saying it is an example
The real import review, opened by this page's own door. It names Marisol Trenchard as invented before anything is saved, and it shows every field beside the line it came from.

No language model is used. The readers are deterministic functions with their own rules and their own confidence, every string they emit is checked to be a span of the document, and a field that fails that check is dropped and counted rather than kept.

What the checker scored it

The same import review on a 390 pixel phone screen, with the example notice above the accept button
The same door on a phone. Nothing is withheld on the small screen: the notice, the reading and the accept button are all there.

Ninety-seven out of 100, with one improvement remaining worth 8 points. The arithmetic is 100 × 30% + 100 × 30% + 92 × 40% = 97, explained in the article on the score. Seven action-led lines, four measurable, seven lines of depth and 179 readable words against a band opening at 250.

A third role would close that gap and this candidate does not have one. The ATS checker says so in those terms rather than implying the document is weak, which is the difference between a measurement and a verdict.

What this example leaves off

No certification list, no cluster counts without context and no uptime figure quoted as nines without saying what was measured. An availability number is only useful beside the thing it describes, and a naked string of nines invites the question rather than answering it.

Tool inventories are left off as well. A platform engineer is hired for what happened to deploy time, spend and on-call load, and a list of thirty tools is usually where a page goes when those three numbers are missing.

What to change for your own

Change the platform and keep the four numbers. Bare metal, managed Kubernetes, serverless and hybrid estates all use this shape. Then put your own deploy times, release counts, spend changes and on-call load in, and state what each was before.

Keep one longevity line. Keep the languages if you work across borders. The design gallery holds 37 layouts, and the data engineer example, the QA engineer example and the product manager example sit beside this one.

Write yours beside it

Opens the builder with Marisol's example loaded, saved as its own entry in the Monoline design. Replace every line with your own. Free, no account.

Use this exampleCheck a résumé instead

Questions

Is Marisol Trenchard a real engineer
No. She is invented for this page, and so are Pellworth Health and Ovingdean Systems. The figures show a shape and describe nobody's career.
What is the strongest DevOps line
The one about on-call. Incidents per engineer falling from six to two a month across nine teams is a change to other people's lives, and it is the result a platform lead is hired to produce.
Should I list every cloud service
No. Ten skills, and the ones that matter appear again inside an achievement line where they are attached to an outcome. A list of forty services reads as a list of forty tutorials.
What did the checker score it
97 out of 100, with one improvement remaining worth 8 points. The document has 179 readable words, and the volume rule's top band opens at 250.
Is a cost saving safe to publish
A percentage usually is; an absolute cloud bill usually is not. Right-sizing 260 workloads for a 29% reduction makes the point without publishing a former employer's spend.
Which design is this rendered in
Monoline, one of the 21 ATS-safe layouts out of 37. Its single weight and tight rhythm suit a page of short technical lines.

Conxfolio is a free set of four career tools: a résumé builder with 37 rendered layouts, an ATS résumé checker that prints its own arithmetic, a cover letter builder that traces every proof paragraph back to the line it came from, and a portfolio builder with 20 authored designs. There is no account to create, nothing is held back for a paid plan, and no language model is used anywhere in the product, so the readers, the score and the letter are deterministic code you can check.