The short version
- Name the change you made, in the words you’d use with a teammate.
- Say how you checked it: a test, a review, a staging run.
- Use a number only when you can say where it came from.
1Say what changed
“Improved the import process” says something got better and nothing about what. Ask what the system did before your work and what it does now. The answer is usually a behavior: a request that now fails loudly, a job that now retries, a page that now loads from a cache.
Jordan’s answer was concrete: incomplete imports used to fail without a reason, and now they’re rejected with a clear error.
2Say how you checked it
A check is your proof. Tests, a code review, a staging run, a support ticket that stopped coming back: each tells a reader the change works, and none needs a percentage.
Jordan wrote regression tests for the rejected-record response. That goes in the line.
3Write the line
Put the change first and the check after it. Name the tools you used if they matter to the role. Jordan’s line now says what was built and how it was tested, and a reader can ask about both.
4When a number belongs
Use a number when you measured it and can say how: a count from the logs, a test suite’s run time, the size of a queue before and after. A reader who asks “how did you measure that?” should get a real answer.
Don’t estimate a number to fill the slot. If the team measured a result, say what your part was. The AI guide shows how an invented 40% gets onto a resume.
Common questions
Does every bullet need a metric?
No. Use one when you have it and know what it measures. Otherwise a concrete change and the check behind it carry the line.
Will a line without numbers look weak?
A specific line looks stronger than a vague one with a number attached. Reviewers ask about numbers, and a guessed one is hard to defend.