Software Engineer Resume Guide

Most engineering resumes are a list of technologies attached to a list of employers. What a hiring engineer is actually trying to work out is what you have built, how big it was, and whether anything changed because of you.

The bullet formula

Three components. Most bullets have one.

What you built or changed, technically specific. At what scale, so the reader can calibrate. What resulted, in a measure someone outside engineering would recognise.

Weak: Developed and maintained backend services using Java and Spring Boot. Worked in an Agile environment with cross-functional teams.

Strong:

• Rebuilt the payment reconciliation service handling roughly 2m transactions a day, cutting nightly batch time from 6 hours to 40 minutes
• Introduced read replicas and query caching for the account API, taking p99 latency from 800ms to under 120ms at roughly 4,000 requests per second
• Led the migration of 14 services off the legacy message bus over two quarters, with no customer-visible downtime

Each names the thing, the scale and the outcome. Note that the scale numbers are what make these credible: 2m transactions a day tells a reader far more about your working context than “high-volume”.

Use real figures. An invented latency number is the first thing a technical interviewer will probe.

Scale is the calibration signal

The single most useful thing you can add, and it is almost always missing.

Useful measures: requests per second, daily active users, data volume, transaction counts, number of services, team size, deployment frequency, cluster size, cost.

Two engineers can both say they built a recommendation service. One served 500 internal users and one served 40 million. Nothing else on the resume distinguishes them.

Where the technologies section goes

Near the bottom, grouped, and shorter than you think.

Languages: Go, Python, TypeScript, Java Infrastructure: AWS (EKS, RDS, Lambda), Terraform, Kubernetes, Kafka Data: PostgreSQL, DynamoDB, Redis, Snowflake Practice: distributed systems, observability, CI/CD, incident response

Two rules. Only include things you would be comfortable being questioned on for ten minutes, since an interviewer will pick from this list. And group them, because a flat list of forty items reads as undifferentiated and hides the four that matter.

Do not rate yourself out of five. Do not include HTML as a skill if you are a senior backend engineer. Do not list a language you used once in a tutorial.

Seniority changes what to lead with

Early career. Projects with visible outcomes, internships, and what you built rather than what you learned. One well-documented project beats a long technologies list. See the student resume guide and projects on a resume.

Mid level. Systems you owned, scale, and the outcome of your work. This is where the bullet formula above matters most.

Senior and staff. Technical direction, cross-team work, migrations, mentoring, and decisions you made including the tradeoffs. What distinguishes a senior resume is evidence of judgement rather than more technologies.

• Chose to keep the monolith and extract two services rather than a full decomposition, which the team completed in one quarter instead of the projected year

That sentence demonstrates seniority better than any list.

Management. Team size, hiring, retention, delivery outcomes. Keep enough technical detail to remain credible. See the executive resume guide for the scope-line technique.

Links, if they earn it

Code. Only if it is worth reading. A profile with one well-documented project and a clear README is a genuine asset. An abandoned profile of tutorial forks is worse than nothing, because a reader will look.

A site or writing. A technical blog with two or three real posts about problems you solved is unusually effective, because it demonstrates communication, which is the scarce skill at senior level.

One or two links, working, in plain text near your contact details.

What to cut

• Every soft-skill claim. “Strong problem solver” describes the entire profession.
• “Agile”, “Scrum”, “cross-functional teams” as bullet content. Everyone works this way.
• Rating bars and skill percentages, which parse as nothing and mean nothing.
• Coursework, once you have professional experience.
• A summary that restates your title. If you have one, make it about domain and scale.

Format and parsing

One page up to roughly eight years, two beyond. Plain, single column, no sidebar. Engineering candidates are the most likely to build a clever multi-column resume and it is the layout most likely to extract in the wrong order. See ATS resume templates.

If you use LaTeX, keep it single column and check the text extraction. See the LaTeX resume guide.

Check the document against a specific posting in the ATS checker, since large technology employers screen at volume and titles vary wildly between companies. See the job titles guide.

The O*NET profile for software developers is a reasonable cross-check on standard vocabulary, and the BLS wage statistics are worth reading by metro area before you negotiate.

Related

For adjacent technical roles, see the data science resume guide and the business analyst resume guide. For a specific market, see software engineer jobs in Los Angeles. For technical skills phrasing, see technical skills on a resume. To compare against other jobs, see resume examples by role.

Browse the developer templates or build one free.