Name the Problem, Not Just the Tool

There is a specific failure mode in engineering resumes where every bullet turns into a technology roster. The sentence starts as a description of work and ends as a comma-separated list, because naming tools feels like conveying information.

It isn’t, mostly. A tool name tells the reader what was in the room. The problem you were solving tells them what you were doing there, and that is the part that’s hard to fake.

What a tool name actually communicates

Very little on its own, because the range of possible experience behind any given name is enormous.

“Kafka” spans someone who consumed from a topic another team owned, and someone who has rebalanced a cluster during an incident. “Terraform” spans someone who edited a variable file, and someone who has untangled state after a partial apply. The reader cannot distinguish these, so they assume the lower end — which means a bullet whose payload is tool names gets discounted to almost nothing.

Naming the problem removes the ambiguity for free:

Inventory: Built data pipelines using Kafka, Spark, and Airflow.

Problem-first: Rebuilt the nightly batch aggregation as a streaming job after the batch window stopped fitting in the night — Kafka for ingest, Spark Structured Streaming for the aggregation, with a replay path for late-arriving events.

Both are illustrations rather than descriptions of any real system. The second one names the same three-ish technologies and yet the reader now knows why they were chosen, what the constraint was, and that you thought about late data. The tool names became evidence instead of decoration.

The one-tool-per-clause guideline

A practical limit that holds up well: one technology per clause, and only when the clause would be ambiguous without it.

Cut cold-start latency on the image resize endpoint by moving the model load out of the request path and into a warm sidecar.

No technology named at all, and it’s a perfectly informative bullet. Adding “(Python, FastAPI, Docker, AWS Lambda, S3)” to the end would add nothing except the impression that you were reaching.

Where the name does carry weight, it’s usually because the choice was non-obvious or because the technology is the substance of the work: “wrote a custom Kubernetes controller to reconcile tenant namespaces” needs Kubernetes in it, because that’s what the work is.

Two questions before a tool name goes in

Would the sentence be ambiguous without it? “Migrated the primary datastore” is genuinely unclear; “migrated the primary datastore from MySQL to Postgres” is not, and the pair of names is doing real work because the difference between them is the difference in the migration.

Is it a baseline for the role you’re applying to? Naming Git, Docker, or a CI system in a bullet is like mentioning that you used a keyboard. If everyone applying has it, it isn’t information, and it costs you a fifth of a line.

Everything that fails both questions belongs in the skills section, if anywhere. That’s what the section is for, and it does the job in a quarter of the space — see the tech stack list problem for how to structure it.

Version numbers, and when they matter

Mostly they don’t, and they date your resume badly. React 16, Python 3.8, Java 8 on a current resume implies you last touched them at that version, which is often not what you meant.

The exception is when the version is the story. Upgrade and end-of-life work is real engineering, frequently unpleasant, and the versions are the load-bearing detail:

Took the fleet off a Python version that had reached end-of-life, including replacing two abandoned dependencies and forking a third.

Here the specifics are the point. Elsewhere, drop them.

Don’t let the tool absorb the credit

A subtle version of the same problem: writing the bullet so the technology is the subject and you are the instrument.

Tool as subject: Utilised Datadog to improve observability across services.

You as subject: Instrumented the checkout path end to end so a failed order could be traced from the API call to the payment provider response, which is what let us attribute a recurring failure to a provider timeout rather than our own retries.

The second version happens to imply a tracing tool without naming one, and no reviewer will penalise you for that. What they take from it is that you know what tracing is for, which is the thing the first sentence was trying and failing to claim.

The verb matters here too. “Utilised”, “leveraged”, and “worked with” all put the tool in the foreground. “Instrumented”, “rebuilt”, “partitioned”, “rate-limited” put you there.

What to do with the specialism signal

The genuine argument for tool-heavy bullets is discoverability: engineers want the technology names on the page so that a reader looking for them finds them. That’s fair, and it has a cheaper solution than corrupting every sentence.

Put the names where they belong and let the density come from three places:

• The grouped skills block, which is scannable and is where a reader goes looking.
• A short role-level context line, before the bullets: Payments team — Go services on ECS, Postgres, Kafka. One line, sets the environment, and now the bullets underneath are free to be about work.
• One or two bullets where the technology is the substance, because you built something inside it rather than on top of it.

That arrangement gets the same names onto the page while leaving your bullets legible.

The reread

Take each bullet and delete every technology name from it. Then read what’s left.

If the sentence still describes a piece of engineering work with a problem and an outcome, put the names you actually need back in — usually one, sometimes zero. If deleting the names left you with “Worked on features for the platform”, the names were doing all the work, and the bullet needs to be rewritten rather than repopulated.

That’s the whole test, and it’s uncomfortable in a useful way: the bullets that collapse are almost always the ones about work you’d struggle to talk about for ten minutes anyway. Which is a signal worth having before someone else finds it, as the questions a technical reviewer is trying to answer covers from the reader’s side.