Hard Skills for a Resume: How to List Them

Published · 15 min read

A hard skill is one somebody can test you on, so write it the way it would be tested: the real product name, the specific dialect or module in brackets, and nothing you could not open today. "SQL (PostgreSQL, BigQuery)" is a hard skill. "Good with data" is not.

The rest of this page is about the details that decide whether an entry works: how to phrase a level, how old is too old, whether to include version numbers, and where certifications actually belong.

What makes a skill hard rather than soft?

Testability. A hard skill has a right answer somewhere. Languages, frameworks, machines, clinical procedures, accounting standards, CAD packages, forklifts, spoken languages, certifications with a registry behind them.

That is what makes the skills section worth having at all. It is a fast, scannable list of claims that can be checked, which is exactly why the unfalsifiable ones do not belong in it — the argument for moving those into your experience section is in our companion piece at /blog/soft-skills-for-a-resume.

How should you write a single entry?

Three parts, in this order: the group label, the product name, and the specifics in brackets. The group label helps a reader find the row they care about. The product name is the match. The brackets are the proof that you have been past the surface of it.

A monospaced example line reads 'Data: SQL (PostgreSQL, BigQuery), Python (pandas)'. Below it, three rows break it apart. 'Data:' is labelled the group label, copied from the heading the job ad uses so the reader finds it without hunting. 'SQL' is labelled the product name, spelled the way the industry spells it, not 'databases' or 'sql basics'. '(PostgreSQL, BigQuery)' is labelled the specifics in brackets, the dialects and libraries you could be questioned on for ten minutes. A black footer bar reads: never in this line, star ratings, progress bars, percentages, software logos, or a tool you could not open today.
The three parts of a hard skill entry, and what never belongs in one.

Spell things the way the field spells them. "PostgreSQL", not "postgres". "Microsoft Excel", not "MS excel". "Adobe InDesign", not "indesign". This is not pedantry — an inconsistent spelling is the first sign to a specialist reader that you learned the tool's name from a job ad rather than from using it.

Tip: The brackets are where a generic skill becomes a specific one. "Excel" says nothing you did not already assume. "Excel (Power Query, pivot tables, XLOOKUP)" describes an actual capability, and it gives an interviewer something to ask about that you will enjoy answering.

Ten entries, weak and rewritten

The rule is easier to see applied than described. Weak version first in each pair; all are example resume entries.

Every rewrite is the same move. The weak version names the category, which the reader already knew was relevant because they wrote the ad. The strong version names the thing, which they did not know until you told them.

How is the line read on the other end?

By two different readers with opposite habits, which is why the rules can feel contradictory.

The first is software, where the file is turned into text and searched for terms. It has no opinion about you and no ability to infer that "postgres db" and "PostgreSQL" are the same thing. It rewards exact, ordinary spelling and it loses anything that is not text — an icon, a chart, a rating bar, a name that exists only inside an image.

The second is a person who may know the field better than you do. They are not searching, they are sampling: they take one entry, form a view about whether you have used it properly, and apply that view to everything else on the page. That is why the bracket contents matter out of proportion to their length. An entry that shows depth makes the reader generous about the rest of the list; an entry that shows a course rather than a job makes them suspicious of it.

Write for both and there is no conflict. Plain text, exact names, one layer of specifics. The software finds the term and the specialist finds the evidence in the same six words.

Should you state a proficiency level?

Only when the level is genuinely load-bearing and only in words. Spoken languages are the clear case, because there is shared vocabulary for it: native, fluent, working proficiency, basic. Everyone reading understands roughly what those mean.

For software there is no shared scale, so a level is either noise or a liability. "Python — intermediate" invites the question of what intermediate means and gives you no good way to answer. If you want to signal depth, do it with the brackets or with a bullet in your experience, not with a label.

Rating widgets are worse than useless. Four stars out of five, a bar filled to eighty per cent, a circle in a template — none of them have units, and all of them are drawn as graphics, which means software reading your file may take away nothing at all where a skill used to be.

How recent does a hard skill have to be?

The honest test is not the calendar, it is the desk. Could you sit down at it today and do useful work within an hour? If yes, it stays regardless of when you last used it. If you would need a weekend of relearning before you were safe, it does not belong in a list that reads as current.

Where a skill matters but has gone cold, keep it in the experience entry where you used it and let the dates speak for themselves. That is accurate and it still surfaces the keyword, without implying you could be dropped into it on Monday.

Do version numbers belong on a resume?

Almost never in the skills section. Versions date your resume fast, and for most tools the difference between releases is not what the employer is hiring for.

The exceptions are the fields where the version is the job. Regulated environments, industrial control, ERP migrations and long-lived enterprise platforms are the usual cases: if the ad names a version, mirror the ad. Otherwise write the product and stop.

Can you list a skill you are still learning?

Not in the skills section, because that section reads as a set of things you can already do. Putting a half-learned tool in it is the single easiest way to lose an interview, since it is precisely the entry a curious interviewer picks.

There are two honest homes for it. A short "Currently learning" line at the end of the section, clearly separated. Or a project entry: what you built with it, what it does, and where the code or the output lives. The project is stronger, because it converts the claim into a thing that exists.

Do certifications go in the skills section?

Give them their own section when you have more than one or two, because they carry information a skill entry cannot: the issuing body, the date, and often an expiry or a registration number a recruiter can verify.

Which hard skills transfer when you change industry?

More than most people list. The tools that appear across sectors are worth keeping even when the job title changes completely, because they are the bridge that makes a career change look like a continuation rather than a restart.

What if your hard skills are self-taught?

List them exactly as you would list any other, with no apology and no note about how you learned them. Where you acquired a skill is not what the skills section is for. It is a list of what you can do.

The place a self-taught background needs support is evidence, since you have no job title backing the claim. Supply it with something that exists: a repository, a live site, a template pack, a dashboard you built for a club, a spreadsheet a small business still runs on. One artefact with a link is worth more than a row of course names, because it is the thing an interviewer can look at before they speak to you.

Courses and certificates are worth listing when they are recognised in the field, and worth compressing when they are not. Six similar online course names in a row reads as a period of study rather than a capability.

What if your last role does not match the target?

Then the skills section carries more of the argument than usual, and its position on the page should move up to match. The point of the block in that case is to establish, before the reader reaches a job title that will confuse them, that the specific capabilities the ad asked for are already present.

Do that by leading with the overlap. If you are moving from care coordination into operations, the first group is the systems and process work both jobs share, not the clinical entries that only made sense in the old field. The clinical entries stay lower down, where they are context rather than headline.

The follow-up question people ask here is whether they should drop the old field entirely. No — a resume with a visible past reads as a person, and a resume with a scrubbed one reads as a gap. Reorder rather than delete.

What if you are coming back after a break?

Split the list mentally into what is still current and what has gone cold, then be explicit rather than vague. A dated entry is stronger than an undated one that a reader is quietly discounting anyway: "Salesforce Service Cloud (2018-2022)" answers the question before it is asked.

If you refreshed something during the break — a certificate renewal, a course, a small project — that goes in as the current version of the skill and the old one becomes history. This is the one case where a short "Recently refreshed" grouping earns its line, because it is answering an obvious doubt with a specific fact.

The hard skills that are costing you a line

The same person, two different job ads

Example lines for one candidate applying to two roles. For a reporting analyst ad asking for SQL, Power BI and stakeholder work: "Data: SQL (PostgreSQL, BigQuery), Python (pandas), Excel (Power Query). Reporting: Power BI, Looker Studio, GA4."

For an operations ad at the same seniority asking for process and systems: "Systems: NetSuite, Excel (Power Query, pivot tables), SQL. Process: month-end close, stock reconciliation, supplier onboarding, GDPR record keeping."

Same person, same history, nothing invented. What changed is which true things were promoted to the top of the list, and which words they were written in. That is the whole exercise.

The check before you send it

Get the hard skills right and the section does real work: it is the fastest part of the page to read and the easiest part to believe. For how to choose which skills make the list in the first place, and how the section is formatted and placed, the main guide is at /blog/skills-to-put-on-a-resume, and the other half of the list is covered at /blog/soft-skills-for-a-resume.

Build a resume free · All articles