How to write it
Lead with the stack, then prove you shipped with it
A recruiter screening developer applications is pattern-matching against a requisition: Go, Postgres, Kubernetes, five years. If those words aren't findable in the first third of the page, the resume can be excellent and still not survive the filter. That's the argument for a short summary that names the stack, and a skills block that isn't at the very bottom.
But naming the stack is only the ticket in. The engineer who reads it next has seen a hundred resumes listing the same ten technologies, and what separates them is whether anything on the page was hard. "Experience with Kubernetes" says nothing. "Migrated 14 services off a shared database with zero downtime" says you have done the thing that goes wrong.
Write bullets as outcome, not assignment
The most common failure in a developer resume is describing the ticket instead of the result. "Worked on the checkout flow" is a fact about your calendar. "Cut p95 checkout latency from 1.4s to 550ms" is a fact about the product, and it implies the work.
The pattern that holds up: what you owned, what you did to it, and the number that moved. Two of the three is usually enough. If you genuinely have no metric — plenty of good work has none — use scale instead: how many users, how much data, how many services, how big the team.
- Owned X → did Y → metric moved from A to B
- Built X, now used by N people / serving N requests
- Replaced X with Y, cutting cost/latency/incidents by N%
- Led the migration of X, completed with no downtime
Seniority is shown by scope, not adjectives
Nobody is convinced by "senior engineer with strong leadership skills". Scope convinces. A junior fixes bugs in a service; a mid-level owns features in it; a senior owns the service, decides its shape, and is the person other engineers ask. Write the sentence that only a senior could truthfully write, and the level takes care of itself.
Mentoring is worth one line and no more. "Mentor 3 engineers; two promoted to mid-level" is credible because it has an outcome attached. A paragraph about your leadership philosophy is not.
Projects earn their place only when they replace experience
If you have three years of professional work, a personal projects section competes with it for space and usually loses. Cut it, and put the one project that's genuinely impressive into your links.
If you're early — a bootcamp graduate, a career changer, a new grad — projects are the whole argument, and they should be treated like jobs: what it does, what you built it with, and something that proves it's real. Users, stars, uptime, a live URL. A tutorial to-do app with none of those attached reads as coursework, because it is.
Keep it to one page until it can't be
One page through roughly eight years, two after that if the second page is full of substance rather than a spillover of your skills list. The pressure that puts on the page is useful: it forces the oldest, weakest bullets out, which are exactly the ones that dilute the strong ones.
The internship from 2016 can go the moment you have two real jobs. So can the line about being a fast learner.