Keyword optimisation, done responsibly

Term-frequency approaches surface the words a posting repeats, which are often the company boilerplate — "collaborative", "fast-paced", "passionate". Those are not requirements and putting them in a CV helps nobody.

Extract the things a person must be able to do: technologies, methods, domains, qualifications, scale. A model does this well when asked for requirements specifically, and badly when asked for keywords.

Weight what you extract by how it was stated. A term in the job title or repeated through the responsibilities matters; one item in a bulleted list of twelve under a heading nobody wrote carefully does not, and treating them equally produces a long flat list of equal-looking suggestions.

A term absent from a CV means one of three quite different things, and conflating them is what makes these tools dangerous. Either the candidate has the experience and did not mention it, or they have equivalent experience under a different name, or they do not have it.

The first is a genuine improvement. The second is a wording fix. The third is not a CV problem at all, and any suggestion to add the term is a suggestion to lie.

Since the document alone cannot distinguish the first case from the third, ask. "This posting asks for X and your CV does not show it — have you used it?" costs one tap and converts a large share of apparent gaps into accurate additions.

• Has it, did not mention it — add, with the specific evidence
• Has an equivalent — surface both terms in the same phrase
• Does not have it — report as a gap, never as a suggested edit

Someone who wrote "built data pipelines" has ETL experience, and a posting asking for ETL will not match them lexically. The tool should recognise the equivalence and suggest phrasing that carries both, not replace their honest description with jargon.

"Built and operated ETL data pipelines" is both true and matchable. That is the shape of a good suggestion: additive, accurate, and serving lexical and semantic matching at once.

Be careful which direction the equivalence runs. "Built data pipelines" supports ETL; ETL experience does not necessarily support "built distributed systems", and a synonym table applied symmetrically will eventually produce a claim the candidate cannot defend.

This is the hard constraint that determines whether you have built a helpful product or an embarrassment generator. A tool that suggests adding a technology the candidate has never used is setting them up to be found out in the first technical conversation.

Enforce it structurally: every suggestion must point to specific evidence in the existing CV. If there is no evidence, the tool reports a gap and stops. Prompting a model to "be honest" is not enough — require the citation.

Watch for inflation as well as invention, because it introduces no new term and changes the claim. "Contributed to" becoming "led", or "used" becoming "owned", passes a naive check and fails the interview, so the comparison has to cover strength and not only content.

A skill in a bare list at the bottom of a CV is worth much less to a human reader than the same skill inside an achievement that shows what was done with it. The parser sees both; the person deciding does not treat them the same way.

So the better suggestion names the bullet to change rather than the list to extend. "Add Kubernetes to your skills list" is a parser optimisation; "your migration bullet used Kubernetes — say so" improves the document for both audiences at once.

Recency and duration carry weight that a keyword match discards entirely. A skill used last year and a skill touched once four years ago are very different claims, and phrasing that carries the timeframe is more honest and, in front of a human, more persuasive.

A tool that returns thirty keywords invites stuffing, and a CV visibly written for a parser reads badly to the human who ultimately decides. Recruiters notice a skills list containing every term from their own posting.

Return the handful that matter most, ordered by how central they are to the role. Fewer, better suggestions produce a CV that passes screening and still reads like a person wrote it.

Remember which stage this is optimising. Keyword coverage affects a first-pass screen and nothing after it, so a document that clears that gate and then reads as machine-written has won the cheap stage and lost the one that decides.