Which verbs matter on an engineering resume?

Which verbs matter on an engineering resume?

The verbs that matter are the ones that claim accountability for software running live. "Shipped," "owned," "migrated," "maintained," and "operated" all place the person somewhere on the path a feature travels from a laptop to a customer, and the further along that path the verb sits, the more it says.

The skills wall told you what technologies a person has touched. The verbs tell you what they were trusted with. "Built a payments service" and "shipped a payments service" describe the same noun with very different weight behind it, because the second one claims the work survived contact with real users. Nouns on a resume are easy to accumulate. Verbs describe a relationship to the work, and that relationship is what a req is actually hiring.

This lesson ranks the common verbs by the accountability they carry, explains why a migration line deserves attention, and covers the metric lines, the "reduced latency by 40%" claims, that look like evidence and are so far only decoration.

What does "shipped" mean?

Shipped means the work reached real users. The feature left the developer's machine, passed review, got deployed, and now runs where customers can touch it.

That makes it a materially stronger word than "built". "Built" can be true of something that never left a laptop: a prototype, a side project, a feature that was finished and then shelved. Software developed but never released is common, and it is honest work, so "built" is a fair word for it. "Shipped" rules that reading out. It claims the last mile happened, and the last mile is where the hard parts live: edge cases surfacing, real data breaking assumptions, and other people depending on the result.

A resume that repeats "shipped" with specific objects, "shipped the checkout redesign", "shipped search filters to 200k users", is describing a habit of finishing. Finishing is a distinct skill from starting, and plenty of strong starters lack it. The verb is small, and it is the single cheapest signal on the page.

Why does "in production" carry weight?

Production is the live environment, the version of the software customers actually use, and "in production" means the person's work runs there right now. Weight comes from what living there costs. Production work has to survive real traffic, real data, and real failure. When it breaks, there is an incident, someone gets paged, and someone has to explain what happened. A developer whose code has lived in production has been on the receiving end of that loop, and it changes how they build. They have learned what why software is never done covers from the inside: the bug reports, the 2am pages, the fix that has to go out under pressure.

Nearby phrases sharpen the same claim. "On-call for the billing service" means the person carried the pager for it. Quoting an uptime figure means they were measured on keeping something alive. "Owned," in the production sense, means the service's health was theirs whether or not they wrote the original code.

What does leading a migration involve?

A migration is moving a live system from one technology to another while customers keep using it: one database to another, an old codebase to a new framework, a company's own servers to the cloud. Leading one means planning and sequencing that move so nothing user-facing breaks along the way.

Engineers compare it to changing an airplane's engines mid-flight, and the comparison is earned. The system cannot stop, so the work happens in careful stages: run old and new side by side, move traffic over a small slice at a time, verify each slice, and keep a tested rollback path ready at every step in case the new system misbehaves. A migration lead is holding the whole sequence in their head, plus the failure plan for each stage, plus the coordination across every team whose work touches the system.

That is why "led the migration" is one of the stronger lines a resume can carry. It bundles production accountability, planning under constraint, and cross-team trust into one verb, and companies hand that work to people they already rely on. The word "led" earns scrutiny of its own, since one migration can appear on five resumes. The person who set the sequence and the person who moved one slice both took part, and the specifics on the line usually reveal which was which.

When does "maintained" outrank "built"?

"Maintained" outranks "built" whenever the req's real work is changing an existing system safely, and most engineering work is exactly that. The majority of professional development happens inside long-lived codebases that other people wrote, full of accumulated technical debt and undocumented decisions.

"Maintained" reads as a modest word next to "built", and the modesty is misleading. Building on a blank page means every choice is yours and nothing can break, because nothing exists yet. Maintaining a system serving customers is the harder discipline: reading unfamiliar code, changing it without breaking what depends on it, refactoring carefully, and keeping tests trustworthy so the next change is safe too. Maintainers develop a specific caution that greenfield work never teaches.

So match the verb to the req before ranking it. A team whose codebase is eight years old and load-bearing is hiring the maintained skill set, whatever the posting says about building.

What does "end-to-end ownership" claim?

"End-to-end ownership" claims the person carried a piece of work through its whole life: shaping the design, building it, shipping it, and staying accountable for it in production, including the failures. It is the maximal accountability claim, all the earlier verbs of this lesson rolled into one phrase.

When the claim is true, it marks a developer who can be handed a problem instead of a task, which is the working definition of seniority on most teams. When it is inflated, it decorates a role where the person built their slice while others designed, released, and carried the pager. Both versions produce the same phrase.

The difference shows in the surroundings. A genuine ownership claim travels with production vocabulary: the incident they handled, the on-call rotation, the metric they were answerable for, the trade-off they chose and lived with. A decorative one sits alone. Give more weight to a resume that says "owned checkout, carried its on-call, held its conversion metric" than to one that says "end-to-end ownership of multiple services" and stops there, whatever the seniority of the title above it.

Why does "reduced latency by 40%" mean nothing yet?

Latency is how long a system takes to respond, and "reduced latency by 40%" carries no information on its own because every anchor is missing. Forty percent of an unknown starting number could be anything. From five seconds to three is work customers felt. From 50 milliseconds to 30 is a change no human can perceive. The same percentage covers both.

Three anchors turn the decoration into evidence. The baseline: what the number was before. The scale: how much traffic, how many users, how big the system. The consequence: who noticed, and what changed for them because of it. "Cut checkout page load from 4 seconds to 2.4 at 80k daily orders" has all three and is a real claim about real work. The bare percentage has none, and this pattern repeats across every metric a resume can carry: cost savings, throughput, error rates, "improved performance by 3x".

An unanchored number is a prompt rather than a verdict. Strong candidates often compress a true story into a bare percentage because resume space is short, and the full story is usually one conversation away. The lesson on numbers without denominators, later in this path, covers how those stories hold up live. For the paper read, the rule stays simple to apply: a verb claims accountability on its own, and a number needs its anchors before it claims anything at all.