What to fix first in your resume

Why the order matters

A first read of a resume is quick. The reader looks at the latest job, the titles, and whether the lines sound like someone who did the work. Fixing in the order below puts your time where that first read lands.

Each step is also quicker than the one after it, so even an hour gets the most important changes in. The first three steps improve the resume for every application; the fourth is done once per posting.

1. Claims without evidence

A claim states a quality or an outcome with nothing to back it: “results-driven leader”, “expert in Python”, “drove significant growth”. A reader cannot check any of it, and one unsupported claim makes the lines around it read as inflated too.

For each one, ask whether you can show it. If you can, replace the adjective with the fact behind it: “expert in Python” becomes the thing you built with Python and who used it; “drove significant growth” becomes what grew, from what to what, over how long. If you cannot show it, delete the line. A shorter resume with nothing to doubt reads better than a longer one with three lines to doubt.

Summaries are where most of these collect. Two plain sentences, the role you do and the kind of work you are best at, are enough.

2. Vague verbs

“Helped”, “worked on”, “was involved in”, “responsible for” and “participated in” hide what you did. The reader cannot tell whether you led the project or attended its meetings. Some examples of the change:

• “Responsible for the billing service” becomes “Ran the billing service: on call, releases and the move to a new payment provider”.
• “Helped with onboarding” becomes “Wrote the onboarding checklist every new hire on the team used”.
• “Worked on the data platform” becomes “Built the jobs that load sales data into the warehouse every hour”.

Use the verb that describes your part: built, wrote, ran, led, cut, moved, designed, negotiated, trained. When it was a team effort, say what your part was instead of claiming the whole.

3. Missing scope and results

Once the verb is right, each experience line needs two more things: how big the work was, and what changed because of it. Scope is the size: users, customers, accounts, people, budget, volume. A result is the difference: faster, cheaper, more revenue, fewer errors, a launch that happened, a process other teams adopted.

Not every line has a number, and you should never invent one. A before and after works (“from a weekly manual export to a daily automatic one”), and so does naming who used the work (“used by the support team to answer refund requests”). If you only remember an approximate figure, write “about” and keep it one you would defend in an interview.

Two lines that say the same thing in different words are worth merging at this step. The space they free is room for a result you have not written yet.

4. Skills the posting names that you have but did not write

This step is the one most often skipped, and it is done one posting at a time. Read the posting’s must-haves (the guide to reading a job posting shows how to separate them) and check each one against your resume. Where you have the skill and the resume does not say it, add it, in the posting’s words where they are accurate: if the posting says PostgreSQL and your resume says “SQL databases”, name PostgreSQL.

Put the skill in an experience line where you used it, not only in a skills list. “Built the reporting API in Go” shows more than “Go” in a list of twenty tools.

Never add a skill you do not have. It comes up in the interview, and a gap you name is easier to work around than one you hid.

What can wait

Fonts, colours, a photo, one page or two, and the order of sections matter far less than the four steps above. Keep the layout plain so it reads the same everywhere it is opened, including the software companies use to store applications: one column, standard section names, dates on every job, and a PDF whose text can be selected.