What Belongs on an Engineering Resume

An engineering resume gets two readings. First a fast one — someone skimming to decide whether to keep reading at all. Then, if it survives, a slower one by an engineer who wants to know whether you’ve done work like the work they have.

Both readings want the same things and neither wants most of what people put on the page. Here’s a section-by-section account of what earns its space.

Contact block: four lines, no more

Name, email, city, and one link. That’s it.

The link should be whichever of GitHub, a personal site, or LinkedIn actually helps you — usually GitHub if it has anything on it, a personal site if you write, LinkedIn as a fallback. Listing all three when two are empty is worse than listing one.

Cut: full postal address (nobody needs it and it’s a privacy giveaway), date of birth, marital status, photo. Those last few are conventional in some countries and strongly discouraged in others; if you’re applying internationally, check the norm for the destination rather than yours.

Summary: two lines or none

A summary is worth it if you have something to position: you’re changing specialism, you’re returning after a break, your recent title doesn’t match what you’re applying for, or your experience is spread across two areas and you want to say which one you’re leading with.

Backend engineer, seven years, mostly Go and Postgres in payments and billing. Comfortable owning a service end to end including its on-call. Currently deepest in event-driven systems and idempotency problems.

If your last two job titles already say it, skip the section. A summary that reads “Experienced software engineer with a passion for clean code and solving challenging problems” is worse than an empty space, because empty space at least doesn’t waste the reader’s first five seconds.

Experience: the entire point of the document

This is where 70% of the page should go.

Per role: title, company, dates, and three to five bullets. A one-line note on the company if it isn’t well known — Northwind (B2B logistics SaaS, ~80 engineers) — costs you six words and saves the reader from guessing at the scale you worked at.

What the bullets should cover, roughly in order of how much reviewers care:

What you owned. Services, systems, or areas where you were the person responsible.
What you built or changed, and what problem it solved.
Scale, where it’s genuinely notable. Request volume, data size, team size, number of services. Only if the real figure is interesting — “handled 40 requests per second” is not a selling point and drawing attention to it hurts.
Technical decisions you made, especially trade-offs. Senior signal.
Anything cross-cutting: mentoring, on-call ownership, incident response, hiring involvement.

More on the craft of the bullets themselves in writing engineering bullets that say something.

Weight by relevance and recency, not evenly. The current job might get five bullets, the one before it three, and anything more than eight years back a single line — or a grouped “Earlier roles” block. Nobody applying for a senior backend job needs four bullets about a 2015 internship.

Skills: shorter than yours currently is

A grouped list of technologies you’d be comfortable being interviewed on. Grouped, not a wall of comma-separated nouns:

Languages Go, Python, TypeScript, SQL Data PostgreSQL, Redis, Kafka Infrastructure AWS (ECS, RDS, S3), Terraform, Docker, GitHub Actions Practices Distributed tracing, load testing, incident response

Cut anything you’d have to caveat in an interview, anything that’s a baseline expectation (git, VS Code, “Agile”, “REST APIs”), and any proficiency rating system — the star bars and percentage circles convey no shared meaning and take up a quarter of a page. There’s a longer argument about this in the tech stack list problem.

Projects: conditional

Include a projects section if:

You’re early career and your work experience is thin.
You have something genuinely used by other people.
Your day job doesn’t demonstrate the skills you’re applying with — the classic case being an engineer whose work is all closed-source enterprise applying somewhere that cares about systems programming.

Skip it if you have five-plus years of relevant work experience and the projects are tutorials, course output, or a to-do app. In that situation they compete with your actual experience for attention and lose.

Covered properly in side projects, open source, and what counts.

Education: shrinks over time

New graduate: near the top, with degree, institution, year, and — if relevant — coursework, thesis, or a notable project.

Five years in: one line, near the bottom. Degree, institution, year.

Ten years in: one line, and dropping the year is fine.

Bootcamp: list it, name it as what it is, and let your projects and work carry the weight. Trying to disguise a bootcamp as something else fails, and it’s unnecessary — plenty of good engineers came through one.

Certifications go here too, if they’re current and relevant. Cloud certifications carry real weight for infrastructure roles and almost none for product engineering roles. Read the job before deciding how much space to give them.

What to cut entirely

Objective statements. “Seeking a challenging role where I can grow my skills.” About you, not them, and universally true.
Skill bar charts and percentages. What is 80% Python? Nobody knows.
“References available upon request.” Assumed. It’s a line of nothing.
Soft-skill adjective lists. “Team player, excellent communicator, detail-oriented.” Unverifiable and identical across every applicant. Demonstrate these in bullets about mentoring, incident comms, or design docs instead.
Every technology you’ve ever touched. See above.
Non-relevant early jobs, unless there’s a gap to account for. Your two years in retail can be one line or nothing.
Hobbies, unless genuinely interesting or relevant. “Reading, travelling, music” is filler.

Length and format

Two pages is normal for anyone past a few years of experience, and one page is normal for early career. The one-page rule is a US early-career convention that got globalised by the internet; plenty of good engineers in plenty of markets submit two. What’s not fine is two pages where the second is padding.

Single column, standard headings, plain text, no graphics. This is partly about how the document gets machine-read and partly because a fast human reader wants a predictable shape.

The ordering question

Default order for an experienced engineer:

Contact → Summary (optional) → Experience → Skills → Projects (optional) → Education

For a new graduate, move Education and Projects above Experience — that’s where your evidence actually is, and nobody expects otherwise.

The general principle: put the strongest evidence for this specific application in the top half of page one. Everything else is arrangement.