Backend Developer CV Examples & Writing Guide

A CV for a backend engineer with seven years of experience, currently owning a high-traffic API at a logistics software company. The name and companies are made up. Every bullet names the technology, the scale and a measured result, and the header links to GitHub, because reviewers will open it.

A technical recruiter screens for stack keywords and years, then an engineering manager or senior engineer reads the page in about a minute and opens your GitHub. They are trying to answer four questions.

• Does the stack match? Language, framework, database, message broker, cloud. Close matches count (Go and Python, PostgreSQL and MySQL); a CV with no stack in the personal statement gets skipped.
• What scale? Requests per second, events a day, database size, number of users or customers, team size. "Built scalable systems" is not a scale. "12,000 requests per second, 4 TB PostgreSQL" is.
• What did you own? A service, an API, a pipeline, a migration, on-call. Ownership from design through production says more than a list of technologies touched.
• Can you show results? Latency, error rate, uptime, cost, deploy frequency, incident count, test coverage. Two or three of these on each job is enough.

“The bullets I trust name the system, the technology and one number: p95 went from here to there, incidents dropped from this to that. Then I open the GitHub link. If there is no link, or the repos are empty tutorials, that tells me something too.”

Many people search "backend developer CV github" and "backend developer CV linkedin" because they are not sure where the links go or what should be behind them. Put both links in the header, then make sure what the reviewer finds there backs up the CV.

• GitHub: pin 3 to 6 repositories that show backend work: an API with tests and a README that explains how to run it, a small service with Docker and CI, a contribution to an open-source project. Archive or unpin half-finished tutorials. Add a one-line description to each pinned repo.
• Projects section (mostly for early-career developers): 2 to 3 projects, each with the stack, what it does, one technical decision you made and one number (requests handled in a load test, rows processed, test coverage, users). Link the repo.
• Open-source contributions: name the project and what you changed ("fixed connection-pool leak in X, merged in v2.4"). One merged pull request to a real project is worth more than ten personal repos.
• LinkedIn: keep the headline and job titles identical to the CV; recruiters check for mismatches. Turn on the open-to-work setting for recruiters only if you want inbound messages.
• Employer code you cannot share: describe it on the CV (system, stack, scale, result) and say in the interview that it is proprietary. Nobody expects to see production code from your day job.

Three lines: years and stack, the system you own and its scale, two measured results, and a certification or specialty if relevant. Write it for the job you are applying to and swap the order of technologies to match the job advert.

A strong backend bullet names the system, the technology, the scale and a measured before-and-after. Here are seven common weak lines rewritten with real backend work.

People search "what skills do you need to be a backend developer" and "skills required for backend developer" as much as they search for CV examples, so here is the list hiring managers expect, grouped the way a CV should group it. List 12 to 18 items, only ones you could discuss for ten minutes in an interview.

• Languages and frameworks: one primary language in depth (Python with FastAPI or Django, Java with Spring Boot, Go, Node.js with TypeScript, C# with .NET, PHP with Laravel, Ruby on Rails) and one or two you can read and fix.
• Data: SQL and one relational database well (PostgreSQL, MySQL), indexing and query plans, transactions and isolation levels, migrations; a cache (Redis); at least one NoSQL store (DynamoDB, MongoDB, Cassandra) if you have used it in production.
• APIs and messaging: REST design, OpenAPI, GraphQL or gRPC, authentication (OAuth 2.0, JWT), rate limiting, webhooks; message brokers (Kafka, RabbitMQ, SQS) and event-driven patterns.
• Cloud and infrastructure: one cloud provider's core services (AWS, Google Cloud or Azure), Docker, Kubernetes, Terraform or CloudFormation, CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Reliability and observability: logging, metrics, tracing (OpenTelemetry, Datadog, Grafana), SLOs, on-call, incident response, load testing.
• Engineering practices: testing (unit, integration, contract), code review, Git, system design, architecture decision records, security basics (OWASP Top 10, secrets management, least privilege).
• Leave off: Microsoft Office, HTML and CSS (unless the role is full stack), and "problem solving". Skill levels ("expert", 5-star ratings) are also unhelpful; the bullets show your depth.

UK job adverts call this level graduate, junior or entry level. Either way the hiring manager knows you have not run production systems. They are checking whether you can write working, tested code in a real stack, whether you understand databases and HTTP, and whether you finish things. Your CV proves that with projects, an internship or placement if you have one, and a GitHub that matches.

1. 1Header with GitHub and LinkedIn links, then a title line: "Backend Developer (entry level) · Python, PostgreSQL, Docker".
2. 2Personal statement of three lines: degree or bootcamp and date, your strongest project or internship with one number, your stack and one certification if you have it (AWS Cloud Practitioner, Oracle Java SE, a Kubernetes or database certificate).
3. 3Projects section above education: 2 to 3 projects, each with stack, purpose, one design decision, one number and a link. At least one should have authentication, a database with migrations, tests and a Dockerfile.
4. 4Internships, placements, part-time or freelance work, hackathons and open-source contributions in an experience section, written like real jobs: system, stack, scale, result.
5. 5Education with relevant modules (databases, operating systems, distributed systems, networks) and your degree classification, or predicted classification, if it is a 2:1 or above. One page. Skip generic soft skills; let the projects speak.

• Two pages is the UK norm for experienced developers; one page is fine for graduates and juniors. No photo, no date of birth, no full street address.
• Order: header with links, title line with stack, personal statement, skills grouped by category, experience, projects (early career) or selected systems (senior), education and certifications.
• Plain single-column layout in a standard font. Tracking systems (Greenhouse, Lever, Ashby, Workday) parse single columns reliably; two-column and icon-heavy templates often lose the skills section. Save as a text-based PDF named Firstname-Lastname-Backend-Developer.pdf.
• Write technologies the way job adverts do: "PostgreSQL" not "Postgres", "Node.js", "Kubernetes" (and "K8s" once if you like), "REST APIs", "CI/CD", "microservices", "AWS" plus the specific services.
• Keywords to mirror from the job advert: the primary language and framework, "backend" or "back-end" exactly as they spell it, "API", "microservices", "distributed systems", "SQL", the message broker, the cloud provider, "Docker", "Kubernetes", "CI/CD", "on-call", "system design".
• If you need visa sponsorship, or already have the right to work in the UK and the role attracts international applicants, one short line saying so saves the recruiter a question. Leave out marital status and nationality otherwise.

Run the finished CV through the cvplex ATS checker with the job advert pasted in. It flags technologies the job advert names that you left out, bullets without a scale or result, and formatting a tracking system may misread.