A DevOps or platform engineering CV reads best when it leads with reliability, on-call ownership, infrastructure migrations and the tooling other teams depend on, rather than the feature-shipping bullets a general software engineer CV commonly leads with. The two CVs share most of the same mechanics: reverse-chronological experience, a short summary, a skills section, and bullets that describe outcomes rather than duties. What changes is which outcomes actually count as impressive in this kind of role, since the people who benefit from infrastructure work are usually other engineers rather than end users, and the work itself is often invisible when it goes well.
Why the emphasis shifts
A feature a software engineer ships usually has a visible before-and-after: a screen that did not exist, a flow that used to take five steps and now takes two. Infrastructure and platform work rarely gets that same visible payoff, because the best possible outcome is often that nothing changes from a user's point of view, a deploy that used to page someone at 2am now does not, a service that used to fall over under load now does not. A CV for this kind of role has to make that invisible reliability legible to a reader who has never worked in infrastructure, by naming what depended on the work and what would have broken without it, rather than assuming a reader already understands why a migration or a monitoring change mattered.
Describing reliability and uptime honestly
Reliability work invites the same trap covered in quantifying engineering impact on a CV without inventing numbers: a tempting but unverifiable "improved uptime by 40%" when no such figure was ever actually tracked. Where a real, currently checkable metric exists, from a dashboard or an incident report you can still point to, it belongs on the CV as stated. Where it does not, scope and before-and-after language carry the same weight without the risk: how many services sat behind the change, what used to fail and stopped failing, which team no longer had to work around the problem manually. A bullet built from what you actually witnessed is defensible in an interview in a way a rounded-up percentage is not.
On-call and incident response as CV content
On-call ownership is worth naming directly rather than folded into a vague "supported production systems" line, since it signals a level of operational responsibility a purely feature-focused role does not carry. What reads well is the shape of the responsibility: which system or systems you carried the pager for, roughly how the rotation worked, and one concrete thing that changed because of an incident you handled, such as a runbook that existed afterward and had not existed before, or a class of alert that stopped firing once its root cause was fixed. What reads poorly is a bare list of incident counts or severity levels with no context, since a reader outside the team has no way to judge whether those numbers were good, bad, or typical for the system involved.
Migrations and infrastructure changes worth naming
A migration, a platform change, or a tooling switch is worth its own bullet when it is the kind of project other engineers had to adapt around, rather than a purely internal change nobody outside the team noticed. Naming what moved and why is usually more informative than naming the destination technology alone: "moved a shared deploy pipeline off a manually triggered script and onto a version-controlled workflow every team used afterward" tells a reader far more than a bare mention of the tool's name on its own. Where a migration ran over months, it is usually worth describing your specific piece of it, especially on a team project, rather than describing the whole migration as though you carried it alone.
Tooling other teams depend on
Internal tooling deserves the same treatment a customer-facing feature gets: what it does, who used it, and what it replaced. Presenting side projects on a software engineer CV covers the same underlying structure for work built outside a formal job, and it applies just as well to an internal tool built inside one: a deploy dashboard other engineers checked before a release, a provisioning script that replaced a manual setup checklist, a linting rule that caught a class of misconfiguration before it reached production. The detail that makes a tooling bullet credible is naming who actually used the thing, since a tool nobody adopted is a weaker CV line than a smaller tool the whole team relied on.
Illustrative example: a bullet rewritten around infrastructure ownership
Before, vague and feature-shaped: "Worked on infrastructure and deployment for the backend team." After, rewritten around ownership, scope and a described before-and-after state: "Owned the deploy pipeline for the backend team's eleven services; the pipeline previously required a manual approval step for every service before it could ship, and after the rewrite, a passing test suite was enough to deploy automatically, cutting the number of engineers who had to be available at release time from three to one." Nothing in the second version is an invented statistic; the eleven services, the manual step, and the staffing change are all things the person could describe from direct experience.
Grouping a long tools and platforms list
A platform engineering skills section often runs longer than a typical developer's, spanning cloud providers, orchestration tools, monitoring systems and languages at once, which is exactly the kind of long, mixed list that benefits from category grouping rather than one unsorted line, a formatting choice covered in more depth for engineering CVs generally elsewhere on this site.
Build yours
CVBuilderKit's Developer template is built around project- and ownership-led entries, which suits infrastructure and platform work as well as it suits application code. Start from it, or from a blank document, in the builder and rework your reliability, on-call and migration bullets around what actually depended on the work before reaching for a number you cannot currently point to.