# The Role Demand Tally, 30 Unique Postings Coded to a Base Resume Order

*In about three and a half hours, turn 30 deduplicated postings for one role into a ranked demand table and a base resume ordered by it, with every gap logged.*

- Canonical URL: https://www.refolk.ai/candidates/guides/role-demand-posting-tally
- Pillar: Reading the market
- Format: Playbook
- Published: 2026-11-04
- Last reviewed: 2026-11-04
- Reading time: 22 min
- Keywords: how to analyze job postings for resume skills, most common requirements across job descriptions for my role, compare multiple job descriptions spreadsheet, required vs preferred qualifications across postings, which keywords to put on base resume, what skills do employers want for my target job

## Key takeaways

- At 10 postings, an item that 7 of them ask for has a 95% interval of roughly 40% to 89%, so 30 unique postings is the smallest sample where a 70% share reliably means most of the market.
- In Refolk's index, only 60% of a US "Data Analyst" title-search sample held that exact title, rising to 76% when SQL was also required, so search postings on title plus one core requirement.
- Only 19.7% of US Data Analyst profiles in Refolk's index list SQL as a skill, so a skills block copied from peers' profiles inherits their omissions and should be ordered from the posting tally instead.
- An item's demand share is the number of postings that ask for it at least once divided by the sample size, tallied separately for required and preferred lines, never the raw count of mentions.
- A LinkedIn screening-question study found recruiters do not screen on trivial listed requirements in more than 98% of cases, so one employer marking an item required does not make it a must-show item.
- O*NET's occupation-level In Demand flags covered 285 occupations in release 31.0, down from 495 in release 30.x, so an empty In Demand list is no evidence against your own tally.

This guide is for a job seeker who has already picked one target role and now needs to know what that role's postings ask for across many employers, not what one posting happened to say. In one working session of roughly three to three and a half hours, it takes you from about 45 raw listings to 30 unique postings coded line by line as required, preferred, or responsibility, then to a ranked demand table and a base resume ordered by it. Every gap gets logged as close, reframe, or ignore before you tailor anything.

## What a posting tally gives you that one job description cannot

A posting tally gives you the share of a role's market that asks for each requirement, which is the only sound basis for deciding what your base resume leads with. One job description tells you what one hiring team wrote on one day, quirks included.

Most public advice on how to analyze job postings for resume skills stops short of that. One university career-center handout asks for at least 6 job postings and flags terms that "show up in all of the job postings". Another guide says running the tally across 5 to 10 listings reveals the truly non-negotiable requirements. Single-posting keyword scanners lean the wrong way: a typical job description yields 15 to 25 meaningful keywords once generic phrases and duplicates are removed, and the scanner weights all of them equally. You end up with a per-posting checklist, not a read of the most common requirements across job descriptions for your role.

Four terms, used throughout:

- **Base resume**: the master version you keep and tailor from for each application. This guide sets its order.
- **Requirement line**: one stated qualification in a posting, such as a tool, a credential, or a years-of-experience floor.
- **Share of postings**: the number of postings that ask for an item at least once, divided by the number of postings in the sample.
- **Demand table**: the ranked list of items by share of postings, kept separately for required and preferred lines.

It also helps to be clear about what the tally is not for. Outright rejection mostly comes from knockout questions the employer configures: when an applicant fails a mandatory knockout condition, Lever automatically dispositions the application. In a survey of 25 recruiters, 92% said their applicant tracking system does not auto-reject for formatting, design, or missing keywords. That sample is small, but it points the same way. Order matters in ranking and in the human read that follows. The tally's job is to put the terms the market looks for where a reader's eye lands first, not to slip past a filter.

## How many postings you need before a percentage means anything

Thirty unique postings is the smallest sample at which an item asked for by 70% of them reliably means most of the market asks for it. At 10 postings, the same 70% is compatible with a true share anywhere from about 40% to 89%.

Nobody has published a minimum sample for one job seeker acting on item-level shares. Research content analyses use samples one person cannot build: 958 job advertisements across four position types, 1,235 postings in another study, and at the small end 34 unique postings. So I calculated the uncertainty directly, using the standard Wilson score interval at 95% confidence. A Wilson interval is the range that probably contains the true market share, given what you counted and how many postings you counted it in. "pp" below means percentage points.

| Postings in sample | Item at 70% | Item at 50% | Width at 70% |
|---|---|---|---|
| 10 | 39.7% to 89.2% | 23.7% to 76.3% | 49.5 pp |
| 20 | 48.1% to 85.5% | 29.9% to 70.1% | 37.4 pp |
| 30 | 52.1% to 83.3% | 33.2% to 66.8% | 31.2 pp |

Read the bottom of each 70% range. At 20 postings, an item that 14 of them ask for could still sit below half the market, which is a coin flip. At 30, the floor clears 50%, so an item that 21 of your 30 postings ask for is a majority ask with reasonable confidence. Interval width shrinks with the square root of the sample size, which is why moving from 10 to 30 buys so much and each further posting buys progressively less for the time it costs.

Thirty is my working choice, not a published standard. It is where the 70% floor clears a coin flip and where coding still fits in one session at about 2 minutes per posting. If your role is niche and you cannot find 30 unique current postings, run the tally anyway, but treat every share as a direction rather than a ranking, and write that down next to the table.

## Building the sample: recency, spread, and deduplication

A usable sample is 30 unique requisitions for the same role at the same level, all first seen within one recency window, spread across employer sizes, with reposts and agency copies collapsed into one. Pull about 45 raw listings so you still have 30 after cleaning.

### Title drift is the first contaminant

Titles are a loose filter. In Refolk's index of professional profiles, a search for a current "Data Analyst" title in the United States returned 65,074 profiles, but in a 25-profile sample only 15 held that exact title. The rest included founders, CTOs, and VPs. Adding one skill filter cleaned the sample noticeably.

**60% - Share of a US "Data Analyst" title-search sample in Refolk's index that held the exact title**

15 of 25 profiles; adding SQL as a required skill raised the exact-title share to 76% (19 of 25).

| Search in Refolk's index | Profiles | Exact title in 25-profile sample |
|---|---|---|
| US, title only | 65,074 | 60% (15/25) |
| UK, title only | 16,419 | 84% (21/25) |
| US, title plus SQL | 12,833 | 76% (19/25) |

Each sample is 25 profiles, so the shares are indicative, not precise. The mechanism carries straight over to postings: a title-only search pulls in senior, hybrid, and adjacent roles whose requirements distort your table. Search on the title plus one requirement you already know is core, then read each posting's responsibilities and drop any that do not fit the level you are targeting.

### The recency window

I use the last 30 days. That window is my judgement, not a sourced figure. It keeps the sample current and simplifies deduplication: inside one short window, a second sighting of the same title, company, and location is almost certainly the same job. Log the date you first saw each listing.

### Spread across sources and employer sizes

Postings concentrate on a few sites. One research centre reports that nearly half of all US postings are available on just the top 5 of 62,271 unique websites it scraped. A pull from one large board will be dominated by whoever posts there most. Spread your 45 across small, mid-size, and large employers, and include company career sites, which also give you the employer's own wording for unmasking agency copies. Keep one requisition per employer so no single employer's quirks count twice.

### Deduplication rules

The best documented method comes from a commercial postings aggregator: match the normalized job title, company, and location, and treat a re-sighting within a fixed window after the first posting as a duplicate. A research centre reports the aggregator claims this catches about 80% of duplicate postings. If a professional pipeline misses roughly one in five, a manual pass needs extra rules:

1. Same normalized title, company, and location inside your window: one posting.
2. Same or near-identical requirements under a different poster name: one posting. Agency mirrors usually reword lightly, so compare the requirements list, not the opening paragraph.
3. Agency listing that matches a career-site listing: keep the career-site version.
4. Same employer and same role in several cities: keep one.
5. Matching visible requisition numbers: one posting. No published procedure covers requisition-ID or text-hash matching for individuals, so use this only as a tiebreaker.

Done looks like 30 rows, each a different employer's requisition, each with a source and a date.

## Coding required vs preferred qualifications across postings

Coding means tagging every line of every posting as R (required), P (preferred), or D (duty, meaning responsibility text), then normalizing the wording so the same item counts once across postings. This is the step that turns 30 documents into data you can compare in one spreadsheet.

Postings rarely make it easy. No published study gives the share of postings that separate required and preferred into different sections; one practitioner says few clearly do, without giving a count. Use the posting's labels where they exist. Where they do not, apply that practitioner's heuristic: "specific and technical leans required; broad and soft leans preferred". Mark the tag as inferred, so you can later check whether inferred lines are pushing items up the table.

Three conventions keep the coding honest:

- **Normalize items.** "Writing SQL queries", "advanced SQL", and "SQL" are one item: SQL. Keep the original line text in its own column so you can audit every merge.
- **Code the lowest education bar as required.** A LinkedIn study of screening questions found recruiters usually screen applicants on the lowest education requirement only. If a posting says a bachelor's is required and a master's preferred, the bachelor's is R and the master's is P.
- **Code experience as its own items.** In a SHRM survey, recruiters rated years of experience (84%) and type of experience (83%) as important in the initial review. Record the years floor and the experience type as separate items.

Responsibility lines are not counted word by word. File each under a theme, such as reporting to business stakeholders or building data pipelines, and rank themes by share of postings the same way. Themes set the verbs and order of your bullets; required and preferred items set the summary and skills block.

**Posting coding sheet, one row per line**

```
posting_id,employer,size_band,source,date_seen,line_text,section_label,tag,inferred,item,theme
P01,<employer>,<small|mid|large>,<board|career site>,<date>,"<exact line from posting>",Requirements,R,no,SQL,
P01,<employer>,<small|mid|large>,<board|career site>,<date>,"<exact line from posting>",none,P,yes,Power BI,
P01,<employer>,<small|mid|large>,<board|career site>,<date>,"<exact line from posting>",Responsibilities,D,no,,Reporting to business stakeholders
```

*Paste the header into a spreadsheet; give each unique requisition one posting_id, and leave theme blank on R and P rows.*

> **Watch out:** Required on the page is not required at the screen
>
> A LinkedIn screening-question study found that for trivial listed requirements, in more than 98% of cases recruiters do not screen applicants on them. An item one employer marks required is not a must-show item until many employers require it.

## The three-hour tally, step by step

The full procedure runs in eight steps and takes about three and a half hours of focused work, most of it coding. The time estimates are mine; no source documents a session length.

#### From 45 raw listings to an ordered base resume

1. **Pick the role and its O*NET occupation** - Find the matching occupation on O*NET OnLine and save its Software Skills rows with their In Demand flags, plus the occupation code. About 15 minutes.
2. **Collect about 45 candidate postings** - Pull listings first seen in the last 30 days, searching title plus one core requirement, across employer sizes and company career sites. Log each URL with source and date, about 40 minutes.
3. **Deduplicate down to 30 unique requisitions** - Collapse shared title, company, and location, agency mirrors, and near-identical text, keeping one requisition per employer and dropping off-level postings. About 20 minutes.
4. **Code every line R, P, or D** - Tag requirement lines R or P from the posting's labels or the specific-versus-broad heuristic, and file duties under themes. About 60 minutes, roughly 2 minutes per posting.
5. **Tally share of postings and rank** - Count postings that ask for each item at least once, separately for R and P, rank themes the same way, and assign bands. About 20 minutes.
6. **Cross-check the top tools against O*NET** - Compare top-ranked tools with the In Demand flags and write a note for every disagreement. About 10 minutes.
7. **Reorder the base resume by the table** - Put the exact title and provable Lead items in the summary, open each role with its highest-ranked provable item, and order skills by share. About 30 minutes.
8. **Log every gap as close, reframe, or ignore** - Record a call and a concrete action for every Lead or Support item you lack or cannot prove. About 10 minutes.

Sources disagree on the order. The career-center handouts go straight from collecting postings to writing the resume, with no deduplication or coding step. I keep both, because almost every failure mode later in this guide enters through one of those two skipped steps.

## Demand bands and the O*NET cross-check

Demand bands sort each item by its share of postings into Lead, Support, or Optional, and the O*NET cross-check tests your top tools against a much larger public count of the same occupation's postings. Neither is a published standard; both are checks on your own sample.

> **Rule:** Count postings, not mentions
>
> An item's share is the number of postings that ask for it at least once, divided by 30. A posting that names SQL four times counts once, and R and P shares are tallied in separate columns.

Rank by required share first, then by preferred share. An item that many postings require sits above one that the same number of postings merely prefer.

| Band | Share of 30 postings | Where it goes |
|---|---|---|
| Lead | 70% or more (21+) | Summary and first bullets |
| Support | 30% to 69% (9 to 20) | Skills block, later bullets |
| Optional | Under 30% (8 or fewer) | Only if already true |

These cutoffs are not established publicly; they are my working bands. The interval table supports them at 30 postings: a 70% item has a floor of 52.1%, so a Lead item is a majority ask, and a 50% item ranges from 33.2% to 66.8%, which stays inside the Support band at both ends. Items within a posting or two of a band line are genuinely ambiguous. Let your evidence decide which side they fall on, not the decimal.

### What the O*NET flags measure

O*NET's Software Skills file, which was named Technology Skills until release 30.3, carries two flags. In O*NET's words: "The 'Hot Technology' column indicates requirements frequently included across all employer job postings. The 'In Demand' column indicates requirements frequently included in employer job postings for the particular occupation." In Demand is the one to check against, because it is specific to the occupation. The method searches US postings within a designated 12-month period and requires at least 50 unique postings mentioning a term. The window behind the current release is not published, and the In Demand column itself only arrived in release 27.1.

| Release | Hot technologies | In Demand linkages | Occupations with In Demand |
|---|---|---|---|
| 29.2 | 170 | 2,300+ | 487 |
| 30.x | 171 | 2,400+ | 495 |
| 31.0 | 176 | 2,400+ | 285 |

Coverage moves between releases. From 30.x to 31.0, occupations with In Demand linkages fell from 495 to 285 while hot technologies rose to 176. The reason is not documented. The relabel to "Employer-Based" designations may be involved, but that is unverified.

### Reading a disagreement

- **High in your tally, not flagged in O*NET.** The item may be newer than O*NET's posting window or specific to your market. Keep it and note why.
- **Flagged in O*NET, low in your tally.** Check your sample for title drift or a skew toward one employer size. If the sample is clean, your tally is the better read of the postings you will actually apply to.
- **Both agree.** Highest confidence; these items anchor the summary.

> **Note:** An empty In Demand list proves nothing
>
> Only 285 occupations had In Demand linkages in release 31.0, and every flag is built from US postings. If your occupation has no list, or you are searching outside the US, record the cross-check as not applicable and rely on your tally.

## Turning the ranked table into a base resume order

Your base resume's reading order should follow the demand table: Lead items you can prove go into the summary and the first bullet of each role, Support items fill the skills block and later bullets, and Optional items appear only if they are already true. This is the answer to which keywords to put on a base resume: the ones most postings ask for, in the slots a reader sees first.

Where the eye goes first sets the priority of those slots. The Ladders' eye-tracking study put the initial decision at 7.4 seconds and found recruiters' eyes spent more time on job titles than on any other element of the resume. Treat that as a description of the triage skim, not the whole read: the original study had only 30 recruiters, the updated version gives no number, and in a separate ResumeGo survey 47% said the overall review takes 30 seconds to a minute.

#### Resume slots, in the order a reader meets them

1. **Job titles** - The element eyes linger on longest; keep them as held, and use the market's exact title in the summary's opening line
2. **Summary** - The Lead items you can prove, in the normalized wording the postings use
3. **First bullet per role** - The highest-ranked item or responsibility theme you can evidence in that specific job
4. **Skills block** - Remaining Lead items, then Support items, ordered by share of postings

*Fill each slot from the top of the demand table down, and only with items you can prove in that slot.*

Placement rules:

1. Open the summary with the market's exact title for the role. The index data above shows how much titles drift; the postings' own title is the one recruiters search for.
2. Name the Lead items you can prove in the summary, using the normalized item names from your coding sheet.
3. Rewrite the first bullet of each role so it carries the highest-ranked item or theme you actually did in that job. Reorder, do not invent.
4. Order the skills block by share of postings, Lead first.
5. Back every Lead item with at least one bullet that shows evidence of it.
6. Leave past job titles as held. Titles are facts of record that a background check can compare.

Do not shortcut this by copying what peers list. Profiles under-state table-stakes skills.

**19.7% - US "Data Analyst" profiles in Refolk's index that list SQL as a skill**

12,833 of 65,074; the likely reason is that people leave out skills they assume are obvious, so a skills block modeled on peers inherits the omission.

Once the order is set, [Refolk](/candidates) can hold it for you: it writes the base resume from your own history and then tailors it to each posting you apply to, so the market-level order you built here becomes the starting point of every per-posting version instead of being rebuilt by hand each time.

### Logging every gap

Every Lead or Support item you lack, or cannot yet prove, gets one of three calls. **Close** means you can acquire and demonstrate it during your search, through a course, a project, or a work assignment. **Reframe** means you already have the substance under different words, so you rewrite the bullet in the market's wording, truthfully. **Ignore** means the item is Optional or the cost of closing it outweighs its share.

#### Gap call by demand and evidence

Horizontal axis runs from Low share of postings to High share of postings. Vertical axis runs from No evidence yet to Provable evidence.

| Quadrant | What it means |
| --- | --- |
| Provable, low demand | Keep in the skills block, low on the page |
| Provable, high demand | Lead with it in the summary and first bullets |
| No evidence, low demand | Ignore and record why |
| No evidence, high demand | Close or reframe, with a dated action |

*Demand share tells you how much an item matters; your evidence tells you whether you are allowed to lead with it.*

**Demand table with gap log**

```
item | R postings (of 30) | P postings (of 30) | band | my evidence (role, bullet) | gap call | action and target date
SQL | __ | __ | Lead / Support / Optional | __ | close / reframe / ignore | __
Power BI | __ | __ | Lead / Support / Optional | __ | close / reframe / ignore | __
<theme> | D: __ of 30 | n/a | Lead / Support / Optional | __ | close / reframe / ignore | __
```

*One row per item or theme from the coding sheet; sort by R count, then P count, and fill the last three columns only for items you lack or cannot yet prove.*

When you start applying, Refolk scores how well you actually fit each posting, which is the per-posting check on whether a gap you logged as ignore matters for that particular employer.

> A tally ranks what the market asks for. Your evidence decides what you are allowed to lead with.

## How the tally goes wrong

The tally fails in predictable ways, and each failure produces a confident-looking table that ranks the wrong things. These are the seven I check for, with what each looks like when the table lies.

1. **Sampling by title only.** What it looks like: leadership, budget, or architecture items near the top of an individual-contributor role's table. In Refolk's index, only 60% of a US "Data Analyst" title search held the exact title; the rest included founders, CTOs, and VPs. Postings drift the same way. Check: reread every posting's responsibilities, drop off-level ones, and replace them.
2. **Duplicates that are not exact copies.** Agency mirrors reword the text, so a text-only match misses them. The false positive is one employer counted twice, which inflates its quirky asks into the Support or even the Lead band. Even the aggregator method catches only about 80%. Check: match title, company, and location, then compare requirement lists rather than introductions.
3. **Coding "required" literally.** The false positive is an obsolete item such as Internet Explorer ranked as must-show because a posting listed it under requirements. The more than 98% non-screening finding for trivial requirements is the reason not to trust a single R tag. Check: does the item appear as R across many employers, or in one posting?
4. **Acting on a small sample.** At 10 postings, a 70% item's interval reaches down to 39.7%. Rankings built on that reshuffle as soon as you add postings. Check: promote an item to Lead only if its interval floor clears your cutoff; at 30 postings that means 21 or more.
5. **Reading an empty O*NET list as disagreement.** Only 285 occupations had In Demand linkages in release 31.0, and all flags come from US postings. Check: an empty list is no evidence either way; record it as not applicable.
6. **Stuffing the skills block.** Claims that Workday and Greenhouse flag unnatural keyword density are unverified against vendor documentation, and a secondary summary of Greenhouse documentation describes its Talent Matching as assistive, not auto-advancing or auto-rejecting anyone. The real cost is the human read that follows any match: a skill with no supporting bullet reads as padding. Check: every Lead item appears in at least one bullet with evidence.
7. **Overweighting the first skim.** The 7.4-second figure describes triage and comes from a disputed sample, and survey respondents put the overall review at 30 seconds to a minute far more often. Optimizing only the top third of the page leaves the bullets that carry the decision in random order. Check: apply the table's order to every role on the page, not just the first.

## Keeping the tally current

A tally is a snapshot of postings inside one window, so it goes stale as the window moves. Refresh it on a trigger, not on a feeling.

Re-run the full tally when you change target role or level, because the sample rules no longer hold. While you are still applying to the same role, refresh it by replacing postings that have aged out of your recency window with new unique requisitions and recounting; the normalized item list and coding sheet make the second pass much faster than the first. Compare the new Lead band with the old one. If an item crosses a band line, move it on the resume; if nothing moves, your base order stands.

Recheck the O*NET side after its updates. O*NET updates its database quarterly, with the primary update in the third quarter of each year, and coverage can shift sharply between releases, as the drop from 495 to 285 occupations shows. Its own pages sometimes disagree, too: for release 31.0, the database page says 208 occupations were updated and the What's New page says 218. Read the release notes and confirm your occupation's In Demand list directly rather than relying on a summary.

#### Before you call the base resume done

- [ ] The sample holds 30 postings, each a different employer's unique requisition, all first seen within the recency window.
- [ ] Every posting fits the target level on its responsibilities, not just its title.
- [ ] Every line in the coding sheet carries R, P, or D, and every inferred tag is flagged.
- [ ] Shares count postings, not mentions, with R and P tallied in separate columns.
- [ ] Every item in the Lead band is asked for by at least 21 of the 30 postings.
- [ ] Each disagreement with the O*NET In Demand list has a written note, or the cross-check is marked not applicable.
- [ ] The summary opens with the market's exact title and names only Lead items you can prove.
- [ ] The first bullet of each role carries the highest-ranked item or theme you can evidence in that job.
- [ ] Every item in the skills block is backed by at least one bullet.
- [ ] Every Lead and Support item you lack is logged as close, reframe, or ignore with a dated action.

## Frequently asked questions

### How many job postings should I analyze before rewriting my resume?

Aim for 30 unique postings for one role at one level. At that size, an item asked for by 70% of postings has a 95% interval of about 52% to 83%, so it is safely a majority ask. At 10 postings the same 70% could really be as low as about 40%, which is why the common advice to read 5 to 10 postings produces rankings that shift when you add more. No published minimum exists; 30 is a working choice that fits one session.

### Should preferred qualifications go on my base resume?

Yes, when you can prove them and enough postings ask for them. Tally preferred lines separately from required ones, then place a preferred item by its share of postings: a widely preferred item belongs in the skills block and later bullets, while one preferred by a handful of employers only appears if it is already true. Never let a preferred item displace a widely required one from the summary or first bullets.

### Can I just use a keyword scanner on one job description instead?

A single-posting scanner is fine for tailoring one application, but it cannot tell you what the role's market wants. A typical job description yields 15 to 25 meaningful keywords, and the scanner weights them all equally, including that employer's quirks. The tally sits upstream: it sets the base resume's order from 30 employers, and per-posting tailoring then adjusts that base for each application.

### What if my occupation has no In Demand flags in O*NET?

Skip the cross-check and rely on your tally. Only 285 occupations had In Demand linkages in O*NET release 31.0, down from 495 in the previous release, so an empty list says nothing about your role's demand. The flags also come from US postings only. If you are searching outside the US, treat any O*NET agreement as a weak confirmation rather than a test.

### How often should I redo the posting tally?

Redo it whenever you change target role or level, and refresh it while you are still applying by swapping out postings that have aged past your recency window and recounting. The second run is faster because the normalized item list and coding sheet already exist. Also recheck the O*NET flags after its updates, which run quarterly with the main update in the third quarter of each year.

### Will repeating keywords many times help my resume rank higher?

There is no vendor documentation showing that density helps, and claims that applicant tracking systems penalize it are also unverified. What is clear is that a human reads the resume after any match, and a skill listed with no supporting bullet reads as padding. Put each top-ranked item in the summary or skills block once, then prove it in at least one bullet with evidence.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/candidates/guides/role-demand-posting-tally*