How to Read a Job Posting Before You Write

The reason a letter comes out generic is almost never the writing. It’s that the writer read the posting the way you read a menu — scanning for whether they qualify — and then had nothing specific to say because they never looked for anything specific.

Read it once as a candidate, then read it again as an editor looking for evidence. The second pass takes four minutes and produces the whole letter.

Postings are written by two different people

Nearly every posting is a composite. There’s the HR-authored scaffolding — the boilerplate about culture, the benefits, the standard requirement list, the equal-opportunity paragraph — and there’s the two or three sentences the hiring manager actually dictated because they describe the problem they need solved.

Those sentences read differently. They’re more concrete, sometimes clumsier, and they often contain a slightly odd phrase that wouldn’t survive a copy edit: bringing order to fragmented data, the reporting is currently spread across four spreadsheets and a person, we need someone who can say no to stakeholders.

Find those sentences. They tell you what the job is. Everything else tells you what the company’s template is.

The four-minute pass

1. Mark every sentence that describes a problem rather than a person.

“Five years of experience with Python” describes a person. “Our test suite takes fifty minutes and nobody trusts it” describes a problem. Problems are what letters answer; person-descriptions are what resumes answer.

2. Note the order of the requirement list.

Requirement lists are rarely random. The first two or three items are usually the ones that made someone open a role. Items near the bottom are frequently aspirational — the “nice to have” list that grew because everyone in the meeting added one.

This matters because it tells you which requirement to build paragraph two around: usually the highest-placed one where you have a genuine story.

3. Look for the repeated word.

If a concept appears three times in different phrasings — stakeholders, cross-functional, alignment — someone in that organisation is currently annoyed about it. A letter that speaks to the repeated concept lands harder than one that speaks to a bullet mentioned once.

4. Note what’s conspicuously missing.

A senior title with no mention of managing anyone. A “data” role with no tools named. A posting for a rebuild with no mention of what happened to the previous version. Absences are often the most interesting thing on the page, and they’re where your closing question comes from — see the closing paragraph.

What to do with a posting that’s pure boilerplate

Some postings genuinely contain nothing. Three hundred words of template, a requirement list assembled from a library, a title, and a salary band.

Don’t invent specificity you can’t source. Instead, shift the letter’s centre of gravity from their problem to the work itself — write about how the job is actually done, which you know and the posting doesn’t say.

The posting doesn’t say much about how the reporting currently works, so I’ll describe the version of this job I’ve done and you can tell me how far off I am. At Ferrell the weekly numbers came from three systems that disagreed, and the first six weeks were entirely about establishing which one was allowed to be wrong.

That’s honest — it names the gap in the posting rather than papering over it — and it demonstrates more than a paragraph of manufactured enthusiasm would.

The company research trap

You do not need to research the company for an hour. You need one true, specific thing, and the posting is usually a better source than the website.

Website research produces the worst sentences in the genre, because a marketing page gives you nothing but adjectives, and adjectives get recycled straight into I admire your commitment to innovation. If the only research you’ve done is the About page, you’d genuinely be better off writing about the work — see answering “why this company” without flattery.

Legitimate sources of a real specific: the posting itself, the product if you’ve used it, public documentation, something you learned working in the same market, or a person you know there. Not the mission statement.

Translate their words into your evidence

Make two columns. On the left, the three problem-sentences you marked. On the right, the most concrete thing you have done that touches each one — a project, not a skill.

The right-hand column is the raw material. If a row is empty, you’re not writing about that one. If every row is empty, you’re either applying for a job you can’t do or you’re describing your own work too abstractly, and the second is more common than people expect.

Then pick one row. One. The letter’s job is to make one match undeniable, not to survey your suitability across five dimensions.

Their vocabulary, not their phrasing

Use the reader’s terms for things. If they call it a “customer health score” and you called it a “churn model,” say customer health score once so the mapping is obvious. If they say “clients” and you say “accounts,” use theirs.

This is not keyword stuffing and it isn’t for a machine — it’s so a human doesn’t have to do the translation. But borrow the vocabulary, not the sentences. Quoting a whole phrase from the posting back at them reads like a mail merge, and there’s a particular flavour of letter that’s just the requirement list re-parsed as prose. Nobody enjoys reading their own bullets returned with “I have extensive experience in” bolted on the front.

What you should have before you type

By the end of the read, four things:

1. The one requirement you’ll answer.
2. The concrete story that answers it.
3. One thing you noticed that isn’t in the posting — the absence, the odd phrase, the repeated worry.
4. One question you’d genuinely want answered.

That’s a letter. The writing after this point is mostly transcription, and it fits straight into the four-paragraph structure without any further decisions.