Software Engineer Resume: What to Put In It (and What to Leave Out)

Engineering resumes get read twice: once by a recruiter scanning for keywords and level, and once by an engineer deciding whether you'd be good to work with. The first reader checks your stack and years; the second wants to know what you built, how hard it was, and whether it mattered. A strong software engineer resume serves both in a single page.

The software engineer resume example on this site follows every recommendation below. Open it alongside this guide.

The sections, in order

For most engineers with experience:

1. Header: name, city, email, phone, LinkedIn, and GitHub or personal site if it has real work on it.
2. Experience: reverse chronological, the bulk of the page.
3. Projects: optional; include one or two only if they show something your jobs don't.
4. Education: degree, school, year. Move it to the top only if you graduated in the last year or two.
5. Skills: grouped by category.

Skip the objective statement. A summary is optional; it helps when you're changing focus (say, from frontend to infrastructure) and wastes space otherwise.

Write bullets about systems and outcomes

The most common weakness in engineering resumes is bullets that list technologies instead of results: "Worked with React, Node.js, and PostgreSQL on the checkout team." That tells a reader your stack, which your skills section already does, and nothing about what you accomplished.

A stronger bullet names the system, your role, and a measurable outcome:

• "Rewrote the card authorization service in Go, cutting p99 latency from 480 ms to 95 ms at 3,000 requests per second."
• "Built merchant webhooks with retries, signing, and replay, delivering 12M events a day at 99.98% success."
• "Added end-to-end tests to CI, cutting production rollbacks from monthly to quarterly."

Good engineering metrics include latency, throughput, uptime, error rates, cost, build or deploy time, adoption, and revenue the system supports. If you don't have numbers, describe the scale (requests, users, data volume) or the concrete outcome (adopted by four teams, replaced a legacy system). Our guide to writing resume bullet points goes deeper on finding numbers.

Show your level, not just your tasks

The difference between a mid-level and a senior resume is mostly in what the bullets describe:

• Mid-level: shipped features end to end, owned services, improved performance.
• Senior: designed systems other people build on, led projects across teams, mentored, set technical direction, handled incidents.
• Staff and above: changed how the organization builds software: platforms, standards, migrations, multi-quarter technical strategy.

If you're applying for senior roles, make sure your bullets show design decisions, leadership, and influence beyond your own code, not only output.

The skills section

Recruiters and applicant tracking systems match your skills to the job description, so be specific and group them:

• Languages: Go, TypeScript, Python, SQL
• Infrastructure: AWS, Kubernetes, Terraform, GitHub Actions
• Data: PostgreSQL, Redis, Kafka

Only list what you could discuss in an interview. A skills section with 40 technologies reads as padding and invites questions you don't want. Drop proficiency bars and star ratings; they mean nothing to a reader and confuse parsers. See our ATS resume tips for more on keywords.

Projects: quality over quantity

Projects belong on your resume when they prove something your work history can't: open-source maintenance, a technology you haven't used at work, or users and traction. One project with 1,200 GitHub stars and outside contributors says more than five tutorial apps.

For new grads and career changers, projects matter much more. They often stand in for work experience. The new grad example shows a class project written with the same "action and result" structure as a job.

What to leave out

• Every technology you've touched. Keep the list to your working stack.
• Generic duties. "Participated in code reviews" and "attended standups" describe every engineer.
• Internal jargon. "Migrated Atlas to Hydra v2" means nothing outside your company. Say what the systems do.
• A photo, age, or full address. City and state are enough, and in many countries photos invite bias.
• GPA after your first job, unless an employer asks.

Formatting for engineers

Keep it to one page unless you have well over a decade of relevant experience (see how long a resume should be). Use one column, a clean sans-serif font, and consistent dates. Avoid dense two-column templates with skill meters; they're harder to read and often parse poorly.

Watch for bullets that wrap with one or two words on their own line. On an engineering resume full of dense technical bullets, these add up fast. dotresume flags them in the live preview so you can tighten them as you write.

Tailoring without rewriting

For each application, spend ten minutes reordering bullets so the most relevant work comes first and aligning your skills with the job's wording. If you use an AI coding agent already, it can do this for you: dotresume's agent API lets Cursor, Claude Code, or Codex edit your resume and check that it still fits on one page.

Start from the software engineer example, replace the details with your own, and download the PDF. It's totally free, with no account required.