What a Requirements List Is Evidence Of

You read a posting, it asked for five years of Kubernetes, you have two, and you closed the tab. Or the reverse: it asked for something you have never touched and you spent a weekend rewriting your resume around it.

Both reactions treat one sentence in one document as a measurement. Before you do either again, it is worth asking what kind of document that sentence came out of, and what a reasonable person can infer from it.

This is a narrower question than reading a posting for what the team is like — what an engineering job posting tells you about the team covers that, and it is about deciding whether to apply. This post is about evidence strength: what a given line licenses you to change.

Who writes the sentence

A requirements list is usually a composite. Something like: a hiring manager writes a handful of bullets, sometimes in a chat message. A recruiter or coordinator turns those into a posting using the last posting for a similar role as the skeleton. Standard organisational text gets appended at the bottom. Somebody approves it by skimming.

None of that is dishonest and none of it is unusual. But notice what it means: nobody in that chain asserted a measured threshold. The person who knows the work wrote the shortest part of the document, and the longest part was inherited from a file.

The practical consequence is that a requirements list has mixed provenance, line by line, and the lines are not labelled.

One posting versus many

At n = 1, a requirement line is evidence that somebody wrote it. That’s all. The plausible causes are numerous and you cannot tell them apart from outside: it was inherited from a template, it is a proxy for a level the writer couldn’t express any other way, it is an anchor intended to reduce application volume, or it is a genuine constraint on the actual job.

At n = many, frequency starts to mean something, because postings written independently by different organisations don’t share the same accidents. If a term shows up across most of the postings in a corpus you defined, that is evidence about the vocabulary of a market — which is exactly the measurement in auditing your stack list against real postings.

The caveat is the word independently. Postings are not independent when they come from the same agency, the same posting template circulating in an industry, or one employer listing twenty near-identical variants. A frequency count is only as good as the de-duplication under it.

The exact-phrase test

Here is a cheap way to check the provenance of a specific line rather than guessing at it. Take the sentence that worries you, put it in quotation marks, and search for it.

If the identical wording comes back from a dozen unrelated employers, you are looking at template text, and it tells you nothing about this team. If it comes back only from this company, someone wrote it about this job. Exact-phrase matching and site restriction are documented features of the query syntax — Serply publishes a reference for search operators covering both — and this is one of the few resume-adjacent tasks where the operators genuinely earn their keep.

It takes about a minute per sentence, and you only need to run it on the two or three lines that were about to change your behaviour.

The years number in particular

“Five years of X” is the softest line in the genre, for a reason that has nothing to do with hiring philosophy: years is a proxy. The writer wanted to say “senior enough to have seen this go wrong” and the template had a field for a number.

Two checks you can run yourself:

Compare the number to the technology’s age. If a posting asks for more years of a framework than the framework has been publicly available, look up its first release — it takes ten seconds — and you have direct proof that the line was not produced by anyone thinking about the work.

Check whether the number varies across the same company’s postings. If two roles at the same organisation, at the same level, ask for different year counts on the same technology, the numbers are decoration.

What you cannot know is how the line gets used after you apply. That varies by employer and there is no general answer, so treat “will this specific number screen me out” as unanswerable rather than as a reason to self-reject. The one thing that is reliably true is that not applying guarantees the outcome.

Which lines actually carry weight

The useful heuristic is not where the line appears but how specific it is. Specificity is a proxy for provenance, because templates are generic by construction. Nobody’s boilerplate contains the details of your prospective team’s system.

Weight these highly:

• A concrete sentence in the responsibilities about work that exists: you will own the migration of the billing service off the legacy scheduler. A template does not contain that sentence.
• An unusual combination named together — a specific message broker alongside a specific runtime and a specific data store. That is a description of a real system, not a wish list.
• A requirement that is oddly narrow. Narrowness is expensive to invent.

Weight these lightly:

• Generic capability statements. Communication, collaboration, “passion for quality.”
• Long nice-to-have tails. The tail is where terms go to be comprehensive.
• Degree and years lines, per the above.
• Anything you just found verbatim on eleven other companies’ careers pages.

What to do with each

A strong, specific line justifies reordering your resume so the matching system leads: the project that resembles their problem goes first, the bullets about it get the space. That is emphasis, not fabrication, and it is the highest-return edit available — a selected-work block is one way to make room for it near the top of the page.

A weak line justifies nothing. Do not restructure a document around a sentence with unknown authorship, and do not delete a term from your skills list because one posting omitted it.

Frequency across your corpus is the only thing that justifies a structural change — cutting a section, learning something, repositioning yourself as a different kind of engineer. Structural changes should have a denominator behind them.

What none of it is evidence of

A requirements list is not evidence about what happens to your application after you submit it. It is not evidence of the team’s technical judgement — a well-written posting proves you have found a competent writer, which is a different person. It is not evidence that the stated stack is what you will work on in your first year, which is frequently whatever is broken.

And it is not a specification you are being graded against. It is a claim about a job, made by somebody who is not doing that job, assembled partly from a file. Read frequency as data. Read any single line as a rumour that happens to have an author.