Software engineer CV that gets interviews

A software engineering recruiter spends, on average, six seconds on a first pass. In that window they are asking three questions: Can this person do the job? Have they done it somewhere similar? Do their bullet points match the language in our job description?

Most CVs fail the third test. A candidate who built a high-throughput event pipeline writes "developed backend services" because they are summarising broadly. The job description says "Kafka," "event-driven architecture," and "99.9% SLA." The ATS parser sees a mismatch and the CV gets scored down before a human ever reads it.

The fix is not to spray keywords throughout your CV. It is to surface the real project details — the stack, the scale, the outcome — in the language the job description uses. That is what tailoring means.

For software engineers specifically, hiring managers prioritise: impact at scale (users, throughput, latency improvements), specific technology choices and why, ownership and leadership (solo vs team, IC vs lead), and measurable outcomes (performance gains, incident reduction, revenue linked to technical work).

The optimal structure for a software engineering CV depends on your level, but the bones are consistent:

Summary (3–5 lines) — Not a generic objective statement. A tight paragraph that names your specialism (backend, full-stack, infra, ML engineering), the scale you have worked at, and one or two landmark accomplishments. Write this last, after you have tailored everything else.

Skills — List languages, frameworks, cloud platforms, and tooling. Group them logically: Languages, Frameworks, Databases, Infrastructure, Observability. Do not list things you cannot speak to in an interview. Order by relevance to the target role, not by how much you like them.

Experience — Three to four bullets per role, each starting with a strong action verb and ending with a quantified outcome. The STAR format (Situation, Task, Action, Result) collapsed into a single sentence is the goal. Avoid "responsible for" and "helped with" — these are contribution-obscuring phrases.

Projects — Only needed if you are junior or if a side project is genuinely more impressive than your employment history. Link to GitHub where the code is actually there.

Education — Brief. Institution, degree, year. Add relevant coursework only if you are early-career.

Length: one page for under five years of experience, two pages for senior and above. Never go to three pages.

The structure above holds for all tracks, but the emphasis shifts by specialism.

Backend engineers should foreground system design and scale. Mention data volumes, request rates, latency targets, and the distributed systems concepts you applied (consensus, sharding, caching layers). If you improved a P99 latency, say by how much. If you migrated a database, say how much data and how you handled zero-downtime.

Frontend engineers should foreground Core Web Vitals, bundle size improvements, accessibility work, and design system contributions. Hiring managers in product-led companies care about polish and collaboration with designers. Mention if you reduced LCP by X%, built a component library adopted by N teams, or shipped a feature used by N active users.

Full-stack engineers face a different challenge: depth versus breadth signalling. A recruiter reading your CV is trying to calibrate whether you are a strong backend engineer who can ship a frontend, or a frontend engineer who can write an API, or genuinely balanced. Make your depth explicit — list the area where you have done the most complex work first, even if the job description is ambiguous.

Infrastructure and platform engineers should highlight reliability engineering metrics (MTTR, SLO attainment, on-call reduction), tooling adoption, and cost savings. Kubernetes cluster size, deployment frequency improvements, and incident response statistics are all fair game.

Responsibilities instead of outcomes. "Maintained the payment service" tells a reader nothing. "Cut payment service P95 latency from 420ms to 80ms by introducing a Redis caching layer, reducing customer support tickets by 18%" tells them everything. Every bullet should answer: what did I change and what happened as a result?

Technology lists without context. Listing "React, Node.js, PostgreSQL, Redis, Kubernetes, Terraform, Datadog" at the top of your CV is table stakes, not a differentiator. Recruiters expect these skills. The differentiation comes from showing how you applied them at depth in your bullets.

Mismatched language. If the JD says "TypeScript" and your CV says "JavaScript," an ATS may score you down even if you are fluent in both. Use the exact terminology from the job description where it accurately describes your experience.

Undated or unclear projects. Side projects without dates, context, or usage numbers are filler. Either give them substance (launched, N users, open-sourced with N stars) or cut them in favour of more employment detail.

Generic summary. "Experienced software engineer passionate about building scalable solutions" appears on approximately 40% of CVs. Write something that could only be true of you: your specialism, your scale, your one landmark outcome.