Building Evidence for a Term You Don't Have

Suppose you have done the counting in auditing your stack list against real postings and it produced an uncomfortable result: a technology that appears in most of the roles you want, and nowhere in anything you can point at.

The standard advice at this point is “build a side project.” That is the fourth-best option, it is slower than it looks, and for several classes of gap it cannot work at all. Start further up.

First, check that the gap is real

Two things masquerade as missing experience.

You have it and never wrote it down. Extremely common. The thing had a local name — you called it “the deploy stuff” or “Atlas” or “the nightly job” for three years and never once typed the vendor’s word for it. Re-read your last two years of work against the term rather than against your memory of your resume.

You have the adjacent thing. You have not run Kubernetes, but you have operated a scheduler and know what a rolling deploy, a health check, and a resource limit are. You have not used Kafka, but you have built consumers against another broker with the same delivery semantics and hit the same replay problems.

Adjacent experience is a genuine answer, and it has to be written as a comparison rather than as a claim:

Ran the service fleet on ECS: task definitions in Terraform, rolling deploys, health checks and autoscaling policies. No Kubernetes in production, though the operational model transfers.

That reads as competence and calibration. Writing “Kubernetes” in your skills list on the strength of the same experience reads, when probed, as overclaiming — and it will be probed, because it is on the list.

Option one: get it at work

Consistently the fastest route and consistently the one people skip, because it is less fun than starting a repository.

Concrete moves, in rough order of availability:

• Volunteer for the migration nobody wants. Migrations are where new technology enters an organisation, and they are chronically short of volunteers.
• Take the on-call rotation for the service that uses it. Operating something is the strongest form of the experience and it is often the easiest to be given.
• Do the internal tooling task. The small thing on the backlog that touches the piece of infrastructure you want.
• Ask to review that part of the codebase. Slower, but it is real exposure and it costs your manager nothing.

The advantage is not only speed. It is that this is the only route that produces evidence with an employer’s name on it, in a bullet with a scope and a consequence. It also improves the description of your current role rather than adding a section below it, which is where a reviewer is actually looking.

The obvious limitation: it needs a quarter or two, and a job where the technology exists at all. If neither is true, keep going.

Option two: a project where the term is a means, not a subject

The distinction that decides whether a project works:

• A project about the technology is a tutorial with your name on it. “Kubernetes cluster demo,” “Kafka playground.” It proves you followed instructions.
• A project that had an honest reason to need the technology is evidence, because the interesting decisions are visible.

Which means the honest version of this advice comes with a boundary that most articles skip. Some gaps a side project cannot close, and reviewers know which. A single-user project has no honest reason to need a multi-node cluster, a service mesh, or a multi-region failover story, so building one is transparently an exercise. Nor can a project produce evidence about cost governance at scale, migrating a system a hundred people depend on, or operating anything under real traffic.

What a project can honestly demonstrate: a language, a data-processing pattern, service and API design, testing discipline, a build and release path, small-scale observability, and the ability to finish something.

Worked example, and it is one you already have a reason to build: the corpus counter from the audit above. A scheduled job pulls postings, normalises the terms, stores them, and produces a report you actually read. That has real content in it — de-duplicating syndicated listings, mapping aliases, making re-runs idempotent, caching so you are not refetching the same records every morning.

Note where the engineering is not. Fetching the data is a solved commodity — Serply’s published API reference describes its endpoints as plain GET requests returning JSON, and every comparable service looks much the same — so the API call is four lines and the project is entirely what you do with the response. That is the shape to look for in any project meant as evidence: if the thing you would put on your resume is “called an API”, there is nothing there.

Option three: a contribution to the ecosystem

A merged, non-trivial change to a project in that technology’s ecosystem is the strongest evidence per hour of the three, because it demonstrates working in an unfamiliar codebase to somebody else’s standard. It is also the hardest to schedule, since it depends on finding a real issue at the right size. Side projects, open source, and what counts covers how contributions get read once you have one.

Option four: apply anyway

Present the adjacent experience honestly and let the reader decide. This is a legitimate ending, particularly at senior level, and it is what the comparison bullet above is for.

The four ways this goes wrong

“Currently learning X” in the skills section. It communicates that you knew the term mattered and haven’t got there. If you want to say it, say it in conversation, where it comes with context. On the page it is a self-reported gap in a list of claims.

A repository whose first and last commit is the week you updated your resume. Commit dates are public and reviewers do look at them.

Trivial use counted as experience. One Dockerfile is not container orchestration. One managed queue is not stream processing. The bar is whether you hit a problem that only appears past the first tutorial.

Listing it before it is true, betting on the interview. The interview is where this fails, and it fails expensively: the reviewer is now recalibrating the rest of your list.

Writing it once it exists

Put the term in the bullet where the work is, then let the skills list carry it. A skills entry backed by a visible bullet is credible; the same entry alone is just a noun.

Match the verb to the tier of the evidence — “used”, “built with”, and “operated” are three different claims, and picking the accurate one is what makes the whole list survive contact with a technical reviewer. That is the same standard as the tech stack list problem: could you answer how did you use this in two sentences, without the answer being the name of a tutorial?

And if a gap resists all four options for a year, consider that it might not be your gap. Chasing the market’s most common term can quietly cost you the specialism you already have — which, per what a link to your code actually proves, is usually the thing carrying your strongest evidence anyway.