LUCERIA
Sign in
Software and technology · Mid level · UK and US conventions noted

Software engineer (backend): resume example, explained

This fictional example shows a backend engineer building services since 2020 and applying for a senior role: the stack named plainly, every service given a scale figure, and incident response, code review and testing written as checkable work rather than personality traits. Four decisions are explained, three weak bullets are rewritten from the evidence behind them, and the editable download lets you replace every detail with your own. Nothing here describes a real person, employer or system.

Illustrative example. An illustrative, invented backend engineer at two fictional product companies since 2020, applying for a senior backend engineer role at a mid-sized software company. Every employer, system, figure and link is fictional.

Editable version of this example (.docx)

The example document

Priya Venkataraman-Hale

Backend Software Engineer · TypeScript, Go and PostgreSQL · Distributed systems and reliability

Manchester (hybrid; open to remote) · 07700 900 214 · priya.vh@example.com · code and write-ups: example.com/priya-vh

Profile

Backend engineer building and running services since 2020 and working on a fictional invoicing and ledger platform used by around 1,200 business customers since 2023. Owns the ledger-posting service that records roughly 3 million transactions a month, takes part in its on-call rotation and reviews most of the team's pull requests. Looking for a senior role with design ownership across service boundaries.

Experience

Software Engineer (Backend) — Fictional Ledger Software Ltd

March 2023 – present · Invoicing and ledger platform for small businesses; team of six engineers; services in TypeScript (Node.js) and Go on PostgreSQL.

  • Own the ledger-posting service that records around 3 million transactions a month, including its schema, API contract and runbook; p95 latency for posting calls has stayed under 120 ms through two years of growth.
  • Redesigned the reconciliation job from a nightly batch to an incremental queue consumer, cutting the morning reconciliation window from about four hours to under 20 minutes and removing the most frequent weekend on-call page.
  • Led the response to a 2025 payments-posting incident as incident commander, restored service within 40 minutes and wrote the blameless post-mortem whose three actions were completed within one sprint.
  • Review around 15 pull requests a week across the team and introduced a one-page design-note template for changes that touch more than one service; six notes were written in the first quarter.
  • Raised the service's line coverage from roughly 55% to 85% with contract tests against the API schema and a replayable fixture set of 2,000 synthetic transactions.

Software Engineer (junior, then mid-level) — a fictional online grocer

September 2020 – March 2023 · Order and delivery-slot services; team of eight.

  • Built the delivery-slot availability endpoint in Go, serving about 400 requests a second at the evening peak, with a cache layer that cut database reads for slot lookups by roughly 70%.
  • Migrated the order-history read path to a dedicated read replica over three releases with no customer-visible downtime.
  • Joined the on-call rotation after nine months and handled around two pages a month, documenting each fix in the team runbook.

Education

  • BSc (Hons) Computer Science, Fictional University, 2020

Projects (described here; links on the contact line)

  • Ledger replay tool (personal, open source): a command-line tool that replays a day of synthetic ledger events against a local database to test migrations; around 1,100 lines of Go with a test suite and a readme explaining the design.
  • Write-up: 'Reconciliation from batch to stream', a short article on the trade-offs behind the queue-consumer redesign, with diagrams.

Skills

TypeScript (Node.js) and Go services · PostgreSQL schema design, indexing and migrations · Message queues and idempotent consumers · Observability: structured logging, metrics, tracing (OpenTelemetry) · Incident response, on-call and blameless post-mortems · Contract and integration testing; CI pipelines · Code review and written design notes

Bullet rewrites, and the evidence behind them

Each rewrite was produced by asking an evidence question and using only the (fictional) answer. No number appears in a rewrite that is not in its evidence.

  1. Before

    Worked on backend services for the ledger platform using Node.js and Go.

    Evidence question

    Which service did you own, what volume does it handle and what did you keep within bounds?

    Evidence (fictional)

    Owns the ledger-posting service (schema, API contract, runbook); around 3 million transactions a month; p95 latency for posting calls under 120 ms for two years.

    After

    Own the ledger-posting service that records around 3 million transactions a month, including its schema, API contract and runbook; p95 latency for posting calls has stayed under 120 ms through two years of growth.

  2. Before

    Improved the reconciliation process.

    Evidence question

    What was the design change, what did the window go from and to, and what stopped happening?

    Evidence (fictional)

    Replaced a nightly batch with an incremental queue consumer; reconciliation window fell from about four hours to under 20 minutes; the weekend on-call page it caused stopped.

    After

    Redesigned the reconciliation job from a nightly batch to an incremental queue consumer, cutting the morning reconciliation window from about four hours to under 20 minutes and removing the most frequent weekend on-call page.

  3. Before

    Helped with incidents and wrote post-mortems.

    Evidence question

    Which incident, what was your role, how long did restoration take, and were the actions completed?

    Evidence (fictional)

    Incident commander for a payments-posting incident in 2025; service restored within 40 minutes; three post-mortem actions (idempotency keys, alert thresholds, replay tooling) completed within one sprint.

    After

    Led the response to a 2025 payments-posting incident as incident commander, restored service within 40 minutes and wrote the blameless post-mortem whose three actions were completed within one sprint.

Try it on your own bullets with the bullet workbench, which asks the same questions and never adds a figure you did not supply.

Transferable skills in this example

  • Designing for failure

    Evidence: Idempotent consumers, replay tooling and a rewritten batch job that stopped a recurring page.

    Where it helps: Platform and reliability roles, data engineering, and any product team that runs its own services.

  • Structured incident response

    Evidence: Incident commander role, timed restoration and a post-mortem with tracked actions.

    Where it helps: Engineering management, technical programme roles and security operations.

  • Reviewing other people's work constructively

    Evidence: Around 15 pull-request reviews a week and a design-note template the team adopted.

    Where it helps: Tech lead and staff engineer tracks, developer-experience teams and technical writing.

  • Explaining a technical trade-off in writing

    Evidence: A published write-up on batch versus stream reconciliation and a readme for every project.

    Where it helps: Solutions engineering, developer relations and product roles between engineers and customers.

Occupation notes

Hard requirements

  • Software engineering is unregulated: there is no licence or registration to state. The hard requirements come from the advert: the employer's must-have stack (named in the headline and skills only if you genuinely use it), right to work in the country of hire (checked through the verified employer process at the stage required in that country, not on the resume) and, for some public-sector or defence employers, a security clearance you should mention only if you hold it.
  • Where an advert asks for 'commercial experience with X', the bullets must show X in production; a course alone does not meet the requirement.

Vocabulary that belongs on the page

  • Service ownership, runbook, on-call rotation, paging
  • p95 / p99 latency, throughput (requests a second), error budget
  • Idempotency, retries, back-pressure, queue consumer
  • Incident commander, blameless post-mortem, action items
  • Pull request, code review, design note / RFC
  • Contract tests, integration tests, fixtures, CI pipeline
  • Read replica, migration, schema change, index

Pitfalls specific to this occupation

  • Listing every language and framework ever touched; a software engineer's skills line is probed in the technical interview and a stale entry invites a question you cannot answer.
  • Writing 'built the platform' when the team built it; name your slice (the service, the migration, the incident) because 'what exactly did you do?' comes first in any engineering interview.
  • Pasting raw repository URLs with no description, so the reader cannot tell a tutorial clone from a designed tool.
  • Giving scale without context, such as 'handled millions of requests' with no period, latency target or statement of what you changed.

UK and US differences

  • UK: Two pages is normal for a mid-level software engineer resume in the UK; keep the current role and the projects on page one.
  • US: A US resume for an engineer at this level is usually concise: drop the second role's context line if space is tight and keep the figures. Right-to-work and sponsorship questions belong in the application form, not on the resume.

Common questions

Should a software engineer resume include a projects section after several years in work?

Yes, when a project shows a design decision, tests and a readme that the day job does not. Describe each in a line or two and link once; leave off tutorials and anything you could not walk through in an interview.

How much detail about scale and latency belongs on a software engineer resume?

Enough for a reviewer to place the system: volume per period, a latency or availability target and what you changed. Use rounded figures you can defend and that do not disclose confidential numbers.

Keep going

Published 6 November 2026 · Every person, employer and figure in this example is fictional. Drafted with AI assistance and checked against Luceria’s editorial standards.