Full stack is the hardest title to make credible on paper, because it is the one most often claimed without evidence. A reviewer who has hired before assumes a "full stack" applicant is strong on one side and passable on the other, and spends the first read working out which side is which.
The way to answer that is to show a feature you carried across the whole boundary: the schema you designed, the endpoint you wrote, the interface that consumed it, and what happened in production afterwards. One such story does more than a skills list twice as long.
This example is written for a developer with around six years of experience working in a small product team, where the same person is expected to design a table, ship a screen and be on call for it.
Full stack developer with six years in small product teams, strongest on the back end: Node.js, TypeScript and PostgreSQL, with enough React to own a feature through to the browser. Recent work includes a payments integration processing around £2m a month and a query-tuning programme that cut dashboard load times by 90%.
Professional Experience
Senior Full Stack DeveloperMay 2022 – Present
Meridian Freight Systems · Lahore, Pakistan
•Own the shipment tracking service end to end: PostgreSQL schema, Fastify API, React dashboard and the on-call rotation that covers it.
•Built the carrier payments integration handling roughly £2m a month, including idempotency keys, a reconciliation job and an audit trail the finance team uses directly.
•Traced a 9-second operations dashboard to a missing composite index and a per-row subquery; the rewrite as a lateral join brought it to 240ms and removed the nightly caching workaround.
•Moved releases from manual deploys to GitHub Actions with blue/green on ECS, cutting release time from around 40 minutes to under 6.
•Wrote the decision record for moving off a shared database to service-owned schemas, and led the four-month migration with no customer-visible downtime.
•Built three client products from empty repository to production, covering authentication, billing, admin tooling and the customer-facing app.
•Introduced Prisma and a migration review step after a manual schema change caused two hours of downtime; no repeat incident in the following two years.
•Added Sentry and structured logging across the estate, which turned "the site is broken" reports into traceable errors and cut mean time to diagnosis noticeably.
•Interviewed and onboarded four developers, and wrote the onboarding guide that got new starters to their first merged pull request within a week.
•A command-line tool that reviews PostgreSQL migration files for locking operations that would block writes on a large table.
•Flags the six patterns responsible for most accidental table locks and suggests the concurrent equivalent.
•Used internally across three teams before being released publicly.
TypeScript · PostgreSQL · Node.js
github.com/example-aliraza/pgcheck
Education
BS Computer ScienceSeptember 2015 – June 2019
National University of Computer and Emerging Sciences · Lahore, Pakistan
•Final-year project: a distributed job queue with at-least-once delivery guarantees.
CGPA 3.6 / 4.0
Full Stack Developer example on the Technical layout. All details are fictional and shown for demonstration only.
What recruiters expect
Before writing anything, it helps to know what the person reading is checking for. In this field that is usually a short, specific list:
A primary stack stated plainly, and honesty about the secondary one. Teams hire for a gap, and they need to know which gap you fill.
Data modelling that is more than "used PostgreSQL": indexes, migrations, transactions, and what you did when a query got slow.
API design decisions - versioning, pagination, error shapes, authentication - rather than just the framework name.
Some operational responsibility. Deployments, monitoring, an incident you were part of, or an on-call rotation.
Evidence you can work without a specialist to hand: writing your own migrations, reading a flame graph, setting up CI.
Recommended CV structure
This is the running order the example uses. It is a starting point rather than a rule, but the order reflects what tends to be read first in this profession.
Profile — Three or four lines positioning you for the role.
Technical Skills — Grouped skills, for example "Languages" and "Tooling".
Professional Experience — Paid roles, in reverse chronological order.
Selected Projects — Work you built, with outcomes and the stack used.
Education — Degrees, diplomas and school-leaving qualifications.
Certifications — Completed certifications with the issuing body.
Languages — Spoken languages with CEFR levels.
Sections worth adding
Open Source — Useful when your commercial work is under NDA and cannot be described in any detail.
Technical Training — Worth a short block if you have completed a substantial cloud or security course.
Skills worth including
Grouped rather than listed in one block. Grouping makes a long list readable and shows that you can tell the difference between the things you use daily and the things you have touched.
Beyond the technical list: Technical decision records, Working directly with customers, Incident response, Scoping under a deadline, Interviewing candidates. These belong inside your experience bullets, demonstrated, rather than in a list of adjectives.
Example professional summary
Three or four lines, positioned for the role rather than describing your personality. Two versions you can adapt:
Full stack developer with six years in small product teams, strongest on the back end: Node.js, TypeScript and PostgreSQL, with enough React to own a feature to the browser. Recent work includes a payments integration handling around £2m a month and a query-tuning programme that cut dashboard load times by 90%.
Product-focused full stack developer comfortable from schema design to interface. Six years across two SaaS companies, including on-call ownership of the service I built and a habit of writing the decision record before the code.
Writing your experience
The difference between a CV that gets a call and one that does not is almost always in the bullet points. Each pair below shows a real rewrite of the kind of line that appears on most CVs in this field.
Weak
Developed REST APIs using Node.js.
Stronger
Designed and shipped the public booking API in Node.js and Fastify, including cursor pagination, idempotency keys for payment retries and a versioning scheme that let two mobile clients migrate independently.
Shows API design judgement, not just familiarity with a runtime.
Weak
Worked with PostgreSQL databases.
Stronger
Traced a 9-second dashboard query to a missing composite index and a subquery running per row; rewrote it as a single lateral join and brought it to 240ms.
Demonstrates diagnosis, not tool exposure. This is what a senior interviewer wants to talk about.
Weak
Helped with deployments.
Stronger
Moved the service from manual releases to GitHub Actions with blue/green deploys on ECS, taking release time from around 40 minutes to under 6 and removing the Friday deployment freeze.
Quantifies an operational change and names the practice it replaced.
Taken from the example
The sample CV for this profession is fully written. A few sections from it, so you can see the level of specificity that works:
Experience
Senior Full Stack Developer, Meridian Freight Systems
Own the shipment tracking service end to end: PostgreSQL schema, Fastify API, React dashboard and the on-call rotation that covers it.
Built the carrier payments integration handling roughly £2m a month, including idempotency keys, a reconciliation job and an audit trail the finance team uses directly.
Traced a 9-second operations dashboard to a missing composite index and a per-row subquery; the rewrite as a lateral join brought it to 240ms and removed the nightly caching workaround.
Moved releases from manual deploys to GitHub Actions with blue/green on ECS, cutting release time from around 40 minutes to under 6.
Projects
pgcheck — A command-line tool that reviews PostgreSQL migration files for locking operations that would block writes on a large table.
Education
BS Computer Science, National University of Computer and Emerging Sciences — CGPA 3.6 / 4.0
Certifications and registration
AWS Certified Solutions Architect – Associate — Amazon Web Services
Common mistakes
A stack list with no centre of gravity
Naming four languages and three clouds reads as unfocused. Lead with the stack you would be productive in on day one.
No database detail
Full stack CVs routinely skip the data layer entirely. It is the part interviewers probe hardest, and the easiest place to stand out.
Treating DevOps as a separate identity
If you wrote the pipeline that deploys your own service, say so inside the job. It does not need its own section.
Bullets that stop at "built"
Built what, for whom, at what scale, and what happened next. Three extra words carry the bullet.
ATS considerations
Applicant tracking systems behave differently by sector, and generic advice is often wrong for a given field. These points are specific to full stack developer applications:
State the primary language and runtime in the first line of the summary. Filters often score the top of the document more heavily.
Write "Node.js" rather than "Node", and include "PostgreSQL" as well as "Postgres" - job adverts use both.
Avoid a single "Skills" wall. Grouped headings survive parsing and make the human read faster.
If the advert asks for a cloud provider, name the specific services you used rather than only the provider.
The Minimal ATS layout is built for this, and the ATS guide covers what parsers do to a file in more detail.
Questions about full stack developer CVs
Should I say full stack if I am stronger on one side?
Yes, provided you say which side. "Full stack, back-end leaning" is credible and saves everyone a round of interviews. Claiming even strength when it is not true rarely survives a technical screen.
How do I show back-end work when the front end is what people see?
Describe the constraint you solved: throughput, latency, correctness under concurrency, or a migration with no downtime. Those are invisible from the outside and are exactly what the CV is for.
Do I need cloud certifications?
They help most when you are moving into a role that uses a provider you have not touched commercially. If you already run production on that provider, experience outweighs the certificate.
How many technologies should the skills section list?
Around twenty, grouped. Beyond that the list stops being read. Anything you would not want a forty-minute interview on should come off.