The Resume Skills Section, Built From a Master List to a Grouped Block

This guide builds one resume skills section from start to finish: from a raw dump of everything you know down to a finished, grouped, posting-ordered block that an applicant tracking system parses cleanly. It is for a job seeker rewriting their resume who wants a section they can defend, not a menu of skills to maybe include. By the end you will have decided the count, the category labels, the order, and the formatting, and you will have tested that the block survives the parser.

An applicant tracking system, or ATS, is the software an employer uses to parse and score resumes before a human reads them. Most of the decisions below exist because that software reads differently than a person does. A recruiter sees a tidy sidebar with skill bars. The parser sees blanks and merged columns. This guide treats the skills section as a build with real failure points, not a decoration.

Why the skills section is the most fragile part of your resume

The skills section fails parsing more dramatically than any other block, because it is exactly where templates park the visual tricks that parsers cannot read. Overall resume parse accuracy drops modestly under a multi-column layout, but skills-section extraction collapses far faster.

The numbers make the gap plain. In a cited study, overall parse accuracy fell from around 93% to 86% when a resume went multi-column, a mild dip. But skills-section extraction over the same shift fell from 65% to 46%. Sidebars, two-column splits, and graphic rating bars all tend to live in the skills block, so the section carries most of the formatting risk on the whole page.

That is the frame for everything here. You are not choosing fonts. You are making a block that a linear text parser reads correctly, in the order you intend, with every skill counted once.

A note on the evidence. The parse-rate figures below come from vendor blogs and template teardowns, not peer-reviewed tests. The clearest methodology cited is the Enhancv 2025 study, which ran 25 recruiters across 10 or more systems including Workday, iCIMS, and Greenhouse, and found formatting issues cause about 23% of parsing failures while the other 77% are content problems. So formatting matters, but it is not the whole battle. Getting the right skills in defensible order matters more than any layout choice.

How many skills to list on a resume

List 8 to 15 matched skills for most roles, and push to 15 to 28 only for software, data, and platform roles where the skills group naturally into categories. The count is a tradeoff, not a style preference: too few starves the keyword match, and too many trips the stuffing heuristics that downrank a resume.

Published guidance converges on this range from different directions. The table below shows where the major sources land.

Read the spread, not any single row. The low end warns that fewer than 10 skills can read as under-qualified. The high end warns that 30 or more reads as keyword stuffing. Between those guardrails, your count should be driven by how many skills you can actually defend, not by hitting a target number.

One blog asserts that Greenhouse discounts skill sections exceeding 25 unique items and that Workday flags excessive keyword density. I could not confirm either claim against those vendors' primary documentation, so treat both as unverified. The safe practice does not depend on them: cap at roughly 20 for most roles and cut your weakest matches first. That keeps you clear of the stuffing zone regardless of whether the specific vendor rule exists.

Which skills belong in the section, and which belong in bullets

Put hard, listable skills in the skills section and demonstrate soft skills in experience bullets with results. A standalone word like "communication" shows no outcome and rarely moves an ATS score on its own, so it earns nothing sitting in the list and earns a lot sitting inside a quantified bullet.

The working ratio is a hard-skill lean. Guidance recommends roughly 60% hard skills in the skills section and 40% soft, tightening to 70/30 for technical roles, with every soft skill proven through a result elsewhere. The reason is mechanical: hard-skill keywords carry almost all of the match an ATS computes, so soft skills in the list are close to dead weight at the parsing stage.

Here is the test. For each item, ask whether it is a tool, language, method, platform, or certification. If yes, it goes in the skills section. If it is a quality you would have to demonstrate, like leadership or problem-solving, move it to an experience bullet and attach a number or an outcome.

Skills-based hiring is why this split pays off. A cited NACE Job Outlook figure puts 70% of employers now using skills-based hiring, up from 65%. The more the match turns on demonstrated skills, the more a defensible, specific skills block outperforms a padded one.

The build procedure, master list to finished block

Work in order. Each step has a time box and a clear done state so you can stop when the step is complete rather than fiddling. The whole run takes roughly 80 to 90 minutes the first time and far less on later resumes once your master list exists.

A tailoring note on steps 2, 3, and 6. These three are posting-specific, which means the skills block is not a set-and-forget asset. It changes per application, even if the underlying master list does not. If you apply to many postings, tailoring the skills block by hand each time is the part that eats hours. Refolk writes your resume from your own history and tailors it to every posting you apply to, including reordering the skills block to the posting's priority, which is exactly the per-application work steps 2, 3, and 6 describe.

How to group and order the block

Group into 2 to 5 short, focused category labels, put the most role-relevant category first, and lead each line with the skills the posting names first. Ordering is not cosmetic. Parsers weight earlier list items more heavily, so matching the posting's required-first order raises your match score without adding a single new skill.

Choosing category labels

Keep labels short and tool-anchored. For a data role, something like "Languages and Querying", "BI and Visualization", and "Data Engineering" beats vague buckets. Put the category the posting cares about most at the top. If the posting leads with querying, your querying line leads your block.

Ordering within each line

Within a category, the first item should be a skill named in the posting's required section. The honesty filter still applies: if a required keyword is one you cannot defend, do not fake proficiency to win the first slot. Lead instead with the strongest required skill you genuinely hold.

Frequency data backs this ordering for data roles specifically. The table below draws on counts from Refolk's index of professional profiles.

Read it this way: in Refolk's index, a US Data Analyst is roughly 6 times more likely to list SQL than Python. That mirrors how most data-analyst postings prioritize, so leading a data-analyst skills line with SQL matches both the labor pool and the typical posting. Geography shifts the denominator but not the leader. US SQL counts run about 3.6 times the UK counts, yet SQL leads in both markets, so the ordering rule transfers across countries even as raw volumes differ.

Matching the posting's required-first order raises your match score without adding a single new skill.

Languages and Querying: SQL, Python, R
BI and Visualization: Tableau, Power BI, Looker
Data Engineering: dbt, Airflow, BigQuery
Methods: A/B testing, cohort analysis, statistical modeling

Formatting that breaks parsers, and the layout that survives

Use a single-column, plain-text block separated by commas or line breaks, and remove every visual element a parser cannot read as text. ATS software reads top to bottom, left to right in a single pass, so anything that splits the reading order or hides text inside a graphic gets dropped or scrambled.

The reported failure rates make the stakes concrete. These figures come from several vendor blogs rather than one controlled test, so read them as directional, not precise.

The pattern is clear even with noisy numbers. Single-column wins, multi-column halves your skills extraction, and skill bars extract nothing. Two offenders deserve naming because they look professional and fail quietly: the sidebar and the progress bar.

One formatting detail inflates your count without your noticing: redundant variants. Listing both "Python" and "Python Programming" can be counted as two separate skills by some parsers, fragmenting the data and padding your total toward the stuffing zone. Use one canonical name per skill.

How this goes wrong

The skills section fails in predictable ways, and most failures pass a casual eyeball check, which is why they survive to the parser or the interview. Below are the false positives to hunt for, with the test that exposes each.

• Count looks right, skills undefendable. You have 15 keyword-matched skills and can only discuss 10. Test: give a one-sentence working example for each. Cut any you cannot, because employers test this later through a mock interview or technical screen.
• Section previews clean but fails the parser. It looks tidy in Word. Test: paste into Notepad. If it jumbles, your layout is table or column based under the surface.
• Skill bars and stars show mastery to a human, nothing to the parser. They extract as blank. Test: delete every graphic rating and replace it with the plain word.
• Soft skills padded into the list. "Communication, teamwork, problem-solving" fills the block and moves no score. Test: move each to an experience bullet with a result.
• Redundant tokens inflate the count. "Python" and "Python Programming" counted twice. Test: keep one canonical name per skill.
• Ordering ignores the posting. The block is alphabetical or in personal-pride order. Test: does the first item in each group appear in the posting's required section?
• Sidebar placement. A clean-looking skills sidebar. Test: the parser may read across columns and merge a skill with a job title. Collapse to single column.
• Over-density trip. Thirty or more skills reading as stuffing. Test: cap near 20 and cut the weakest matches.

The most expensive failure is not a formatting one. It is the undefendable skill. A section that parses flawlessly but lists tools you cannot discuss gets you to an interview you then fail. The honesty filter is doing the heavy lifting here: list only what you can defend, and let the count fall where that leaves it.

Pressure-test before you call it done

Before you treat the skills block as finished, run it against the checklist below. Each item is a pass-or-fail check, not a topic to think about.

Keeping the block current across applications

The master list is the durable asset; the grouped block is disposable and rebuilt per posting. Keep your master list in a plain file and treat steps 2, 3, 5, and 6 as a short per-application pass rather than a rewrite. That is the whole maintenance model: one stable inventory, many tailored blocks.

Two things change over time and are worth re-checking rather than memorizing. First, the parse-rate figures here come from vendor blogs and will shift as parsers improve, so re-run the Notepad test on any new template rather than trusting a past result. Second, the stuffing and density thresholds are partly unverified vendor claims, so keep your cap conservative near 20 and let the defensibility filter, not a vendor rule, decide what stays.

If you want to see how a target role actually lists and orders its skills before you finalize yours, look at real profiles for that role and market. The frequency pattern you find there is your ordering evidence.

A final reframe. The skills section is not where you prove you are impressive. It is where a machine confirms you match, in a format it can read, in an order it rewards. Build it to pass that reader honestly, and the human on the other side gets a candidate they can trust rather than a wall of words to discount.