Software Engineer Resume: Impact Bullets, ATS Parsing and Honest Tailoring

Usually the resume lists duties instead of evidence. A software engineer resume that says what you were responsible for, but not what changed because of you, gives a reviewer nothing to compare.

Picture a common setup. A backend engineer with two years at an Indian e-commerce company applies to forty roles and hears back from two. The values in this guide are made up, but the pattern is real.

Their strongest piece of work sits in one line: "Worked on backend APIs using Django and Redis." Django is a Python web framework and Redis is an in-memory data store. The line is true. It also fits every backend engineer in the country, so it proves nothing.

This guide rewrites that one bullet step by step. Then it uses the same method on the same engineer's final-year college project, checks how software reads the file, and shows how to tailor it honestly.

Six terms come up again and again. Each gets a plain meaning here.

• JD (job description): the posting that lists the role's duties and its required and preferred qualifications.
• Bullet: one line under a job or project. It is the unit reviewers compare, so most of your effort goes here.
• Impact: what changed because of your work. Faster pages, fewer failures, hours saved and users served are all impact.
• Metric: a number that measures impact, such as latency in milliseconds or a count of users.
• p95 latency: the time within which 95 out of 100 requests finish. Engineers use it because averages hide slow requests.
• ATS (applicant tracking system): the software that receives applications and stores each candidate's details in fields a recruiter can search.

Put the strongest evidence first. For a working engineer that is experience; for a fresher it is usually projects and internships. Contact details sit at the top, and skills and education follow.

Think of a resume like the front page of a newspaper. Your name and title are the masthead, the paper's name at the top. The first job or project is the lead story, and its first bullet is the headline.

Editors put the most important story above the fold, the top half a reader sees first. You do the same with your best bullet. Where the picture breaks: a newspaper reader chose to read, while a reviewer is screening many resumes and looking for a reason to stop.

Leave out a photo, date of birth, father's name, marital status and a long objective statement. None of them is evidence of engineering skill, and an ATS vendor lists photos as a cause of failed parsing.

On length, keep a fresher resume to one page and an engineer with under about eight years to one or two. That is our advice. MIT's career office suggests one page, or two at most if you have substantial relevant material.

Write each bullet as action, scope and result: a strong verb, how big the thing was, and what changed, measured. Then add how you did it if space allows.

This pattern matches what university career offices advise. MIT's career office tells students to focus on what they accomplished and to quantify results whenever possible. Its action-verb list says to begin each bullet with an action verb.

The running example, one step at a time

Start with the vague line: "Worked on backend APIs using Django and Redis." Ask what you actually changed. Our engineer remembers that the order-status page felt slow, and that they fixed it.

• Action: "Cut" says you reduced something. It is stronger than "worked on" and more honest than "led" if you did it alone.
• Scope: "the order-status API, about 2 lakh (200,000) requests a day" tells the reader the work was real traffic, not a demo.
• Result: "p95 latency from 900 ms to 300 ms" is the change, taken from the team's monitoring dashboard.
• How: "by caching price lookups in Redis" names the technique, which gives the interviewer something to ask about.

Here is the full rewrite, before and after. The second line is longer, but every added word is evidence.

• Before: "Worked on backend APIs using Django and Redis."
• After: "Cut p95 latency of the order-status API from 900 ms to 300 ms by caching price lookups in Redis, at about 2 lakh requests a day."

What just happened? The tools are still there, so keyword searches still match. But the change from 900 ms to 300 ms is what a reviewer can compare. A 900 to 300 ms drop is a 66.7 percent cut, or three times faster.

Write the raw numbers, not only the percentage. "66.7 percent lower latency" invites the question "faster than what?", while the before and after values answer it.

What if your work has no number?

Use scope instead of a result. MIT's career office says not to worry if you lack exact numbers, and to describe your role and the positive outcome. Size, users, frequency and who depended on your work are all honest substitutes.

• Size: "Migrated 14 cron jobs (scheduled scripts) from a single server to a job queue".
• Users: "Built the refund screen used by the 30-person support team".
• Frequency: "Automated the weekly release checklist that took two hours by hand".
• Trust: "Owned on-call for the payments service for six months".

Find numbers before you write. Look at monitoring dashboards, merged pull requests, ticket history and old release notes. If you only know a range, write "about" and keep the lower figure.

Not as a rule. The number comes from one small eye-tracking study, which recorded where people's eyes moved on a screen. It timed how long recruiters looked before a first fit or no-fit decision.

TheLadders, a US job site that also sells resume rewriting, published the study in 2012. Thirty professional recruiters took part over ten weeks. They spent about six seconds on the initial fit or no-fit decision.

The same report says recruiters spent almost 80 percent of their review time on six items. Those were name, current title and company, current start and end dates, previous title and company, previous dates, and education.

Read it with its limits. The report does not say how many resumes were viewed or which statistical tests were used. The authors sell resume services, the sample was 30 people, and the data is from 2012.

A 2018 press release from the same company reported an average first screen of 7.4 seconds. The release does not give the number of recruiters, so treat it as a headline, not a study you can check.

What can you safely take from it? Make the top third of page one easy to read: your name, current title, company, dates and best bullet. If a reviewer reads only that, they should still want more.

Treat each project like a small job: what you built, who used it, and one hard problem you solved. The same action, scope and result pattern works, with smaller numbers.

Go back two years in our running example. The same engineer's fresher resume said: "Made a mess feedback app using React and Node.js." That line tells a reviewer the stack and nothing else.

The rewrite: "Built a mess feedback web app in React and Node.js used by about 400 hostel students. Weekly reports cut complaint follow-up from 10 days to 3." Both numbers are made up for this guide.

• Pick two or three projects with real users, real data or a hard bug, over five tutorial clones.
• Link the code. A GitHub repository with a short README that explains how to run it lets a reviewer check your claim.
• Name your part in team projects: "designed the database schema and wrote the search API" beats "team of four built".
• Add CGPA if it is strong or a role asks for it. Otherwise one line under education is enough.
• Contest ratings and hackathon results go under achievements, with the platform and the rating or rank.

Beginners can stop here with a working resume. The next sections cover how software reads the file, tailoring, common mistakes and interview defence.

An ATS pulls the text out of your file and fills fields such as name, email and job history. If the text comes out empty or in a strange order, those fields come out wrong.

Greenhouse, an ATS vendor, documents the causes of a failed parse on its support site, last updated 2 March 2026. As of 26 October 2026, its list includes the causes below, among others.

• Files larger than 2.5 MB are not parsed.
• Resumes uploaded as an image instead of a document such as .docx or .pdf can fail.
• Graphics, photos and word art can cause failures.
• Complex resumes with tables, headers and footers can fail.
• Putting your name and contact details in a header, footer or text box can fail.
• Resumes with a columned layout can fail.

The same page says what happens next. The resume is only attached to the candidate, and someone must type the details into the fields by hand. It does not say the candidate is rejected.

Our test: the same layout, read two ways

We wanted to see why two-column designs cause trouble. So we made a fake resume as a PDF with reportlab 4.2.5, a Python library that writes PDFs. Then we pulled the text out with two common Python libraries, pypdf 5.1.0 and pdfminer.six 20240706.

The page had a skills column on the left and the experience column on the right. We wrote it twice: once column by column, once line by line across the page. Both files rendered to identical images.

The line-by-line file is the warning. One library mixed a skill with a job title on alternating lines, and the other did not. You cannot see from the screen how your design tool stored the text.

Check your own file the same way. Install pypdf, save this as check_resume.py next to your resume, and run it. You should see your name first and every bullet in reading order.

# pip install pypdf==5.1.0
from pypdf import PdfReader

reader = PdfReader("resume.pdf")
for number, page in enumerate(reader.pages, start=1):
    print(f"--- page {number} ---")
    print(page.extract_text())

If the output is empty, your file is probably an image, so export it again from your word processor. If lines from two columns alternate, switch to one column. Also select all the text in a PDF viewer and paste it into a plain text file as a second check.

Do ATS keyword filters reject resumes automatically?

Not in the way the myth says, at least in what Greenhouse documents. Its application rules can auto-reject, but they act on answers to custom application questions, such as a notice period or work location question.

That page says nothing either way about rules on resume text, and other ATS products and newer screening features may differ. We did not find a primary study behind the popular claim that most resumes are rejected by software unseen.

What does matter: recruiters search the stored text. If the JD says PostgreSQL and your resume says only "SQL databases", a plain keyword search for PostgreSQL may miss you. Write the exact names of tools you have used.

Change the selection, order and wording of true bullets, never the facts. Tailoring means showing the most relevant parts of your real work first, in the words the JD uses.

MIT's career office suggests keeping one full master resume and a shorter targeted version for specific roles. It says to read the job description for clues on what the employer values.

1. 1

   Mark the JD

   Highlight required skills, preferred skills and the problems the team says it solves. Note the exact spellings, such as PostgreSQL or Kubernetes.

2. 2

   Match each line to evidence

   For every highlighted item, find a bullet that proves it. If none exists, leave the gap; do not invent one.

3. 3

   Reorder

   Move the bullets that match to the top of each role. For our engineer applying to a caching-heavy team, the Redis bullet goes first.

4. 4

   Reword, keeping the facts

   Use the JD's term where it is accurate. "Caching layer" can become "Redis cache" only if you used Redis.

5. 5

   Run the ten-minute test

   For every skill on the page, ask whether you could talk about it for ten minutes. Remove anything that fails.

6. 6

   Save a copy per role family

   Keep one version each for backend, frontend or data roles, and adjust only the top bullets per application.

Why so strict? Interviewers ask about what you wrote. Employers can also check past jobs, dates and degrees with your old employers and college, so a wrong date can cost you an offer.

Most mistakes either hide your evidence or make it hard to trust. The table pairs each one with a fix.

Expect the interviewer to pick a bullet and ask you to redraw it. Prepare each top bullet as a short design story, with the problem, the design, the numbers and what you would change.

1. 1

   State the problem and the numbers

   The order-status API had a p95 of 900 ms at about 2 lakh requests a day. Price lookups hit the database on every call.

2. 2

   Draw the before and after

   Client, API, database; then the same path with Redis in front of the price lookups.

3. 3

   Explain the trade-off

   Caching made reads fast but prices could go stale. Say how long a cached price lived and why that was acceptable.

4. 4

   Show how you measured

   Name the dashboard, the metric and the time window you compared. This is where an inflated number falls apart.

5. 5

   Say what broke or could break

   Cover cache misses after a deploy, and what happens if Redis goes down.

6. 6

   Close with what you would change

   One honest improvement shows judgement more than a perfect story does.