The software engineer’s CV: stack and projects

An engineering CV is read twice by two people who want completely different things. A recruiter checks it against a list — years, languages, frameworks, location, notice period — in under a minute. Then, if it survives, an engineering manager skims it for about thirty seconds looking for one thing: is this person likely to be good at the work my team does?

Most engineering CVs are written for neither. They are a list of technologies attached to a list of employers, with the actual engineering — the systems, the decisions, the failures survived — left out entirely.

What the manager skims for

1. Current stack and depth. Not everything you have touched — what you would be productive in on day one.
2. Scope. The size and nature of the systems you have worked on. A CRUD app for 50 internal users and a payments service at 40k transactions a day are different jobs with the same job title.
3. What you personally did. “The team migrated to Kubernetes” tells them nothing about you.
4. Evidence of shipping. Things that reached production and stayed there.
5. Trajectory. Increasing ownership over time, or a plausible reason it changed.
6. Red flags. Unexplained gaps, six jobs in three years, a stack that has not moved in a decade, or claims that are obviously inflated.

Everything below is about getting those six things into the top half of page one.

The stack section

Put it directly under the summary, not at the bottom — it is the fastest read on the page and it is what the recruiter is checking. Group it, order the groups by what the advert asks for, and be honest about levels. No bars, no percentages, no star ratings.

Languages    Go (primary, 5 yrs), TypeScript (4 yrs), Python (scripting, data)
Backend      gRPC, PostgreSQL, Redis, Kafka, RESTful service design
Infra        Kubernetes, Terraform, AWS (EKS, RDS, S3, SQS), GitHub Actions
Practice     Code review, incident response and on-call, design documents,
             trunk-based development

Experience bullets that read as engineering

The useful pattern is what you built, the constraint it was built under, and what changed. The constraint is what separates an engineer from a list of nouns — anyone can add a cache; adding one without breaking read-after-write consistency is engineering.

Percentages are fine, but concrete units are better: milliseconds, requests per second, number of services, size of the dataset, size of the team. Round the numbers and never inflate them — a senior engineer interviewing you will ask how it was measured.

Projects: which ones earn their space

A projects section is essential early in a career and optional later, where it should only appear if it shows something your day job does not. The test is whether a reader learns something new about your judgement.

• It has users, or it solved a problem you actually had. A to-do app has neither.
• You can describe a real decision in it: why this database, why not a queue, what you would change.
• It is finished enough to run. A README with a screenshot and a two-command setup beats 20 abandoned repositories.
• It is recent, or the skill it demonstrates still matters.
• Three lines maximum on the CV: what it is, the stack, the one interesting thing.

Tramline - open-source CLI for staged database migrations (Go, SQLite)
Runs migrations in shadow tables and diffs the result before promoting.
~400 GitHub stars; used in CI at two companies I know of. Wrote the
conflict-detection logic and the docs.

Open source, honestly

Open source is a strong signal when it is real and a weak one when it is decorative. What reads as real: sustained contribution to a project you did not start, maintainership with issues and releases you handle, a merged change to something the reviewer has heard of, documentation work on a widely used library. What reads as decorative: forks, one-line typo fixes listed as “contributor to Kubernetes”, and star counts on repositories nobody uses.

If you contribute occasionally, say what you did rather than where: “merged three fixes to the Django ORM query compiler (2024–2025)” is specific and checkable. And if your public work is thin, leave the section out. Its absence is not read as a negative; a padded version is.

Links, and the state you leave them in

Link GitHub, a portfolio or a personal site only if a visitor will find something coherent within ten seconds. Before you add the link, do the ten-second test yourself: open it in a private window and see what a stranger sees.

• Pin three repositories that represent your current level, and give each a README that opens with what it is and why it exists.
• Remove or archive tutorial follow-alongs and dead experiments, or accept that they are the first thing a reviewer sees.
• Keep take-home solutions private — most companies ask, and publishing them helps candidates after you cheat.
• For a personal site, one page describing three projects beats a design-heavy site with nothing behind it.
• Write links in full text (github.com/yourname), not hidden behind “click here”, so they survive a printed CV and a plain-text parse.

Format and length

Single column, two pages, plain section headings. Engineering roles at larger companies almost always route through an applicant tracking system, and a two-column CV with a skills sidebar is exactly the layout that parses badly — see make your CV ATS-safe in 20 minutes. The technology templates here are built single-column with room for a stack block, projects and links.

The best engineering CVs read like a short technical postmortem of a career: here is what I built, here is what constrained it, here is what happened.

One last thing worth doing: before you send it, read your own CV as if you were interviewing yourself, and write down the five questions you would ask. If you cannot answer any one of them for twenty minutes, that line is a liability, not an asset.