CV example · Seven years, mid-to-senior
Software engineer CV example
The example CV, rendered at full page size in the Software Engineer template. The full text of the summary and the highlighted bullet points is reproduced below in selectable form.
Priya Example is a fictional person. The employers, figures and links are illustrative and exist only to show how a real CV of this kind is put together.
The text, in full
The professional summary
Backend engineer with seven years building and running high-throughput services in Java and Go, most recently owning the shipment tracking platform at a logistics company handling around 4M API requests a day. Strongest on distributed systems that have to stay up: event-driven ingestion, idempotency, and the unglamorous work of making deployments boring. Comfortable being on call for what I build.
Why it is written this way: Three sentences and no adjectives about being passionate or results-driven. The first gives years, languages and — crucially — a scale figure, so everything below is read against 4M requests a day rather than against nothing. The second names a specialism narrow enough to be a real claim. The third is one line about being on call, which quietly answers a question engineering managers care about and rarely see addressed.
The text, in full
4 experience bullets, and why each one works
Bullet 1
Cut p99 latency on the public tracking API from 850 ms to 210 ms by replacing a per-request currency and carrier lookup with an in-process cache and a nightly refresh job.
Opens with the metric that moved and closes with the mechanism, so the reader gets the result in four words and the credibility in the rest. Naming the actual cause — a per-request lookup — is what makes it sound like something that happened rather than something that was written.
Bullet 2
Led the migration of 14 services from EC2 to EKS over five months and wrote the Helm conventions the other three teams adopted; deploy frequency went from weekly releases to around 30 a week, and rollback time from 40 minutes to under two.
Establishes ownership ("led"), scope (14 services), duration (five months) and influence beyond the team (three other teams adopted the conventions). The two operational figures at the end are the payoff, and they are the kind that get asked about in interviews, which is a good sign.
Bullet 3
Rebuilt carrier webhook ingestion as an idempotent Kafka consumer with a replayable dead-letter topic, ending a class of duplicate-delivery incidents that had caused six customer-facing outages in the previous year.
A reliability bullet with a before state. Six customer-facing outages is an uncomfortable number to write down, and including it is precisely why the fix reads as significant. Idempotency and a replayable dead-letter topic are specific enough to prove the work was understood, not just completed.
Bullet 4
Ran onboarding for four new engineers and rewrote the code review checklist after a post-incident review; median time to first merged pull request for new starters dropped from nine days to three.
The people bullet, written as engineering rather than as sentiment. Mentoring is unverifiable; an onboarding process, a rewritten checklist and a team metric that moved from nine days to three are not.
Section by section
Why the CV is built the way it is
The header
Name, title, city, email, phone and three links, all as plain text. No photo, no date of birth, no full postal address — none of them help, and the first two actively hurt in UK and US applications. The GitHub link is here because the profile behind it is maintained; an unlinked profile is better than a neglected one.
Technical skills, placed second
This is the deliberate structural choice on the page. Skills sit directly under the profile, above the job history, because the first read is a matching exercise and the recruiter is checking a list. The block is grouped — languages, frameworks, infrastructure, data, observability — so it can be scanned in a couple of seconds, and the levels are uneven on purpose. A list where everything is "expert" is read as a list where nothing is.
The scope line under each job
Every role opens with one unbulleted line establishing what was owned and how big it was: services, integrations, requests, events, team size, on-call rotation. Without it, a bullet about cutting latency has no context; with it, the reader can size the job in one sentence and every achievement lands harder.
Bullet distribution across the roles
Four bullets on the current role, three on the previous one, two on the first. Attention drops sharply down the page, so the strongest and most recent material gets the space. The 2017 graduate job earns two lines because it shows the starting point of the trajectory, not because anyone will read it closely.
Honest numbers, including the hedged ones
Some figures are exact because they came from a dashboard, and some are softened — "around 4M requests", "roughly half", "was associated with a fall". That mix is deliberate. A CV where every number is suspiciously precise invites the interview question you do not want, and hedging the ones you cannot fully attribute costs nothing while making the rest more believable.
One project, not six
The open-source section holds a single tool with a real reason for existing and evidence that other people use it. Six tutorial repositories would push the employment history down the page and prove nothing. If the project section cannot beat the space it takes from your jobs, cut it.
Education compressed to two lines
Degree, institution, year, classification, and nothing else. Seven years in, the degree is a hygiene check. Modules, societies and the dissertation title all left the CV around year three and the space went to work that pays.
What is deliberately absent
No skill bars, no percentage ratings, no interests, no "references available on request", no two-column sidebar. Each of those would cost space or parsing safety in exchange for decoration, and in a field where the skills list is the filter, that is a bad trade.
Adapt it
What to change if you have less experience
- Two or three years in: keep the same structure but drop to one page. Two roles, three bullets each, and skills still directly under the profile.
- Replace the scope line with whatever scale you do have — users, records, tickets, services — even if the numbers are small. A precise small number reads better than no number.
- With one or two jobs, the projects section moves above education and earns more space: one substantial project with a README, tests and a reason for existing does real work at this stage.
- Do not pad with technologies you have touched once. Four things you can be interviewed on is a stronger page than fourteen you have to hedge.
- If you came through a bootcamp or a conversion course, state it plainly in the education block. Trying to disguise it reads worse than the route ever does.
US market
What to change for a US résumé
- Cut to one page: drop the 2017 role to a single line, remove the open-source section unless it is directly relevant, and tighten each bullet by a clause.
- Rename the file and the document "resume", and drop the "Profile" heading in favour of "Summary".
- Remove the classification — "2:1" means nothing to a US reader. Give a GPA only if you graduated recently and it was strong.
- Quantify in dollars where money appears, and keep the scale figures (requests, events, users) exactly as they are; those travel unchanged.
- Keep the same structural order. US engineering resumes also lead with a skills block, so the one genuinely portable thing here is the shape.
The conventions behind those edits are set out in full on the US résumé guide.
Use the structure, not the sentences
Everything above is fictional, and it is meant to be studied rather than copied. Recruiters in a given field read hundreds of CVs a month and recognisable phrasing is noticeable — the value of a worked example is in showing you what to include, how a claim is constructed and where it belongs on the page. The specifics have to be yours, because the specifics are the only part that persuades anyone.
The most portable things here are the scope line under each employer, the distribution of bullets across the roles, and the habit of ending a sentence with a number and its method rather than with an adjective. Those three transfer to almost any profession. For the advice that does not transfer — the metrics, the section order, the terms a parser in your field is matching for — read the profession guides.
Software engineer CV example: common questions
Keep going
- Software engineer CV guideHow to write a software engineer CV: the order an engineering manager reads it in, the metrics that carry weight, three bullets rewritten, and templates that parse.
- Data analyst CV guideA data analyst CV is read for the stack, then for evidence that your analysis changed a decision. How to write both, with three bullets rewritten and templates that parse.
- Project manager CV guideA project manager CV is judged on the size of what you have run and whether it landed. Budget, headcount, duration, variance against plan — and how to write them honestly.
- Project manager CV exampleA full worked document — eleven years, business change and systems.
- Accountant CV exampleA full worked document — acca-qualified, six years in industry.
- All CV examplesTen roles, each with one weak bullet rewritten into a strong one.
- ATS-friendly CV templatesWhat a parser does with your file, and the layouts built to survive it.
Start from this software engineer example
Open the editor with the same template already selected, then replace the content with your own. Switching to another design later keeps every word you have written.
Free plan, free download, no credit card.