Where to Draw the Line on a Skill You Barely Know

A skills section is a list of claims, and each one invites a question. The workable line is this: list a tool if you could talk about using it for two minutes without preparing, and describe something you actually did with it. Anything below that threshold either comes off the list or gets labelled as exposure rather than skill. The reason is not modesty, it is that an unsupportable skill claim is discovered in the one setting where you cannot revise it.

Why the list gets inflated

Skills sections attract padding for structural reasons. They have no space for nuance, no verbs, and no evidence — just nouns in a row, which makes every item look equally weighted. Adding one more costs nothing at the moment of writing.

AI drafting pushes in the same direction. Ask a tool to build a skills section from your history and it will infer adjacent technologies: mention one cloud service and related ones appear, mention a language and its common frameworks follow. The inferences are reasonable as guesses and wrong as claims, and they arrive looking exactly like the items you supplied. Any skills list produced or expanded by a tool needs reading item by item against what you have actually done, in the same way every generated bullet needs checking against your own record.

The two-minute test

For each item, ask: could I speak for two minutes about using this, unprepared, and say something specific? Specific means what you built or changed with it, something that surprised you, a thing it does badly.

If yes, it belongs. If you would produce a definition and then stop, it does not — a definition is evidence you have read about a thing, and the person asking will hear the difference immediately.

This test is more useful than trying to judge your own proficiency level, because proficiency is relative and unstable while the two-minute answer either exists or does not.

Showing partial exposure honestly

Some tools genuinely belong on the page even though you would not claim skill, and the answer is to say what the relationship was. A grouped list does this without adding words:

Daily: Python, SQL, Git Used on projects: Airflow, dbt Familiar with: Kubernetes, Terraform

Three tiers, no inflated claims, and considerably more informative than one flat row. A reader looking for a Python role knows where to look; a reader who needs deep Kubernetes knowledge knows you are not it, which saves both of you a wasted conversation.

The wording of the bottom tier matters. “Familiar with” and “exposure to” are honest. “Working knowledge of” implies you can work with it. “Proficient” is a claim of competence. Pick the one that matches and do not let a tool upgrade it during a rewrite.

Better: prove the skill in the experience section

The strongest version of a skills claim is not in the skills list at all. It is a bullet in your experience section that describes something you built with the tool. That is a claim with a date, an employer, and an artefact behind it — checkable in a way a bare noun never is.

Which suggests a useful editing rule: for each of your most important skills, make sure it appears somewhere in the experience section attached to a real piece of work. Anything that appears only in the skills list is, by construction, unevidenced, and the gap between the two lists is worth looking at directly.

The items to cut first

• Anything from a training course you have not used since. Course attendance is a credential, not a skill; put it under training if it matters, with its status stated.
• Tools you watched someone else use. Being in the room is not exposure.
• Technologies you inferred you must know because they are part of a stack you worked in. If you never touched the queue system, it is not yours.
• Anything you added because the job posting mentioned it. Tailoring a resume to a posting is normal; adding an untrue skill because the posting asked for it is not, and it is a claim you cannot back up sitting in the most easily tested part of the page.
• Soft skills as bare nouns. “Communication” and “leadership” are unfalsifiable and therefore uninformative. Demonstrate them in a bullet or leave them out.

Skills you are actively learning

Something you are genuinely mid-way through learning can be worth signalling, but say so explicitly and put it last: “currently learning Rust” is honest and reads as initiative. “Rust” in the main list reads as a capability, and if the role involves Rust you will be asked about it in a technical conversation where the distinction becomes obvious in about a minute.

Why the discipline pays off

A trimmed skills list changes what you get interviewed for, which sounds like a cost and is mostly a benefit. Interviews you get on an inflated list are interviews you go into knowing there is a question you cannot answer, and that knowledge affects how you perform on the questions you could have answered.

There is also a consistency dimension. Skills lists get copied into profiles and application forms and then drift apart, so the same trimming should be applied everywhere, as part of keeping one version of your story across every surface. A skills list you can defend in full is a small thing that removes a whole category of avoidable trouble.