Overview
Backend developer resumes fall into two categories. There are the ones that list 30 technologies and say nothing about what was built. And there are the ones that describe actual systems, with throughput numbers, latency improvements, and architecture decisions. Recruiters skim the first type. They read the second.
This resume belongs to Nathan Crewe, a backend developer with four years of experience building APIs and data pipelines in Python and Go. He currently works at THG (The Hut Group) on a logistics platform handling 840,000 daily orders. Before that, he built microservices at Patchwork Health, a health-tech startup that grew from 12 to 85 employees while he was there.
The resume works because every bullet describes a system, what it does, and how much traffic it handles. Let us go through it section by section.
Summary: languages, scale, and the system you own
For backend roles, the summary needs to answer: what languages do you write? What kind of systems do you build? And what is the scale?
Nathan's:
Backend developer with four years of experience building APIs and data pipelines in Python and Go. Currently working on the logistics platform at an e-commerce company handling 840,000 daily orders. Previously built microservices at a health-tech startup that grew from 12 to 85 employees during my time there.
Three sentences. Languages are named. Scale is given (840,000 orders/day). The startup mention adds context about working in a fast-moving environment. No buzzwords, no "self-motivated problem solver" filler.
For yours: Name your primary languages. Describe the system or domain you work in. Give a throughput or scale number. If you do not have one, use team size, number of services, or number of users.
Experience: describe the system, not the task
The biggest mistake backend developers make is writing task descriptions instead of system descriptions. "Worked on the backend" tells the reader nothing. "Designed and built the order routing service in Go that processes 840,000 orders/day" tells them everything.
Nathan's THG bullets:
Designed and built the order routing service in Go that processes 840,000 orders/day and selects optimal warehouse based on stock, proximity, and carrier cost
Reduced warehouse API response times from 1.2s to 180ms by introducing Redis caching and connection pooling
Built an event-driven returns pipeline using AWS SQS and Lambda, handles 23,000 returns per day with zero manual intervention
Each bullet follows the same pattern: what he built, what technology he used, and the measurable result. The latency improvement (1.2s to 180ms) is the kind of before-and-after number that immediately communicates competence. If you have ever improved response times, reduced error rates, or increased throughput, those are your best bullets.
The formula: System you built + Technology used + Throughput/performance number.
"Wrote API endpoints" becomes "Wrote and maintained OpenAPI specs for 31 internal endpoints consumed by 4 frontend teams." That second version shows scale and cross-team impact.
Startup experience: growth as a metric
Nathan's Patchwork Health role is interesting because he uses the company's growth (12 to 85 employees) as context. This tells the reader he was there during a period of rapid scaling, which means he dealt with changing requirements, growing systems, and probably some technical debt.
His bullets from that role:
Built a shift recommendation engine in Python (FastAPI) that matched 6,200 shifts per week based on worker skills, location, and availability
Migrated the monolithic Rails backend to 5 Python microservices, cutting deploy times from 25 minutes to 4 minutes
The monolith-to-microservices migration is a classic backend project. But the deploy time improvement (25 minutes to 4 minutes) makes it real. Without that number, it is just "we rewrote things." With the number, it is clear the migration had a practical benefit.
If you have worked at a startup, use growth metrics: users when you joined vs. when you left, revenue growth, team size change, or system scale increase. These paint a picture that a company name alone cannot.
Skills: keep it focused and grouped
Nathan lists 10 skills. Not 25. His list includes two languages (Python, Go), databases (PostgreSQL, Redis), cloud services (AWS with specific services named), infrastructure (Docker, Kubernetes, Terraform), and tools (Git, GitLab CI).
The specific AWS services matter. "AWS" alone could mean anything. "AWS Lambda, SQS, RDS, S3" tells the reader exactly which services you have used in production. If you have worked with specific GCP or Azure services, name them the same way.
One strong addition: Nathan has certifications for AWS Developer Associate and HashiCorp Terraform Associate. For backend roles, cloud and infrastructure certifications carry weight because they show you can operate the systems you build, not just write code.
The internship: it still counts
Even with four years of experience, Nathan includes his Sky Betting & Gaming internship. Two bullets:
Built a bet settlement reconciliation tool in Python that compared outcomes across 3 data sources and flagged discrepancies
Processed 2.1 million bet records during the tool's first live test weekend
That internship entry takes up very little space but adds a real company name and a concrete deliverable. If your internship involved building something that went to production (or even got used internally), include it. If you just shadowed people and attended meetings, you can probably leave it off once you have two or more full-time roles.
Mistakes backend developers make
Listing every technology you have ever touched. If you did one tutorial in Rust three years ago, do not put Rust on your resume. Only list technologies you could answer interview questions about. A focused list of 10 says more than a wall of 30.
No system context. "Built REST APIs" tells the reader nothing about what the APIs did, who consumed them, or how much traffic they handled. Always describe the system, not just the code.
Ignoring open source contributions. Nathan lists his FastAPI contributions. If you have merged PRs in any open source project, that is worth mentioning. It shows you can read other people's code, follow contribution guidelines, and get work accepted by maintainers.
Skipping the operations side. Backend developers are increasingly expected to own deployment, monitoring, and infrastructure. If you have written Terraform, set up CI/CD pipelines, or configured monitoring dashboards, put it on the resume. Many teams now expect backend engineers to handle the full lifecycle, not just write application code.
One more thing
Backend interviews are often heavy on system design. Your resume should give the interviewer natural starting points. Nathan's order routing service, his returns pipeline, and his shift matching engine are all systems that a hiring manager can ask "tell me about this" and get a 15-minute conversation. Design your bullets to be conversation starters, not just line items.
