A Resume Guide for Software Engineers

Most people write a resume once, list their duties, and then wonder why nobody replies. This lesson shows a simple way to build one, based on one well-known public guide. It covers what to put in, what to cut, what is myth about applicant tracking systems (ATS), and how to rewrite weak bullets. It ends with a checklist.

This is the first lesson of the career series. The next lesson is a study plan for coding interviews, and the third is about practising with mock interviews. For the rounds that come after the resume, see Full-Stack Lesson 14 (the experience round) and Full-Stack Lesson 38 (behavioural questions, salary and offers). To see how a hiring decision looks from the other side of the table, read Team Lead Lesson 9.

Words used in this lesson

• Resume: a short document listing your work, skills and education. In the US it is the normal word; some countries say CV (curriculum vitae) for the same thing.
• ATS (applicant tracking system): software a company uses to collect applications, parse resumes into fields and let recruiters search and sort them.
• Parsing: the software reading your file and splitting it into fields such as name, job titles and dates.
• Recruiter: a person who finds and screens candidates before the engineers talk to them.
• Bullet: one line item under a job, describing one thing you did.
• Action verb: a strong first word for a bullet, such as "built", "cut", "migrated", "led".
• Scope: how big the thing was: users, requests, team size, data size, money.
• Keyword: a word from the job post, such as "React" or "PostgreSQL", that a person or a search tool looks for.
• Metric: a number that measures a result, such as "p95 latency down from 800 ms to 300 ms".

Who reads your resume, and for how long

Two kinds of readers see your resume, often in this order:

1. Software (the ATS) stores it and may help the recruiter search it.
2. A person (a recruiter, then an engineer or hiring manager) scans it, usually quickly.

The guide says the person is "quickly scanning for keywords of skills or experiences that they value" because they have little time for each resume. It does not give a number of seconds. You will often hear "six seconds" or "30 seconds" online; I did not find a number in the guide, so I treat it as folklore. What matters is the point behind it: assume a short, distracted read.

So design for a scan. In the first screen of the page a reader should be able to answer four questions:

My opinion: if a friend cannot tell you in ten seconds what you do and one result you are proud of, the page is not ready.

One page

The guide says to use only one page and that "highlighting a few of your best achievements is better than including many average achievements". It also says not to list everything "just to showcase a greater quantity".

The reason is simple: every extra line makes the best lines harder to find. One page forces you to choose. If you have more than ten years of experience and one page truly cannot hold it, that is a judgement call; the guide does not discuss it, and I will not invent a rule.

The structure

The guide recommends this order and these heading names ("recommended by recruiters", in the author's words):

Two notes from the guide: if you are still a student or have under 3 years of experience, you may put Education first. And do not put symbols in headings, because the guide says they can hurt ATS readability.

My opinion: many people put contact details in a single line directly under the name and skip a heading for it. That is fine for a human reader. The guide's table is about being safe with software.

Summary (headline)

The guide says a summary helps because interviewers rarely have time to read the details. Its rules:

• Fewer than 50 words.
• Answer "why am I a good fit for this job?"
• Active voice, action words, and start with the noun for your role ("Software Engineer", "Front End Engineer").
• Give it a headline of fewer than 10 words instead of the title "Professional Summary".

Its own examples include "Front End Engineer with X years of experience and strong fundamentals in Front End technologies" and, for a student, "Senior Year student at University X with a focus on Artificial Intelligence and Machine Learning". Replace X with your real number.

A made-up example of mine, in that style:

Contact information

The guide's must-haves: name at the very top, personal phone number, city/state/zip (enough for a recruiter to tell if you are local or international), personal email, and a LinkedIn profile. It says never to use a work phone or work email. Good to have: GitHub, personal site, and coding-platform profiles (with rankings or badges if impressive).

My opinion: if you include a link, check it opens while logged out. A dead link is worse than none.

Skills

The guide gives this shape: [Skill summary] : [list separated by "|"], grouped as programming languages, frameworks and databases. It also says that if your familiarity is impressive you can add the amount of code you have written ("Over 10,000 lines").

Languages: JavaScript | TypeScript | Python | SQLFrameworks: React | Next.js | ExpressDatabases: PostgreSQL | RedisTools: Git | Docker | GitHub Actions

Rules I use (my opinion): list only what you could discuss for ten minutes in an interview. A skills list is a promise the interviewer will test. Put the skills the job asks for first. Do not rate yourself with bars or stars: "4 out of 5 in Java" tells the reader nothing and cannot be parsed.

Work experience

The guide's format for each job:

[Company], [Location] | [Job Title] | [MM/YYYY - MM/YYYY]

Example from the guide: Facebook, Singapore | Front End Engineering Lead | 08/2018 - Present. List jobs in reverse chronological order (newest first). Under each job, give the scope of the job and its top accomplishments.

Education

The guide's rules: unless you are a recent graduate, do not put education above work experience. Include a GPA only if it is more than 3.50 / 4.00 (or above 4.3 on a 5-point scale). You can add leadership roles, societies, projects and awards.

Projects

The guide says to include at least 2 projects with your key contribution, and to link the project name to GitHub or another place where the reader can look. Its example is a maintainer role on a documentation tool, with a clear statement of what the tool is and who uses it.

My opinion: a project is most useful when you have little work history. For each, say what it is in one sentence, what you built, the stack, and one number (users, stars, requests, test count). A link to a repo that has a README and a working demo beats a long description. If you want ideas for what to build and how to explain it, the Full-Stack Lesson 14 experience round shows how those projects get discussed later.

Writing a good bullet

This is the part that changes results the most. A weak bullet says what your job was. A strong bullet says what changed because of you.

The guide's formula

The guide says each accomplishment follows this shape:

So the three parts are: what you achieved, what you did, and the measurable result.

About the "accomplished X as measured by Y by doing Z" idea

You may have seen a version of this sentence frame: "Accomplished X, as measured by Y, by doing Z." I did not find that wording in the handbook guide. I believe it comes from a different, widely shared recruiting tip, but I did not read that source, so I will not attribute it. The handbook's frame (summary, action, quantifiable outcome) carries the same idea, and I use it below.

A practical bullet recipe (action + scope + result)

This is my way of using the guide's frame. Check each bullet for three things:

1. Action: starts with a strong verb in the past tense (present tense for your current job). "Built", "reduced", "migrated".
2. Scope: how big was it? Users, services, team size, data size, number of endpoints.
3. Result: what changed, as a number if you honestly have one: time saved, cost cut, errors reduced, revenue, adoption.

A bullet does not need all three every time. But a page full of bullets with none of the three is a job description, not a resume.

Numbers you can defend

The guide asks for "quantifiable" results. The risk is a number you cannot explain. Interviewers read your bullets and ask about them (see Full-Stack Lesson 14). A good rule from me:

• Use only numbers you can explain in a sentence: how it was measured, over what period, and compared to what.
• Prefer before and after ("from 12 minutes to 3 minutes") to a bare percentage.
• If you do not have a metric, use scope instead: "for a service handling about 2 million requests a day" is honest if you know the figure from a dashboard.
• Never round up. "About 30%" is fine when it was 28%. "Doubled" when it was 1.3 times is not.
• If you do not know a number and cannot find out, leave it out. A clear plain bullet is better than a doubtful number.

Keywords and ATS: myths versus facts

Here I separate three things: what the guide claims, what I could verify, and my opinion. I could not verify anything about how a particular ATS works, because I did not have access to one.

What I would conclude (my opinion)

• The format rules (plain file, selectable text, standard headings, no tables-in-images) cost nothing and remove a real risk. Follow them.
• The ranking and auto-reject claims are unproven here. Do not twist your resume to chase them. A real person still reads the page in the end.
• The keyword advice is just good sense. If the post says "React" and "TypeScript" and you have used both, those words should appear on your page, in skills and in bullets.

The plain-text test

The guide suggests a simple check: copy all the text from your resume and paste it into a plain text file. Edit your resume if:

• some points are missing,
• some characters show up wrongly, or
• the sections come out in the wrong order.

Do this every time you export. It takes one minute. It tests the thing that actually matters: can software read your file.

Tailoring without lying

The guide suggests this for a group of similar jobs: collect 3 to 5 job posts for the role, paste them into one text file, and use a word-frequency tool to see which words repeat. Then make sure the skills and experience you really have show up in your resume. For one specific job, read the post for must-have and nice-to-have skills and mirror the language where it is true.

Two cautions from the guide: do not stuff keywords, and do not apply to many unrelated roles at the same company, because the ATS lets recruiters see all your applications. Also, if a company makes you retype your work history into its own form, take it seriously: the guide says the form data may be what is screened, and the recruiter may never open your file.

What to cut

Using the guide's "less is more" rule plus my own judgement:

Before and after: five weak bullets

The jobs and numbers below are made up by me to show the pattern. They are not real results. Use your own true numbers; if you have none, use scope.

1. A duty with no result

• Before: Responsible for maintaining the company website.
• After: Maintained a Next.js marketing site used by about 40,000 monthly visitors; fixed 25 accessibility issues found in an audit and cut the page weight of the home page from 4 MB to 1.5 MB.
• What changed: an action, a scope and two results.

2. A tool list

• Before: Worked with React, Redux, Node.js and MongoDB.
• After: Built a dashboard in React and Node.js that let support staff search 1.2 million tickets, replacing a spreadsheet process that took about 20 minutes per lookup.
• What changed: the tools stay (good for keywords), but now they sit inside something that was built and mattered.

3. A vague claim

• Before: Improved application performance.
• After: Reduced the p95 response time of the orders API from 900 ms to 350 ms by adding a database index and caching the product lookup in Redis.
• What changed: what was measured, from what to what, and how. (The p95 is the value 95% of requests are faster than.)

4. Teamwork with no detail

• Before: Helped the team with deployments.
• After: Set up a GitHub Actions pipeline that ran tests and deployed to staging on every merge, cutting release time from about 2 hours of manual steps to 15 minutes for a team of 6.
• What changed: "helped" hides what you did. Name the thing you made.

5. A big task with no outcome

• Before: Migrated database.
• After: Led the migration of a 200 GB MySQL database to PostgreSQL with no more than 10 minutes of planned downtime, and wrote the runbook the team used for two later migrations.
• What changed: size, constraint, and a lasting result. Note it does not claim "zero downtime" unless that is true.

A mistake to avoid when you copy these: do not copy my numbers. If your honest line is "Fixed a flaky test suite so CI passed reliably", it is fine to leave it without a number than to invent one.

Formatting summary

From the guide, collected in one place:

• Create it in Microsoft Word or Google Docs, then export a PDF with selectable text.
• No headers or footers in the file. Use 0.5 inch margins to gain space.
• Fonts: Arial, Calibri or Garamond; at least 10 pt.
• Standard section names, no symbols in headings.
• Dates as MM/YYYY; use | or tabs as dividers.
• One page.

Your file name is also read by humans. My opinion: Firstname-Lastname-Resume.pdf is clear.

Cover letters, in one paragraph

The guide has a section on cover letters. Its advice is that a cover letter should complement the resume, not repeat it, be tailored to the company and role, be under one page, tell one short relevant story, and be proofread. Whether a given company reads cover letters varies; I did not verify how often they are read. If a job asks for one, follow that advice. If it is optional and you have no reason to write one, your time is probably better spent on the resume.

Checklist

Print this and tick each line before you send a resume.

• One page; best points first.
• Headline of under 10 words and a summary of under 50 words that name the role.
• Name, city, personal email, phone and LinkedIn at the top; links open when logged out.
• Standard headings in a sensible order; no symbols in headings.
• Skills grouped (languages, frameworks, databases, tools); only things I can discuss.
• Jobs in reverse order with company, location, title and MM/YYYY dates.
• Every bullet starts with an action verb.
• Most bullets have a scope or a result; every number can be explained in one sentence.
• No duties-only bullets; no buzzwords without proof.
• Keywords from this job post appear where they are true, with abbreviations spelled out once.
• At least 2 projects with links, if work history is short.
• Created in Word or Google Docs; exported as a PDF; text is selectable.
• Plain-text paste test done: nothing missing, nothing garbled, order correct.
• Spelling and dates checked by someone else.
• If the company has a form, I filled it in carefully too.

Self-check

Try to answer these without looking up. The short answers are below each question.

1. How long should a software-engineer resume be, and why? One page. The guide says a few best achievements beat many average ones, and short pages are scanned faster.
2. What are the three parts of a strong bullet? An action, a scope (how big) and a result (what changed, ideally with a number).
3. What does the handbook guide say a bullet should look like? "Accomplishment summary: action that resulted in quantifiable outcome."
4. A bullet says "improved performance". How do you fix it? Say what you measured, from what to what, and what you did. For example "cut p95 latency from 900 ms to 350 ms with an index and a cache".
5. Name two format rules that help software read your file. Export a PDF from Word or Google Docs with selectable text, and avoid headers/footers, symbols in headings and design tools. Standard fonts also help.
6. Which ATS claims in the guide did I not verify? That an ATS auto-rejects by rule, ranks by keyword count, and estimates years of skill from placement. They are the guide's claims.
7. What is the plain-text test? Paste your resume text into a plain text file and check that nothing is missing, garbled or out of order.
8. Why should you only list numbers you can defend? Interviewers ask about bullets. A number you cannot explain (how measured, compared to what) hurts trust more than having no number.

Key takeaways

• Write for a short, distracted read; keep it to one page.
• Use the standard order and heading names, and a plain file that software can read.
• Every bullet: action, scope, result. Use true numbers you can explain.
• Take keywords from the job post only where they are true.
• Cut duties, buzzwords and old or unrelated items.
• Do the plain-text test before every send.
• Know the limits of the evidence: the guide is one experienced interviewer's advice, and the ATS claims are unverified.

What's next

Once the resume gets you a call, you need to be ready to solve problems live. Continue with A Coding-Interview Study Plan Mapped to This Site.