Software Engineer CV Example
A software engineer CV is read by two very different audiences in sequence: an automated resume parser, then a senior engineer or technical recruiter. Both want very different signals from the same page. The parser wants exact keyword matches against the job description — language names, framework names, the right job titles in the right format. The human wants evidence: scope of what you actually built, technical depth at the level the role demands, and outcomes that prove your work mattered. This example covers the structure, the skills section, the experience bullets, the projects section, and the small details that separate a software engineer CV that lands interviews from one that gets filtered out. Everything in it is editable in the Cvida builder; use it as a starting point and tailor for your stack and seniority.
Why a software engineer CV is different from a generic CV
Start with the differences, because they explain every choice that follows. Software engineering hiring has its own conventions:
- Technical specificity is the whole game: 'web developer' is a label, 'TypeScript / React / Node / PostgreSQL' is a real CV match the parser can score
- Projects count as much as jobs: a strong open-source contribution or a real production side-project is treated like work experience by senior reviewers
- Stack matters more than title: 'Senior Engineer at small company you've never heard of' is judged by the stack used and the scale shipped, not the title
- Quantification is technical, not commercial: latency reduced, queries-per-second handled, MTTR improved, deploy frequency, test coverage — not 'increased revenue'
- ATS keyword matching is brutal in tech: hundreds of applications per role mean a recruiter literally scans for the exact frameworks named in the job post
Treat your CV as a technical document. The same precision you'd use in a system design doc applies here: name the right primitives, show the scale you operated at, prove it with measurable outcomes.
The CV structure that works for engineering roles
Most software engineer CVs work best in this order — it puts the technical signal where reviewers actually look first:
- Header: name, role title, location, email, GitHub URL, LinkedIn URL, portfolio/website URL — every link clickable in the PDF
- Summary (3–4 lines): years of experience, primary stack, one or two domain specialisms, the kind of role you're targeting
- Skills: technical skills grouped (languages, frameworks, infrastructure, tools) — scannable in 5 seconds
- Experience: roles in reverse-chronological order, each with 3–6 bullets focused on what you shipped + the impact
- Projects (especially for juniors and mid-level): 2–4 personal or open-source projects with tech stack + outcome
- Education: degree + university + year — short, unless you're a recent grad with relevant coursework
- Optional: certifications (AWS, Kubernetes, etc.) and languages spoken if relevant
Keep it to 1 page for under 5 years of experience, 2 pages above that. Senior staff/principal engineers with significant scope earn the second page; everyone else should treat one page as the discipline that forces them to pick the strongest signals.
The fundamentals of CV structure and length that this builds onThe summary: tech stack first, outcomes second
Three or four lines, top of the page. This is the most-read part after your name. It should answer: who you are, what you ship, what kind of role fits next:
- Line 1: years of experience + primary specialism. Example: 'Backend engineer with 6 years of experience building distributed Go services on AWS.'
- Line 2: the kind of scale you've operated at. Example: 'Owned services handling 50k requests/second; led incident response across a 12-engineer platform team.'
- Line 3: technical breadth signal. Example: 'Strong in Go, Kafka, Postgres; comfortable in TypeScript and Python for adjacent work.'
- Line 4 (optional): what you're targeting next. Example: 'Looking for senior or staff roles building platform infra at consumer scale.'
- What to drop: 'passionate' / 'team player' / 'highly motivated' — these are space-fillers that work against you. The technical specifics do the persuading
A summary that names a real stack, a real scale, and a real next step beats an adjective-heavy one every time. If you can't name a specific stack you'd own, the summary isn't ready — that gap will show up in the interview anyway.
The skills section: depth signals, not a buzzword wall
Group your technical skills by type so a reviewer can scan in seconds. Within each group, order by your real depth — most-fluent first:
- Languages: Go, TypeScript, Python, Rust (in roughly that order of fluency)
- Frameworks: React, Next.js, Node/Express, FastAPI, gRPC
- Data / infrastructure: PostgreSQL, Redis, Kafka, ElasticSearch, Kubernetes, Terraform, AWS (EC2, S3, RDS, Lambda)
- Practices: distributed systems design, observability (Prometheus, Grafana, OpenTelemetry), CI/CD (GitHub Actions, ArgoCD), incident response
- What to leave off: tools you used once 5 years ago, languages you've only touched in a tutorial, 'Microsoft Word' (truly — recruiters will roll their eyes)
Be honest about depth: if you list it, you'll be asked about it. A short, accurate skills section beats a long one full of false signals — getting caught lying about Kafka experience in the technical screen costs you the offer.
How to build a credible, specific skills section that maps to the roleExperience bullets: ship + scale + impact, every line
The strongest engineering bullets follow a tight pattern: action verb → what you built → the scale or impact in numbers. Compare these:
- Weak: 'Worked on the payment processing system' — no stack, no scale, no outcome, no scope of ownership
- Strong: 'Designed and shipped a distributed Go payment service handling 12k transactions/second with 99.99% availability across 3 AWS regions'
- Strong: 'Cut p99 API latency from 480ms to 90ms by replacing in-memory aggregation with a Redis-backed materialised view; rolled out behind feature flag over 6 weeks'
- Strong: 'Led the team's migration from a Rails monolith to 4 Go services; reduced deploy time from 35 minutes to 6 and incident MTTR from ~2h to 28 minutes'
- Strong: 'Built the internal feature-flag platform now used by 40 engineers across 6 teams; integrated SDKs for Go, TypeScript, and Python'
- Pattern to apply: start each bullet with an action verb (designed, shipped, led, scaled, owned, migrated, automated), name the technology, name the scale or the before/after
The numbers don't have to be impressive — they have to be real and specific. 'Handled 200 requests/second on a small e-commerce checkout' is a strong bullet for a mid-level engineer; honesty about scale is more persuasive than vague claims of impact.
How to quantify your work the way engineering hiring panels score itThe projects section: critical for juniors, useful for everyone
A strong projects section answers the question reviewers always have about candidates whose day jobs don't show all their range: what can you build when no one's stopping you? It carries serious weight for early-career engineers and pivoters:
- Pick 2–4 projects, each with: name, one-line description, tech stack, GitHub or live URL, and 1–2 bullets on what's interesting about how you built it
- Open-source contributions count: 'Contributed a Kafka consumer rewrite to {project} (merged, 30k weekly downloads)' is a serious signal
- Side projects with real users are gold: 'Built {tool}: a CLI for X used by ~200 developers; written in Rust, packaged via Homebrew'
- Course / bootcamp projects are weakest — only include them if you have nothing else and lead with what was technically non-obvious
- If you have 5+ years of strong job experience, this section becomes optional; replace with 'Selected open-source contributions' if you have any
Make every project link live. A reviewer who clicks the GitHub URL and lands on a real, recently-active repo with a clean README is half-sold before they read your bullets — get the signal in front of them with one click.
Education + certifications: keep it short
For software engineers, this section earns its space only when it adds a specific signal:
- If you have a degree, list it: degree type, field, university, year. One line. Skip GPA unless you're a recent graduate with a strong one
- Recent grads (0–2 years out): add relevant coursework or capstone projects, but only the ones that map to the role you want
- Bootcamp grads: name the bootcamp + the year; lead with the projects and the production code you've shipped since, not the curriculum
- Self-taught: skip the education section entirely; let the projects section + work experience do the work
- Certifications worth listing: AWS Solutions Architect / Associate, GCP Professional Cloud Architect, CKA (Certified Kubernetes Administrator). Skip 'Codecademy completed' — recruiters don't count it
Education matters less the further you are from graduation. By year 5, a strong projects + experience section makes the education line nearly invisible — which is exactly what you want. The interview will be about your code, not your degree.
ATS optimisation: match the job post exactly
Even at senior levels, your CV gets parsed before a human sees it. Engineering ATS scoring is unusually literal about technology names:
- Mirror the exact framework names from the job post. If the post says 'React.js' write 'React.js' (not just 'React'); if it says 'Node.js' write 'Node.js'
- Spell out both the abbreviation and the full name where they differ: 'Kubernetes (K8s)', 'Continuous Integration (CI/CD)' — covers both keyword variants
- Keep the format simple: standard fonts, no two-column layouts, no images of text, no fancy section dividers. ATS parsers mangle anything visually clever
- Save as PDF unless the job post asks for Word — the layout survives the round-trip more reliably
- Don't keyword-stuff a hidden 'skills' line in white text. Modern ATSs flag this and recruiters laugh — and the technical screen catches the lie anyway
The simplest test: can you open your CV in a plain text editor and have it read top-to-bottom in a sensible order? If yes, the parser will too. If your skills end up in the middle of your education line, the formatting is fighting the parser.
The full ATS playbook for parsing-safe CV formattingCommon mistakes that filter strong engineers out
Even technically strong engineers lose interviews to CV mistakes that are quick to fix:
- Listing every language you've ever touched: it dilutes the real signals and invites interview questions you'll fumble. List what you'd be confident defending in an interview, no more
- Buzzword summaries with no stack: 'passionate full-stack engineer with strong communication skills' tells the reader nothing. Name a stack and a scale
- No links: a software engineer CV without a GitHub URL or portfolio is suspicious — reviewers want to see code. Add the URL even if your GitHub is modest
- Wall-of-text bullets: bullets longer than two lines lose the scanner. Keep them tight: action + tech + outcome
- Outdated stack signals: leaving 'jQuery' in the languages list when you've been writing TypeScript for 5 years signals the CV hasn't been rewritten in a long time — and that you might not be either
Run the recruiter's test: in 30 seconds, can a busy reviewer see what you build, at what scale, and which roles you fit? If yes, this CV will land you the screens. If not, the fixes are almost always the same — tighter bullets, named stack, fewer adjectives, working links.
The full guide to tailoring a CV for tech roles — stack mapping and seniority signals