Backend Developer CV Guide: APIs, Skills and Examples

A backend stack only becomes meaningful when the reader knows the system behind it. Python, Django, PostgreSQL and AWS could describe a small internal tool, a customer-facing SaaS product, a data-heavy platform or a public API. Add the service context early so the stack has a job to do. A Backend Developer CV is easier to trust when the reader can see the product, platform or operational setting behind the code.

For example, instead of opening with Backend developer with five years of Python experience, write something closer to Backend developer specialising in Python services, REST APIs, PostgreSQL data modelling and AWS-hosted product platforms. The second version gives the reader a shape: language, service type, database and environment.

That context is especially useful when your work sits below the visible product. Recruiters may not understand the full architecture, but they can understand payment integrations, subscription services, high-volume booking APIs, order processing, identity and access services, data ingestion or internal platform tooling.

A backend developer CV often has two audiences. The recruiter checks title match, commercial context, location, salary band, right-to-work details and basic stack fit. The technical reviewer looks for service ownership, design judgement, testing habits, operational awareness and evidence that you understand trade-offs.

You do not need separate sections for those audiences. You need sentences that work at both levels. A recruiter can understand reduced API response times by 38% for the checkout service; an engineering lead can ask follow-up questions about caching, query plans, payload shape, profiling and test coverage.

That is why vague claims such as worked on scalable backend systems are weak. They sound relevant, but they do not give either reader enough to trust. Replace them with proof: what scaled, from what level, under which constraint, and what changed after your work.

Backend vacancies are not interchangeable. One job may care about API design and integrations. Another may care about data processing, cloud migration, platform reliability, payments, security, AI service integration or legacy modernisation. The first page of your CV should move toward the problem in the advert.

Before you edit, mark the vacancy for repeated signals: language, database, cloud provider, architecture style, domain, team shape and reliability expectations. Then adjust your profile, skills order and first three experience bullets so they answer those signals directly. The CV tailoring guide is useful when you need a repeatable process for this.

Tailoring does not mean rewriting your whole career history. It means choosing the most relevant evidence first. A tailored Backend Developer CV should make the vacancy's main backend problem visible in the profile, skills and first experience section. If the role mentions Kafka, event-driven systems and observability, an older but strong event-processing project may deserve more space than a newer CRUD feature with less relevance.

Your profile should not try to summarise every language you have touched. Use it to define your backend lane: the services you build, the level you operate at, the environments you know, and the kind of value you bring. Keep it to three or four lines unless you are writing an executive or principal-level CV.

A good Backend Developer CV profile usually includes role level, core stack, service context and one or two evidence areas. For example: Backend developer with six years' experience building Java and Kotlin services for payments and subscription platforms. Skilled in REST API design, PostgreSQL optimisation, AWS deployment and CI/CD, with recent work reducing payment retry failures and improving release confidence through integration testing.

Notice what that profile avoids. It does not say passionate, motivated or hard-working. It does not list ten tools. It tells the reader what the candidate has been trusted to build and where the most relevant evidence will appear in the experience section.

For junior developers, the profile can still be specific. Lead with placement projects, apprenticeship work, university systems modules, GitHub projects or support-engineering exposure. The National Careers Service software developer profile lists common entry routes and duties, but your CV should go further by showing what you have actually built, tested or maintained.

A backend skills section works best when grouped. Long comma-separated lists are hard to scan and can make shallow experience look the same as deep experience. Group skills by programming languages, backend frameworks, databases, cloud and DevOps, testing, observability and architecture.

Be honest about depth. If you used Redis on one project, do not place it beside a language you use every week without context. You can show depth through order, grouping and nearby experience bullets. A skill mentioned in the profile and then backed by two recent achievements feels credible. A skill hidden in a list of thirty tools does not.

A practical structure might be: Languages: Java, Kotlin, TypeScript; Backend: Spring Boot, Node.js, Express, REST, GraphQL; Data: PostgreSQL, MongoDB, Redis, schema design, query optimisation; Cloud and delivery: AWS, Docker, GitHub Actions, Terraform basics; Quality: JUnit, contract testing, integration tests, API monitoring.

Match this to the vacancy. If the job is for a Python API role, Python, FastAPI, Django, PostgreSQL and pytest should be easy to find. If it is a platform-heavy role, Kubernetes, Docker, observability, CI/CD and cloud services may deserve more prominence. The skills on CV guide can help you decide what belongs in a skills section and what belongs in work experience instead.

Your work experience is where the backend developer CV either becomes convincing or stays generic. Recruiters see many bullets that say built APIs, fixed bugs or worked in Agile teams. Those are duties, not evidence. Turn each important duty into a short story of problem, action and result. In a Backend Developer CV, that story usually needs a system change as well as a tool name.

A useful backend bullet often follows this shape: Built or improved X, using Y, to achieve Z. For example: Reworked customer search endpoints in Node.js and PostgreSQL, adding indexed filters and response caching that cut median response time from 820ms to 310ms during peak usage. That bullet gives the system, stack, action and outcome.

Not every result needs a percentage. Scope can work too: number of services, users, requests, integrations, migrations, release cycles, incidents, queries, endpoints or environments. If you cannot share commercial numbers, use operational language: reduced manual support work, removed duplicate data entry, improved deployment confidence, simplified partner onboarding, made audit reporting easier.

Use your most technical bullets where they support the job target. A backend developer applying for API roles should show endpoint design, authentication, rate limiting, contract testing and integration work. A backend developer applying for data-heavy roles should show schema design, ETL, data validation, query performance and reporting reliability. A backend developer applying for cloud-native roles should show deployment, scaling, observability and incident learning.

Projects can strengthen a backend CV when they show something your paid roles do not. This is especially useful for junior developers, career changers, contractors, bootcamp graduates and developers moving from full-stack or support roles into backend engineering.

Do not add a project because the CV feels short. Add it because it proves a capability: designing an API, modelling data, securing authentication, deploying a service, writing tests, documenting endpoints or handling background jobs. Include the problem, stack, your decisions and the outcome. A small but well-explained project beats a large project described as built a web app.

For example: Built a FastAPI expenses service with PostgreSQL, JWT authentication, role-based permissions and Dockerised local development; added pytest coverage for core workflows and documented endpoints with OpenAPI. This gives a technical reviewer something concrete to inspect.

If the project is public, link to the repository or demo only when it is tidy enough to support your application. A neglected repository with no README, no tests and broken setup instructions can work against you. If the work is private, describe it clearly without exposing confidential data.

A computer science degree, software engineering degree, apprenticeship, bootcamp or professional course can help, but it should not take more space than your evidence deserves. Recent graduates may put education above experience. Experienced backend developers usually keep it shorter and place it after work history or skills.

For each qualification, include the qualification name, provider and dates. Add modules or projects only if they relate to the role: distributed systems, databases, algorithms, cloud computing, security, networking, software architecture or data engineering. For apprenticeships, highlight workplace evidence as well as the qualification.

Certifications can be useful when they match the vacancy. AWS, Azure, Google Cloud, Kubernetes, security, database or Scrum certifications may support a backend role, but they should not replace delivery evidence. Treat them as proof of learning or platform familiarity, not proof that you can run production services alone.

The UK's Digital Data and Technology profession has a developer role framework that can help you think about progression signals, especially for public sector or government-adjacent roles. Use frameworks as a prompt for evidence, not as wording to copy into your CV.

Backend CVs can become dense because the work has many layers: language, framework, API, database, infrastructure, testing, monitoring, security and collaboration. Formatting has to reduce that load. Use clear headings, consistent dates, short bullets and enough white space to let technical evidence breathe.

Two pages is usually right for a mid-level or senior backend developer in the UK. One page can work for an early-career developer with limited experience. Three pages is rarely necessary unless you are applying for a highly specialised senior, contract or academic-adjacent technical role where project history matters.

Keep the first page focused on the target role: profile, core skills and most relevant recent experience. Move older or less relevant roles down. If a previous job was not in backend development, translate it into relevant evidence such as stakeholder communication, systems support, data handling, troubleshooting, analysis or operational ownership.

For structure, use the CV structure guide and the ATS-friendly CV guide. Backend CVs still need simple headings, readable fonts and standard section names so parsing tools and busy recruiters can find the information they expect.

For a mid-level API role: Backend developer with five years' experience building REST and GraphQL services for SaaS platforms. Confident with Node.js, TypeScript, PostgreSQL and AWS, with recent work improving API performance, integration reliability and release testing across customer-facing services.

For a Python backend role: Python backend developer focused on Django and FastAPI services, PostgreSQL data models and asynchronous task processing. Experienced in building internal APIs, improving query performance and supporting production systems with clear logging, tests and documentation.

For a senior backend role: Senior backend developer leading service design, technical discovery and delivery for Java/Kotlin microservices. Strong record across API standards, data modelling, reliability improvements, incident learning and mentoring developers through code review and pairing.

• Designed and delivered a new partner onboarding API in Spring Boot, reducing manual setup work for operations teams and giving partners clearer validation errors during integration.
• Optimised PostgreSQL queries and added targeted caching for account dashboards, cutting load time during peak weekday traffic and reducing support complaints about slow reporting.
• Migrated a legacy scheduled job into an event-driven queue worker, improving retry behaviour and making failed processing easier to investigate through structured logs.
• Added contract tests between backend and frontend teams, reducing release blockers caused by unexpected API response changes.
• Reworked authentication and role checks for an internal administration service, closing access-control gaps and documenting permission behaviour for future maintainers.
• Built Docker-based local development scripts and CI checks that helped new developers run the backend service without manual environment setup.

If you have less commercial experience, lean into specificity. A bootcamp, apprenticeship or personal project can still show backend thinking if the wording explains decisions and quality habits.

• Built a booking API using Node.js, Express and PostgreSQL, including validation, migration scripts, unit tests and API documentation for the core reservation flow.
• Completed a software development apprenticeship rotation supporting .NET services, fixing production defects, writing regression tests and documenting release notes for support colleagues.
• Created a Django portfolio project with user authentication, permission checks and background email tasks, then deployed it with Docker and documented local setup in the README.

The pattern is the same at every level: state the system, show your action, name the technology where it helps, and explain the result. The software engineer CV guide can help if your experience is broader than backend work, while the Python developer CV example is useful when your backend evidence is language-specific.

Tool lists are useful, but they cannot carry the whole CV. Java, Spring, PostgreSQL, AWS, Docker, Kubernetes tells the reader what might be relevant. It does not prove what you did with those tools. Every important skill should connect somewhere to a project, role or achievement.

Fix this by choosing the five to eight most important tools for the target role and making sure your recent experience proves them. If PostgreSQL is in your top skills, include a bullet about schema design, query optimisation, migrations, data quality or reporting. If AWS is prominent, show what services you used and what you improved.

Backend developers often undersell themselves by writing bullets that could belong to any developer. Worked on new features, fixed defects and supported releases are too broad. They hide the service-layer decisions that make you suitable for the role.

Fix this by naming the backend object: API endpoint, data model, queue worker, integration, authentication flow, payment service, reporting job, deployment pipeline or monitoring dashboard. Then add the result.

The opposite problem is too much detail. A CV is not a design document. You do not need to explain every class, service boundary, message schema or deployment step. Too much architecture can make your CV harder to scan, especially before it reaches a technical reviewer.

Fix this by keeping each bullet to one main idea. If the architecture detail is important, use it to explain a decision or outcome: split reporting jobs from the request path to reduce timeout failures, not a paragraph of internal design history.

Backend roles often involve maintaining services after release. If your CV only describes feature building, it may miss reliability, incident response, monitoring and support. Production ownership is especially important for mid-level and senior roles.

Fix this by including evidence of logging, metrics, alerts, runbooks, incident learning, on-call support, rollback planning or monitoring improvements. You do not need to overstate ownership. Be clear about whether you led the work, contributed to it or supported it as part of a team.

AI coding tools are now part of many development workflows, but a CV should not imply that you rely on generated code without understanding it. Recruiters and engineering leads care about judgement, maintainability, security and testing. Recent discussion around AI-assisted coding has also made review discipline more important, not less.

Fix this by framing AI use around safe workflow habits when it is relevant: test generation, refactoring support, documentation drafts, debugging prompts or code review preparation. Keep the emphasis on your engineering decisions, review, tests and final responsibility for code quality.