Backend Developer CV Example and Writing Guide

A simple order works best for most UK backend roles:

1. Contact details and links.
2. Short profile.
3. Technical skills grouped by category.
4. Work experience in reverse-chronological order.
5. Projects, if they add evidence not already covered in your job history.
6. Education, certifications, and training.
7. Optional extras such as open-source contributions, speaking, mentoring, or relevant interests.

Do not hide the stack at the bottom of the CV. Backend hiring teams often need to check language, framework, database, and deployment fit quickly. A grouped skills section near the top saves them from hunting through every bullet.

That does not mean the skills section should do all the work. A list of Java, Python, Node.js, PostgreSQL, Docker, and AWS is not enough on its own. The experience section should prove how you used those tools in real systems.

For most candidates, the first page should answer four questions: what level are you, what backend stack do you use, what have you delivered, and how do you work with a team? If the first page only shows a long profile and generic responsibilities, the strongest evidence may be missed.

Put your most relevant backend evidence early. If a role asks for Python, FastAPI, PostgreSQL, Docker, and AWS, those terms should appear in your skills section and in one or more experience bullets where they are supported by real work.

For a UK CV, keep personal details minimal. You normally do not need a photo, date of birth, marital status, full postal address, or National Insurance number. A town or region is enough unless the employer asks for more.

Use clear headings such as Profile, Technical Skills, Experience, Projects, and Education. Use consistent dates, plain bullet points, and standard file formats. Avoid diagrams, progress bars, icons that replace text, or sidebars that might confuse parsing.

A two-page CV is usually right for a backend developer with commercial experience. One page can work for a junior candidate with limited history, and three pages should only be considered for highly experienced contractors, senior engineers, or technical leads with genuinely relevant delivery evidence.

If you want more general layout support, compare this page with the CV Structure Guide. For adjacent technical roles, the Software Engineer CV Example, Full Stack Developer CV Example, and Frontend Developer CV Example can help you adjust the balance between backend depth and broader engineering evidence.

Backend Developer with four years of experience building REST APIs and internal services with Node.js, TypeScript, PostgreSQL, Redis, and AWS. Experienced in improving endpoint performance, writing integration tests, supporting CI/CD pipelines, and collaborating with frontend, QA, and product teams on customer-facing releases. Recently reduced repeated support escalations by improving logging, validation, and error handling across a payments service.

This works because it names the stack, shows production responsibilities, and gives a specific outcome. It does not rely on unsupported claims such as “passionate”, “hard-working”, or “expert”.

Junior Backend Developer with a software development apprenticeship and project experience in Python, Django, REST APIs, PostgreSQL, Git, and unit testing. Built a booking API with authentication, role-based permissions, and documented endpoints, and completed team code reviews during placement work. Looking for a junior role where I can keep improving server-side development, testing, and database design in a supported engineering team.

This version is honest about level while still giving evidence. For a junior backend developer CV, projects, placements, bootcamps, apprenticeships, and GitHub work can carry more weight than job titles.

Senior Backend Developer with eight years of experience designing, modernising, and operating API-led services in Java, Spring Boot, PostgreSQL, Kafka, Docker, Kubernetes, and AWS. Led migration of a monolithic billing workflow into event-driven services, improved observability, and mentored junior developers through code review and design sessions. Comfortable owning technical decisions from discovery through release, monitoring, and incident follow-up.

This profile signals scope and judgement. Senior candidates should show architecture, risk, ownership, mentoring, and operational maturity, not just a longer list of tools.

Backend work can sound invisible if you describe only tasks. “Built APIs”, “fixed bugs”, and “worked with databases” are technically relevant, but they do not show scope or impact.

Use a simple action-scope-result pattern:

• What you did.
• What system, service, data flow, or team it affected.
• Which tools or methods mattered.
• What improved.

You do not need a metric in every bullet, but you should give enough context for the reader to understand the value.

Weak: Built REST APIs for customer platform.

Stronger: Built and maintained REST APIs for a customer onboarding platform using Node.js, TypeScript, PostgreSQL, and OpenAPI, reducing repeated manual checks by adding validation, audit logging, and clearer error responses.

Weak: Worked on database performance.

Stronger: Optimised slow PostgreSQL queries in reporting endpoints by reviewing indexes, query plans, and pagination logic, cutting average response times from 3.8 seconds to under 900ms during peak usage.

Weak: Helped with deployment.

Stronger: Supported CI/CD improvements with GitHub Actions and Docker, adding automated test steps and safer rollback notes so the team could release smaller backend changes twice a week.

Weak: Fixed production bugs.

Stronger: Investigated production incidents across payment callback handling, tracing failures through logs, queue retries, and third-party API responses before releasing a fix that reduced duplicate support tickets.

These examples are specific without being overloaded. They show the technology, the problem, and the result.

Tailor your bullets to the job advert. If the advert asks for Python and AWS, do not lead with old PHP work unless it is your strongest evidence. If it asks for microservices, do not just say “microservices”; show service boundaries, deployment, observability, messaging, or API contracts.

For backend roles, useful bullet themes include:

• API design, versioning, authentication, authorisation, and documentation.
• Database design, query performance, migrations, indexing, and data integrity.
• Testing, including unit, integration, contract, and end-to-end collaboration.
• CI/CD, containerisation, cloud deployment, infrastructure awareness, and release safety.
• Security practices such as input validation, access control, secrets handling, and dependency updates.
• Reliability work such as logging, monitoring, tracing, incident response, and post-incident fixes.
• Collaboration with frontend, QA, DevOps, product, support, data, and security teams.

Use the same principle when comparing this page with the Python Developer CV Example, Node.js Developer CV Example, or Java Developer CV Example. Your stack-specific CV should still show outcomes, not just syntax familiarity.

Projects can help a Backend Developer CV when they prove skills that your employment history does not show. They are especially useful if you are applying for your first backend role, moving from frontend to backend, returning after a break, or changing from a different software area.

A good project entry should explain the problem, the stack, the backend decisions, and the result. Avoid writing a project section that reads like a coursework list.

Inventory API and stock alert service Built a Django REST API for a small retail inventory project, using PostgreSQL, JWT authentication, role-based permissions, and Celery tasks for low-stock alerts. Added unit and integration tests, documented endpoints with OpenAPI, and deployed a demo version using Docker. The project demonstrates database modelling, background jobs, validation, and practical API documentation.

This example works because it explains the purpose and the backend decisions. It does not simply list “Django, PostgreSQL, Docker”.

Include GitHub when it strengthens your application. A tidy repository with a clear README, setup instructions, tests, meaningful commits, and a deployed demo can help. A messy account full of half-finished tutorials may weaken your CV.

Before linking to GitHub, check:

• The pinned repositories match the role you want.
• The README explains what the project does and how to run it.
• The code is not full of secrets, copied coursework, or broken dependencies.
• Tests, linting, or CI are visible where relevant.
• Commit messages show steady progress rather than one large upload.
• The project supports the claims in your CV.

Open-source contributions can also help, but describe the contribution clearly. “Submitted documentation fixes and two bug-fix pull requests to an internal tooling library” is more useful than “contributed to open source”. GitHub’s pull request review guidance describes reviews as a way to comment, suggest improvements, approve, request changes, and share knowledge before code is merged, which is exactly the kind of collaboration evidence worth reflecting in backend experience when it is real.

List the degree, institution, dates, and relevant modules only if they add value. For an experienced backend developer, education can sit below experience. For a graduate or junior applicant, modules such as databases, distributed systems, algorithms, security, cloud computing, and software engineering can be useful.

Example:

BSc Computer Science, University of Leeds, 2022 Relevant modules: databases, software engineering, cloud computing, web application security. Final-year project: event booking API using Python, Django, PostgreSQL, and Docker.

Do not apologise for a non-degree route. Show what you learned and what you built. Include apprenticeship standards, placement work, team projects, code reviews, tests, and any production exposure.

Example:

Software Developer Level 4 Apprenticeship, 2023 Built internal API features in C# and SQL Server, completed code reviews, wrote unit tests, and supported sprint demos with a six-person product team.

For bootcamps, include the provider, dates, technologies, and one or two project outcomes. Avoid making the bootcamp section longer than your project or experience evidence.

Certifications can help when they match the role. AWS, Azure, Kubernetes, security, database, or language-specific certifications may support your CV, especially for cloud-heavy backend roles. They do not replace project or production evidence.

List certifications clearly, and remove expired or irrelevant ones. If you are studying for a certification, say “in progress” only when there is a real exam plan or course evidence.

Formatting should make technical evidence easier to find. It should not compete with the evidence.

Use a clean font, clear headings, consistent spacing, and bullet points of one to three lines. Keep dates aligned and use month-year or year-only consistently. Save the file with a clear name such as samira-khan-backend-developer-cv.pdf.

For most mid-level and senior candidates:

1. Name, target role, contact details, location, and useful links.
2. Profile.
3. Technical skills.
4. Experience.
5. Projects or selected technical achievements.
6. Education and certifications.
7. Optional additional sections.

For junior candidates:

1. Name, target role, contact details, location, and useful links.
2. Profile.
3. Technical skills.
4. Projects.
5. Placement, internship, apprenticeship, freelance, or work experience.
6. Education and certifications.
7. Additional evidence such as hackathons or volunteering.

The difference is emphasis, not quality. A junior CV can still be strong if the projects are explained well and the CV is honest about experience level.

Avoid turning the skills section into a wall of keywords. Group it like this:

Languages: Python, TypeScript, JavaScript Backend: Django, FastAPI, Node.js, Express Data: PostgreSQL, Redis, MongoDB Cloud and tooling: AWS, Docker, GitHub Actions, Linux Quality: Pytest, Jest, integration testing, code review, OpenAPI

This is easier to scan than a single line of thirty tools. It also helps you tailor the order for each role.