Software Engineer CV Example & Writing Guide

The full CV example

Fictional example. Use your own name, city, email, phone and one profile link.

Why this CV works

Four things this example does that most engineer CVs do not:

• The headline says which kind of engineer

  "Software Engineer" alone matches thousands of jobs. "Backend and platform" narrows it to the ones this person can actually win, and costs six words. A frontend recruiter stops reading, which is the point.

• Every claim is checkable

  820 ms to 230 ms. Zero duplicate charges. 90k SKUs in a 20-minute window. None of these prove anything on their own, but they invite a question the candidate can answer, and an interview is a sequence of questions the candidate can answer.

• The stack appears inside the work, not only in a list

  Go and Postgres are in the skills block, but they are also in the sentence about the billing migration, attached to a decision. A parser picks up the keyword either way; a human only believes it in the second place.

• The oldest role is one line

  The 2020 agency job gets a single bullet. Space on page one goes to the work that matches the next job. Compressing early roles is how a CV stays at two pages without deleting the career.

• It admits to scope

  "Payments platform team of 6" stops a reader mistaking the checkout latency work for a solo effort, and stops an interviewer catching the exaggeration later. Naming the team size costs nothing and buys credibility.

Professional summary examples

Entry level

With little experience, name the one thing you actually shipped and the environment you want. Do not claim ownership of a system you were shown around.

Mid level

Mid-level is where a number belongs. Two sentences of evidence, one of scope.

Senior

Senior summaries should say what you are trusted with, not how many years you have. The last sentence is an offer, not a description.

Experience bullet examples

Twelve bullets, weak form and strong form. The strong versions are not better because they are longer - they are better because a reader can disagree with them.

Weak

Responsible for software development.

Stronger

Reduced checkout API median latency from 820 ms to 230 ms by refactoring the payment-service request pipeline.

Why

The weak version could describe any job in the industry.

Weak

Worked on the billing system.

Stronger

Migrated billing from a shared Postgres instance to a dedicated cluster with zero downtime, using dual writes and a two-week read shadow.

Why

Naming the technique is what signals you have actually done it.

Weak

Fixed bugs and improved code quality.

Stronger

Cut duplicate charges from roughly 40 a month to zero by adding an idempotency key to every write path in the retry handler.

Why

"Improved code quality" is unfalsifiable. Pick the bug class that mattered.

Weak

Was part of the on-call rotation.

Stronger

Took on-call for two services and reduced paging volume 60% by fixing the four alerts that produced most of it.

Why

Being on call is table stakes. Changing what on call feels like is not.

Weak

Used Docker and Kubernetes.

Stronger

Moved six services off hand-written manifests onto a shared Helm chart, which took a new service from two days of setup to about an hour.

Why

Tools belong in an outcome, not in a sentence of their own.

Weak

Wrote unit tests.

Stronger

Added contract tests between the storefront and four internal services, catching 11 breaking changes before release in the first year.

Why

The number here is the count of problems avoided, which is the only reason anyone funds testing.

Weak

Mentored junior developers.

Stronger

Mentored two junior engineers through their first production incidents; both now run the on-call rotation unsupervised.

Why

Mentoring claims need an outcome you did not control, or they read as self-assessment.

Weak

Improved application performance.

Stronger

Cut the nightly inventory sync from 55 minutes to 18 by batching writes and dropping a redundant index, bringing it inside the delivery window.

Why

Two numbers and the constraint they had to fit. The constraint is what makes it a result.

Weak

Participated in code reviews.

Stronger

Introduced a review checklist for schema changes after a migration locked a table for 40 minutes in production; no migration has locked a table since.

Why

The incident is the reason the practice exists. Include it.

Weak

Worked in an Agile environment.

Stronger

Broke a six-month platform migration into eleven shippable steps, each deployable and reversible on its own.

Why

Nobody hires for Agile. They hire for being able to decompose a large change.

Weak

Built APIs.

Stronger

Designed and shipped the public webhooks API now used by 140 merchant integrations, including replay and signature verification.

Why

Adoption is the evidence that the design was usable.

Weak

Helped migrate to microservices.

Stronger

Extracted the notification service out of the monolith behind a feature flag, moving traffic over four weeks with a one-command rollback at every stage.

Why

"Helped" hides your role. Say what you extracted and how you de-risked it.

Skills that belong on this CV

Education and certifications

A computer science degree helps for a first job and stops mattering quickly after that. By the third role, put education after experience and keep it to degree, institution and years. Bootcamp graduates should name the programme and then spend the space on projects instead.

Certifications

• AWS Certified Solutions Architect / Google Professional Cloud Architect - Worth listing when the job ad names the cloud. Otherwise it reads as filler next to shipped work.
• CKA (Certified Kubernetes Administrator) - Relevant for platform and infrastructure roles specifically.

There is no certification a software engineer needs. List one only when the advert asks for it by name.

How an ATS reads this CV

Appliora's ATS Checker runs 14 checks against an uploaded file and shows you the text its parser extracted. Three of those checks catch the mistakes engineer CVs make most often.

• Reading order

  Developer CVs attract two-column templates, usually with the stack in a narrow sidebar. When a parser reads across the page instead of down the column, the sidebar text lands interleaved with your job titles. The checker shows the extracted text in reading order, so you can see whether it happened to your file.

• Concrete skills

  A skills block of forty comma-separated tokens scores worse than twelve, not better. The check looks for recognisable skills rather than orphan fragments - "k8s", "CI" and a lone version number read as noise.

• Bullet quality

  This is the heaviest content check. It looks at how many of your bullets carry a figure and how many open with an action verb. "Responsible for" phrasing across a whole role is the single most common reason an otherwise strong engineer CV scores in the 60s.

• Format traps

  Skill rating bars, icon fonts for contact details and text inside graphics are all invisible to a parser. They are also common in developer templates downloaded from design sites.

Templates that suit this role

• ATS Structured

  Single column, conventional headings, nothing in a sidebar. The safest choice when you are applying through a large company's portal.

• Tech Stack

  Gives the stack a proper block without putting it in a narrow column, so it survives parsing while still being the first thing a human sees.

• Swiss One Page

  A disciplined one-page layout for engineers with under four years, where a second page would be padding.

• Dark Modern

  For direct applications and portfolio links where a recruiter is reading the PDF rather than a parser.

Related roles

• Backend Developer
• Frontend Developer
• Full Stack Developer
• DevOps Engineer