Resume guide

Software Engineer Resume: Examples, Template, and What Reviewers Actually Look For

Most engineers are not rejected for lacking the skills. They are rejected because the resume describes a job category instead of the job in front of the reviewer. Here is the difference, in diffs.

Written from twenty years in engineering and engineering management, screening candidates at eBay, Sony PlayStation, Roche, and several medical device companies.

@@ the first pass @@

What happens to your resume before a human really reads it

The first pass on a stack of applications is not reading. It is pattern-matching. The reviewer holds one question — does this person plausibly do the job we wrote down? — and answers it from a handful of signals: your current title, your most recent employer, the top third of the first page, and whether the language of the posting appears anywhere in your document.

Before that, there is usually a keyword search inside an applicant tracking system. This is the step candidates most misunderstand. The system is not an adversary looking for reasons to reject you. It is a search index. A recruiter types terms pulled from the requisition, and resumes that use those terms come back. Resumes that describe the same work in different vocabulary do not.

Both filters reward the same thing: a resume written for one specific posting rather than for the general idea of your job. Almost nobody does this, because doing it properly takes forty-five minutes per application and you are applying to thirty.

@@ experience bullets @@

Six real rewrites

These are the patterns that come up most often on engineering resumes. In each case the underlying work is unchanged — only the description is different.

@@ page structure @@

The template that survives a first-pass screen

There is no magic layout, but there is a conventional one, and deviating from it costs you attention you cannot spare. Order matters more than styling: the reviewer reads top-down and stops early.

Contact

Name, city and state, email, phone, one link. No photo, no age, no street address, no marital status.

Summary

Optional. Two lines, concrete, naming your specialty and scope. If it could describe anyone applying, cut it.

Experience

Reverse chronological. Three to five bullets on recent roles, one or two on older ones. This is the section that gets read.

Projects

Only early career, or when unusually substantial. Delete once you have real production work to describe.

Skills

Grouped by category, limited to what you would be comfortable being interviewed on. No proficiency bars, no star ratings.

Education

Bottom, one or two lines. Moves to the top only for current students and very recent graduates.

Length

One page for most engineers. Two is defensible past roughly ten years, or with a substantial publication or patent record. But length is not really the constraint — a two-page resume whose second page is a technology inventory is weaker than a disciplined single page.

Format

PDF, unless the posting explicitly asks otherwise. A standard two-column layout parses correctly in modern systems. What does not survive is anything exotic: text inside images, tables used for layout, or fonts that fail to embed.

Links

Include a GitHub link only if the profile is genuinely maintained. An empty or abandoned profile is worse than no link, because a reviewer who clicks it forms an impression you did not intend.

@@ vocabulary @@

Use the posting’s words for the work you actually did

This is where most tailoring effort should go, and it is not keyword stuffing. It is translation.

You have spent six years calling something “backend infrastructure.” The posting calls it “distributed systems.” Same work, different vocabulary, and the recruiter’s search is running on theirs. If your resume never uses their term, you do not appear in the result set — regardless of how well you would do the job.

So read the posting and note the specific nouns: the systems, the scale language, the methodology names, the exact product terms. Then find the places in your own history where you did that thing, and describe it in their words. The constraint is honesty — you are relabeling work you genuinely did, not claiming work you did not.

Three tactics that are not worth your time, because they do not do what people believe:

• White text behind the margins. It renders as visible garbage to the human who opens the file next. It does not hide.
• Stripping all formatting to plain text. The parser was fine either way. The human now has a wall of text.
• Targeting a keyword density percentage. There is no threshold being measured. There is a search being run.

@@ common failures @@

What gets strong engineers filtered out

• Describing the team’s work rather than yours. “We built” and “helped with” leave the reviewer unable to tell what you personally did, and they will not give you the benefit of the doubt at volume.
• No numbers anywhere. Not every bullet needs a metric, but a resume with none reads as someone who never measured their own impact.
• Equal space to obsolete work. A role from 2009 does not need four bullets. Compress older experience aggressively; recency dominates the read.
• Title inflation or vagueness. An invented internal title that maps to nothing outside your company should be translated into the industry-standard equivalent, with your real title alongside if needed.
• The same document sent to forty postings. This is the big one. It is also the one everyone knows about and skips anyway, because the manual version is genuinely too slow to sustain.

A note on experience level

Early-career and senior resumes fail differently. If you are new, your problem is having little professional work to point at, and the answer is projects described with the same specificity as jobs — what you built, what it handled, what you would change. If you are senior, your problem is the opposite: too much material, and a tendency to list responsibilities rather than outcomes. At that level reviewers are looking for scope and judgment, not tool coverage.

@@ questions @@

Common questions

How long should a software engineer resume be?

One page for most people. Two past roughly ten years, or with a real publication or patent record.

Do applicant tracking systems reject PDFs?

No. This is the most persistent myth in the category. Modern parsers handle standard PDFs without difficulty. The actual failure is vocabulary mismatch, which no file format fixes.

Should I include personal projects?

Early career, yes — they substitute for professional experience. Once you have several years of production work, keep a project only if it is unusually substantial or directly relevant to the specific role.

Should I list every technology I have used?

No. A long undifferentiated list signals exposure rather than judgment, and it invites an interview question you cannot answer well. List what you would be comfortable defending.

Do I need a summary or objective?

An objective, no — they went out with fax numbers. A two-line summary can work if it is concrete about your specialty and scope. If it could describe any applicant, the space is better spent on your first bullet.

How much should I change between applications?

Less than people fear. Your history is fixed. What changes is emphasis, ordering, and vocabulary — which bullets lead, which get cut, and whether you are using the posting’s terms for the work you did.