Write a developer CV with evidence, not a tool inventory
Show what you did, why it mattered, and which skills the work demonstrates. Keep technology names useful and avoid invented metrics or keyword stuffing.
Build your CV around relevant work you can explain: the problem, your action, and the supported result. Use technology names to clarify that evidence, not replace it. Tailor the emphasis to the role without changing the facts or inventing impact numbers.
'Java, SQL, Docker' names tools. A statement about diagnosing a report failure, adding the missing check, and verifying the affected case shows what you used those tools to do.
A list of tools can tell a reader what you have encountered. It cannot tell them whether you can investigate a failure, finish a change, or explain a technical choice. Your CV needs a few pieces of work that make those capabilities visible.
Start with the work the role needs
Read the role description for responsibilities, not only keywords. What would the person build, maintain, investigate, or coordinate? Which experience is essential, and which is a preference? When the description is ambiguous, do not pretend that a long list of technologies makes the role clear.
Select genuine examples that connect to those responsibilities. A backend role may need evidence of working with persistent data and service behaviour. A role with wider coordination may need evidence of clarifying dependencies or guiding a decision. The same experience can be emphasised differently without changing what happened.
Ian Siegel’s Get Hired Now! prompted the focus on making relevant experience legible. For the writing method, MIT’s guidance on describing skills uses project, action, and result. Treat this as a way to explain work, not a demand that every line contain an impressive number.
Try the decision
A CV bullet says “responsible for APIs.” Which revision adds credible evidence?
A grander title without evidence may overstate the candidate’s contribution.
Next step: Identify the actual change and how it was checked.
This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.
Replace a duty with a supported contribution
Consider an illustrative weak statement: “Responsible for backend development using Java and SQL.” It describes a category of work but leaves your contribution unclear.
A stronger hypothetical statement is: “Investigated inconsistent report results, added a missing validation check, and covered the affected case with a regression test.” If the technologies are relevant, include them where they help explain the work. Do not copy this example unless it truthfully describes something you did.
A larger contribution might need more context: “Coordinated the API change with two consuming teams, documented the compatibility decision, and implemented the agreed transition.” This makes collaboration visible without claiming that you alone delivered the entire project.
Use a verb that matches your actual responsibility. “Led” is not a stronger version of “contributed”; it is a different claim. Explain whether you designed the approach, implemented part of it, reviewed it, or coordinated the work. The promotion-evidence guide makes the same distinction between activity and consequence.
Use numbers only when you can explain them
A number is useful when it clarifies scale or a measured result. It is not useful merely because it makes a sentence look more professional. Know what was measured, over which period, and how your contribution relates to the result.
If several changes reduced an error rate, do not attribute the entire reduction to your one change without evidence. If the measurement came from a controlled test, do not describe it as a customer outcome. If a figure is confidential, do not publish it because a CV template asks for metrics.
You can describe an outcome without a percentage: an agreed migration completed, a missing case covered, a manual handoff removed, or a decision documented so another team could proceed. Keep the claim bounded to what you know and can discuss.
Do not turn guesses into measurements with words such as “approximately” or “estimated.” An estimate still needs a basis. If the basis is weak, explain the work in a different way rather than decorating uncertainty with a number.
Make the evidence easy to find
Use clear headings, consistent dates, and straightforward wording. Put the experience most relevant to the role where a reader can find it quickly. A skills section can be helpful, but it should agree with the work described elsewhere.
Follow the employer’s requested format and check the exported document yourself. Can you select and copy the text? Are headings and dates in a sensible reading order? Do links open the intended public material? These are practical checks, not a promise of passing every applicant-tracking system.
Avoid hidden keywords, repeated tool names, and inaccurate titles chosen to match a search. There is no universal keyword trick that makes an irrelevant application relevant. If a requirement is missing, show an honest adjacent capability or leave the gap visible.
Public work is optional, not a prerequisite for being a good developer. Some useful experience is confidential, and some people have no time for side projects. Where you do include a project, show the decisions and limits rather than relying on a repository count.
Check every claim before sending
Read each statement as an interviewer might. What did you personally do? Why was it needed? How did you know the result? What would you do differently? If you cannot answer, the line may be too broad or may describe something you did not own.
Ask another person to identify your strongest relevant capabilities from the CV alone. If they can repeat your tools but not your contribution, revise the experience statements. Prepare the truthful interview account behind each important claim.
A CV is a selective account, not a complete autobiography. You can leave out irrelevant detail while remaining honest. The aim is to help the reader understand why your actual experience might fit their work, not to create a more impressive fictional version of it.