A bloated CV is just as damaging as a sparse one. Hiring managers and ATS systems both struggle with noise — too many bullet points, irrelevant jobs from 15 years ago, or a skills section that lists every technology you've ever touched. Getting a software engineering role in 2025 requires a CV that's precise, scannable, and tailored. This guide breaks down exactly what belongs on your CV, what to cut, and why.

The Core Sections Every Software Engineer CV Needs

Your CV needs five things to pass both ATS filters and a 10-second human review.

Contact details and professional links. Include your name, location (city and country is enough — no street address), email, LinkedIn URL, and GitHub profile. If you have a personal site or portfolio, add that too. Drop anything else.

A short professional summary. Two to four sentences at the top that pitch who you are and what you bring. Think: your role, your main technology stack, and your career focus. Avoid clichés like 'passionate developer' or 'team player.' Instead: 'Full-stack engineer with six years of experience building high-traffic APIs in Node.js and Python. Currently focused on distributed systems and cloud-native architecture.'

Technical skills. A concise list of languages, frameworks, tools, and platforms you're genuinely proficient in. Group skills into logical categories (Languages, Frameworks, Cloud & DevOps, Databases) to make scanning easier.

Work experience. Reverse-chronological order, with achievement-focused bullet points. The goal is to show impact, not just list responsibilities.

Education. Unless you're a recent graduate, education goes near the bottom. Degree, institution, and year is enough. Modules, grades, and dissertation summaries are only worth mentioning if they're directly relevant to the role.

The Skills Section: What to List and What to Drop

The skills section is where most software engineers go wrong — usually by listing too much.

Include languages you can write production code in (Python, TypeScript, Go, Java, Rust), frameworks and libraries you've used on real projects (React, Django, Spring Boot), cloud platforms and DevOps tools you know well (AWS, GCP, Azure, Docker, Kubernetes, Terraform), and databases you've worked with (PostgreSQL, MongoDB, Redis).

Leave out tools you used once on a university project, generic software like Microsoft Word or Google Docs, soft skills listed in a skills section (those belong in your experience bullets), and version control basics like Git — it's assumed for any engineering role.

Work Experience: How Much Detail to Include

Each role should have three to five bullet points — not a job description, but evidence of impact. Start each bullet with an action verb (Built, Reduced, Led, Designed, Migrated, Implemented), include a specific outcome or metric where possible, and mention the technology used.

For example: 'Reduced API response time by 40% by refactoring a Node.js service to use connection pooling and query caching in Redis.' That tells a hiring manager far more than 'Responsible for maintaining and improving backend services.'

Go back no more than 10 to 15 years. Anything older can be condensed into a single line or omitted entirely. If older experience is directly relevant — for example, you're returning to a domain after time away — a brief mention is fine.

Leave out day-to-day responsibilities written as job duties, roles unrelated to tech that happened more than five years ago, and internships once you have two or more years of professional experience.

Projects and Portfolio: When and How to Include Them

Side projects and open source contributions matter most for early-career developers without much professional experience, career changers demonstrating new skills, and senior engineers showcasing specific expertise in a domain they want to move into.

For each project, include the name, a one-line description, the tech stack, and a link (GitHub, live URL, or demo). Two to four projects is plenty. Avoid listing projects you can't speak to confidently in an interview.

Leave out tutorial projects (the weather app, the to-do list) unless you've meaningfully extended them beyond the original, projects with no README or visible code, and abandoned repositories with no recent commits.

What to Leave Out Entirely

Objective statements like 'Seeking a challenging position where I can grow my skills' tell the reader nothing. Replace them with a focused professional summary that communicates your role, stack, and direction.

In the UK, USA, Canada, and Australia, do not include a photo, date of birth, nationality, or marital status. These details are not expected and can introduce bias into the hiring process — excluding them protects both you and the employer.

Leave off 'References available on request.' It takes up space and is already understood. Only list certifications that are directly relevant and industry-recognised: AWS Certified Solutions Architect, Google Cloud Professional, CKA. Drop one-off online courses unless they're the primary evidence of a skill.

Length and Formatting

Aim for one page if you have less than two years of experience, one to two pages for two to ten years, and a maximum of two pages for ten or more years. Going beyond two pages rarely helps — editors value what you choose to cut.

Use a clean, single-column layout. ATS systems often struggle with tables, multiple columns, and complex templates. Keep fonts consistent, spacing even, and save as a PDF unless the job posting asks for something else.

Avoid graphics, icons, skill progress bars, and flashy design elements. They confuse automated parsers and look cluttered on screen. Clarity and scannability beat visual decoration every time.

Final Thoughts

The best software engineering CV is a curated document, not a complete record of everything you've done. Every line should earn its place: does it help a hiring manager decide you're worth a call? If not, cut it. Focus on impact, clarity, and relevance — and you'll have a CV that works harder than most.