Software Engineer Resume Guide: Stack Fit, Scope, and Shipped Impact

A practical guide from the team behind PlainResume, the free resume builder.

An engineering resume gets two very different readers: a recruiter spending ten seconds matching keywords, and an engineer spending sixty judging what you actually built. Most resumes fail one audience or the other — a keyword wall that makes engineers wince, or elegant prose the ATS never surfaces. The fix is a division of labor: the skills section serves the recruiter, the bullets serve the engineer, and neither tries to do the other's job.

Skills: group by fluency, not alphabet

Twenty-five technologies reads as padding to every engineer who's interviewed anyone — nobody is fluent in all of that, so the list stops being believable exactly where you needed it to be. Eight to twelve, split by honesty tier, does more: recruiters still get their keywords (use the posting's exact terms for the stack you really use), and engineers get a claim they can trust. Two small tells they notice: correct names (PostgreSQL, GitHub, Node.js) and no filler rows — an IDE, an OS, and "Agile" are not skills.

Bullets: the system, your part, the number

The unit of engineering work is not the ticket — it's the system that changed. Every strong bullet names the thing, your role in it, and what moved:

The verbs carry your level, so scope them honestly (the action-verbs rule): built and owned claim more than contributed to, and an interviewer will probe exactly that line. Numbers don't need to be revenue — latency, throughput, error rates, incident counts, on-call load, team size on the thing you led. And engineering's special hazard, buzzword inflation, is a one-way ratchet down: call a CRUD app "AI-powered" and the reader discounts every other line.

Projects: for juniors, this is the experience section

Early-career engineers live and die on projects (the first-resume problem), and the bar is simple: deployed beats tutorial. One real thing with users — even twelve users — outweighs three todo-app clones, because it generates real bullets: what broke, what you measured, what you changed. Write project bullets exactly like job bullets: the system, your part, the number. Link GitHub only if the repo is presentable — a README, recent commits, code you'd defend live. An abandoned fork farm subtracts; no link is neutral, and working engineers whose code is all private can skip it without apology.

The rest, quickly

• Education: degree, school, year — one line after your first real job. New grads add relevant coursework; nobody else does.
• Format: single column, no skill-bar graphics, no photo, exported as a text-based PDF. Engineers judge signal-to-noise; decoration is noise.
• Length: one page for your first decade, pruning old roles to their best bullets as new ones land.

Frequently asked questions