Unfalsifiable Claims on an Engineering Resume

A claim carries information in proportion to what it rules out. “Built a scalable microservices architecture” rules out nothing — no engineer has ever described their own architecture as unscalable — so a reader learns nothing from it except that you wanted them to be impressed.

This is not about honesty. Every sentence discussed here can be entirely true. It is about a specific defect: sentences whose negation nobody would ever write, which is exactly the property that makes them free to say and worthless to read.

The test

For any line on your resume, try to state the version that would be false. If the false version is a sentence a real engineer might plausibly have written about real work, your claim carries information. If the false version is absurd, the claim is decoration.

“Wrote clean, maintainable code” — the negation is “wrote code that was difficult to maintain”, which nobody writes about themselves. No information.

“Migrated the service from a shared database to its own, with a dual-write period and a reconciliation job” — the negation is “did a hard cutover with no reconciliation”, which people do, quite often, deliberately. Information.

This test is faster than the alternatives and it catches things a proofread doesn’t, because the offending sentences are all grammatical, plausible, and confidently written.

The standard offenders, and what to write instead

Scalable. Means nothing without a dimension and a limit. Every system scales until it doesn’t; the interesting part is where the ceiling was and what you did about it.

Instead: Reworked the notification fan-out from per-recipient database writes to a batched producer, which took the nightly send from a job that ran past its window to one that finished inside it.

Robust / resilient / highly available. Name the failure mode you handled. Resilience is always resilience to something.

Instead: Made the payment webhook handler tolerant of duplicate and out-of-order deliveries by keying on the provider’s event ID and treating state transitions as idempotent.

High-performance / optimised. The mechanism is the content. Which layer, and what was the constraint?

Instead: Cut the report endpoint’s tail latency by replacing a per-row lookup with a single join and adding the covering index it needed — the query had been the cause of the connection-pool exhaustion under load.

Best practices. This is the emptiest phrase in the genre, because it asserts conformity to an unnamed standard. If you know the practice, name it.

Instead: Made the migration runner refuse a deploy whose schema change wasn’t backward-compatible with the currently running version, which removed the failure mode where a rollback couldn’t be rolled back.

Architected. Reads as a claim to authority and invites the reviewer to test it. “Designed”, “proposed”, “argued for”, and “wrote the RFC for” are all more specific, and each says something about how the decision actually happened — see design documents, RFCs, and what they show.

End-to-end / full-stack ownership. Sometimes accurate and worth saying. Usually it means “did some of several things”. Name the layers you actually held: owned the API, its Postgres schema, and its deploy; the frontend was another team.

Cutting-edge / modern / state-of-the-art. These date the resume instantly and imply the writer thinks recency is a qualification. Drop them without replacement.

Cross-functional collaboration. True of everyone. If the collaboration was the hard part, say what it consisted of: the teams, the mechanism, the deadline. That construction is covered in the staff-level resume problem.

The pseudo-metric, which is worse than the adjective

Some unfalsifiable claims arrive wearing a number, which makes them harder to spot and more dangerous, because a number invites a question.

Test coverage figures. A coverage number is a measurement of which lines executed, not of whether the tests are any good, and every engineer reading your resume knows that. Citing one signals that you measure the thing that’s easy to measure. What’s worth citing instead: that you made a suite reliable enough to block merges on, that you added tests to a path that had none before changing it, or that you cut a suite’s runtime enough that people stopped skipping it.

“Improved developer productivity.” Not measurable by any method your reader will accept. Its defensible cousins are concrete: build time, deploy frequency, time from repository creation to a running service, the number of manual steps removed.

“Reduced technical debt.” Unquantifiable by construction. Say what you deleted or replaced, and how you established it was safe — the version in when the work was keeping a legacy system alive.

Round percentages with no baseline. The defensibility question — could you explain the measurement in two sentences? — is the filter, and when the numbers belong to another team covers what to do when the measurement wasn’t yours to see.

Why these sentences get written

Not laziness, mostly. Three real causes, and each has a different fix.

The work is hard to describe and the adjective is a shortcut. Common with infrastructure and platform work, where the outcome is an absence. The fix is a frame that makes absence concrete, which is what resumes for infrastructure and platform roles is about.

Genuine uncertainty about how much detail is appropriate. People flatten specifics because they assume a reviewer won’t follow them. For an engineering resume this is backwards: the specific version is both shorter and more legible to the person who will actually read it.

The claim is doing work the evidence can’t. Sometimes “scalable architecture” is standing in for a system that was not, in fact, difficult. That is fine — most systems aren’t — and the honest small claim reads better than the large empty one.

Where an adjective is legitimately load-bearing

This is not an argument for stripping all description. A qualifier earns its place when it is bounded, when the alternative was real, or when it names a property that could have been otherwise.

“Idempotent”, “append-only”, “eventually consistent”, “single-writer”, “at-least-once” are all adjectives, all falsifiable, and all informative — each one rules out a different design. That is the difference. The problem was never adjectives; it was adjectives with no opposite.

The pass to make

Go through your resume and mark every claim whose negation nobody would write. Then, for each one, replace it with the mechanism underneath it — the failure mode, the constraint, the layer, the thing that changed.

Most people find this shortens the document while making it more specific, which feels contradictory and isn’t: the empty claims were long. Six words of adjective become nine words of fact, and the nine words are the only ones a technical reader was ever going to act on.