How to read a job description (and find the keywords that matter)

Most people read a job description once, decide "yeah, close enough," and hit apply. Then they wonder why they never hear back.

I've changed industries three times — heavy civil, into project management, into robotics — and every one of those jumps started with a stack of job descriptions for work I'd never officially held. I couldn't afford to skim. When you're the candidate who doesn't obviously fit, the job description is the only map you get, and reading it well is the difference between "worth a tailored application" and "20 minutes I'll never see again."

Here's how to actually read one. Not the résumé edits that come after — I wrote those up separately in how to tailor your résumé to a job description. This is the step before that: understanding what the posting is really asking for, and pulling the words that decide whether a human ever sees your résumé.

A job description is two documents wearing one headline

Almost every posting is written, or stitched together, by two people who want different things.

• The hiring manager wrote the parts about the actual work — the responsibilities, the problems the team is drowning in, the "day in the life." This is where the real job lives.
• HR or a recruiter wrote (or pasted) the requirements block, the qualifications, and the boilerplate. This is the part a computer and a busy recruiter will filter on.

You need both. The hiring-manager half tells you whether you'd want the job and can do it. The recruiter half tells you the exact words that have to be on your résumé for anyone to find it. Read only the first and you write a heartfelt application that gets auto-filtered. Read only the second and you keyword-stuff your way into an interview you're not right for.

Read it twice, on purpose

First pass — for the job. Ignore the keywords. Ask three questions: What problem is this team hiring to solve? What would I actually do on a Tuesday? Do I want this? If the honest answer to the last one is no, stop here. You've saved yourself the tailoring time.

Second pass — for the words. Now go line by line with a highlighter (or a scratch doc) and pull out the language you'll need to mirror later. What you're building is a list, and it splits into two piles.

Requirements vs. wishes: the language tells you which is which

Postings almost never label what's a hard gate and what's a nice-to-have — but the phrasing gives it away every time.

Hard requirements sound like a filter:

• "Required," "must have," "minimum qualifications"
• A specific number: "5+ years," "3 years managing a team"
• A named license or certification stated flatly
• "This role requires X"

Wishes sound like a tiebreaker:

• "Preferred," "a plus," "bonus," "nice to have"
• "Familiarity with," "exposure to," "ideally"
• Anything under a heading literally called Preferred Qualifications

This split matters because of one hard truth: the "required" list is mostly not required. A widely-cited internal finding at Hewlett-Packard, repeated for years since, was that men applied when they met about 60% of the listed qualifications and women tended to wait until 100%. The lesson isn't about gender — it's that the people writing these lists pad them, and the people who get hired treat the requirements as a strong preference, not a locked door. If you clear the genuine must-haves (the certification, the years in the actual function) and most of the rest, you apply. I wrote more on that call in how to apply for a job you're not fully qualified for.

Finding the keywords that actually matter

Not every noun in a posting is a keyword worth chasing. Here's how to tell the signal from the filler.

Repetition is the tell. If a skill shows up in the summary, again in the responsibilities, and a third time in the requirements, the employer is telling you plainly what they care about. A word that appears once in a throwaway bullet is not what gets filtered on. Rank your keyword list by how many times each term appears.

Grab the exact phrasing, not your translation of it. This is where good candidates quietly lose. If the posting says "project controls" and your résumé says "schedule and cost tracking," a recruiter searching their system for "project controls" will never find you — even though you've done exactly that work. Same for "stakeholder management" vs. "worked with clients." Copy their words down verbatim; you'll decide later which ones are honestly yours.

Pull these four every time:

1. Hard skills and tools, by their exact names — "Postgres," not "databases"; "Bluebeam," not "markup software."
2. Certifications and licenses, spelled exactly as written, acronym and full form both ("Project Management Professional (PMP)"). You don't know which version a recruiter will search.
3. The job title itself, plus close variants. Titles are one of the most common filter fields.
4. Domain phrases the posting leans on — the two or three phrases that clearly belong to this company's world.

Ignore the boilerplate. "Excellent communication skills," "team player," "fast-paced environment" — nobody searches for these and nobody's impressed by them. They're not keywords. They're wallpaper.

The signals hiding between the lines

A few things a job description tells you if you're paying attention:

• Scope and seniority. "Own," "lead," "define the strategy" is a senior role even if the title is modest. "Support," "assist," "under the direction of" is not. Match your framing to the altitude the posting is written at.
• What they're really short on. The responsibility that's described in three sentences while everything else gets one is the fire they're hiring you to put out. Speak to it directly in your summary.
• The honest yellow flags. "Wears many hats," "thrives in ambiguity," "we move fast" can mean a great scrappy team — or an understaffed one with no process. Not a reason to skip it, just a question to ask in the interview instead of finding out on day 30.

What to do with the list

Once you've read both halves and built a keyword list ranked by repetition, you're ready to tailor — mirror the true keywords into your résumé, reorder your bullets so the relevant ones lead, and cut what doesn't serve this application. That's a whole process on its own, and it's in the tailoring guide.

The one rule that carries across both steps: only claim what's true. Reading a job description well means you know exactly which of their keywords you can honestly stand behind — and which you can't. Mirroring a tool you've never touched doesn't get you a job; it gets you a first interview that falls apart in ten minutes. Tailoring is translation, never invention.

The mechanical parts of this — checking which of a posting's keywords your résumé already covers and which are missing — are exactly what software is good at, and it's the loop I built ResumAI to run: paste a job description, and it scores your résumé against that specific posting, shows you the covered and missing keywords, and drafts a tailored version for you to edit and approve. Because a résumé is personal data, it masks your name, phone, email, and links before anything reaches an AI model, and on the bring-your-own-key plan the tailoring call goes straight from your browser to your own AI provider. The judgment calls — which keywords are honestly yours, whether you even want the job — stay with you. Those were always the part that mattered.

Read it twice. Split the requirements from the wishes. Rank the keywords by repetition. Keep only what's true. Do that before you touch your résumé, and the tailoring takes half the time and lands twice as often.