Writing Engineering Bullets That Say Something

Here is the bullet almost everyone writes:

Worked on the payments service using Go and PostgreSQL.

And here is what a reviewing engineer takes from it: this person was on a team that has a payments service. Nothing about what they did, what was hard, or whether they’d be useful.

The advice usually given for fixing this is “quantify your impact,” which produces the second-most-common bullet:

Optimised payments service, improving performance by 300% and saving $2M annually.

That’s worse. Not because quantification is bad, but because that number almost certainly isn’t real, and the person interviewing you is going to ask about it. “300% faster on what workload, measured how, against what baseline?” is a completely normal question, and if the honest answer is “it felt quicker after we added the index,” you’ve spent your credibility on a line you didn’t need.

There’s a third way, and it’s better than both.

The structure that works

A good engineering bullet answers three things in one sentence: what you did, what problem it solved, and what changed.

Replaced the payments service’s synchronous fraud check with a queue-backed flow, cutting p99 checkout latency from around 4s to under 800ms and removing the timeout errors that had been the top support complaint.

Look at what a reviewer gets from that. A recognisable technical decision (sync → async), a specific mechanism (queue-backed), a real measurement (p99, before and after), and a business consequence they can understand. It also tells them you know what a p99 is and that you were paying attention to support tickets, which are both signals in themselves.

Every part of that is defensible in an interview, because it’s what actually happened.

Numbers: the defensibility test

Use this rule: if another engineer asked “how did you measure that?”, could you answer in two sentences?

Numbers that usually pass:

• Latency percentiles from a dashboard you actually looked at
• Request or event volume the system handled
• Data sizes, row counts, index sizes
• Build or deploy times, before and after
• Team size, service count, number of consumers of your API
• Incident counts or on-call pages per week
• Cost figures if you saw the bill — cloud spend is genuinely measurable and worth citing when you have it

Numbers that usually fail:

• Percentage improvements where nobody benchmarked the baseline
• “Increased developer productivity by X%”
• Revenue attributed to a technical change with no experiment behind it
• Anything ending in “%” that you computed after the fact from vibes

If you’re in the second category, don’t downgrade to vagueness — downgrade to specific description:

Cut the CI pipeline from “long enough that people stopped waiting for it” to under five minutes by parallelising the test suite and caching the dependency layer.

No invented percentage, and it lands harder than one would, because it’s obviously the truth.

Say what you owned, not what the team achieved

The other reliable way to lose an interview is scope inflation.

Migrated the platform from a monolith to microservices.

If you were one of eight engineers on an eighteen-month programme, this is a claim you cannot support. The first probing question dismantles it, and now everything else on your resume is in question too.

The honest version is not weaker:

Owned the extraction of the billing and invoicing domain during the platform’s monolith decomposition — designed the service boundary, wrote the dual-write and backfill for 4M customer records, and ran the cutover with no downtime.

That’s a bigger claim in every way that matters. It shows judgement, a specific hard problem, and ownership of a risky moment. “Migrated the platform” shows a bullet point.

Useful verbs for honest scope: owned, designed, built, led, drove, wrote, ran, introduced. Vaguer verbs that hide scope: worked on, was involved in, helped with, participated in, contributed to. If you genuinely were a contributor rather than an owner, say what your contribution was: “contributed the retry and idempotency layer to a team migration of…” is precise and perfectly respectable.

Include the decisions, especially the trade-offs

The single strongest seniority signal available in a resume bullet is evidence that you chose between options and knew what you were giving up.

Chose Postgres advisory locks over a distributed lock service for the scheduler, accepting the single-region constraint in exchange for removing a dependency the team would have had to operate.

A reviewer reading that learns more about how you think than they would from five bullets listing technologies. It says: this person considers alternatives, understands operational cost, and can articulate a trade-off. That’s the difference between a mid-level and a senior resume, and it’s mostly a writing difference rather than an experience difference — plenty of mid-level engineers make decisions like this and never mention them.

You don’t need one of these per role. One or two across the whole resume changes how the document reads.

Write the invisible work

Some of the best engineering work has no user-visible outcome. Deleting code. Fixing flaky tests. Making an alert stop firing. Upgrading a runtime before it went out of support. Writing the document that stopped a bad architecture from being built.

This work is chronically under-reported because it doesn’t fit the “impact” framing. Fit it anyway, by naming the cost that was avoided or the state that changed:

Deleted the legacy recommendation pipeline after confirming with the data team that nothing consumed it — removed 11k lines, two cron jobs, and a Redis cluster from the bill.

Took the flakiest 20 tests in the suite from a ~30% failure rate to zero over a quarter, which is what let us turn on merge-blocking CI.

Upgraded the fleet from Python 3.8 ahead of end-of-life, including three libraries that needed forking or replacing.

These read as the work of someone who leaves systems better than they found them, which is exactly what a hiring team is looking for.

Practical rules

One idea per bullet. If there’s an “and also” in the middle, it’s two bullets — or one of them wasn’t worth mentioning.

Lead with the verb. Not “Responsible for maintaining…” Not “Was tasked with…” Start with what you did.

Past tense for past roles, present for the current one. Consistently.

No end punctuation, or full stops throughout. Pick one. Mixed is sloppy and reads as such to people who care about consistency for a living.

Two lines maximum. Three-line bullets don’t get read. If it needs three lines, the interesting part is buried; find it and lead with it.

Three to five bullets per role, weighted toward recent and relevant.

The pass to make before you send it

Go through every bullet and ask two questions.

Could a competent engineer on my team have written this exact sentence about their own work? If yes, it’s too generic — it describes the team’s context rather than your contribution.

If an interviewer picks this line and says “walk me through it,” do I have ten good minutes? If not, either you’re overclaiming or you picked the wrong thing to highlight. Both are worth fixing before someone else finds them.