How to Write an ATS-Friendly Resume for Software Jobs

Much of the advice about “beating the ATS” imagines a robot that silently bins resumes. The reality is duller and more useful: the software turns your file into searchable text, and a recruiter decides what happens next. Your job is to make sure the text survives that conversion intact, and that a person skimming it quickly finds the evidence they are looking for.

What an applicant tracking system actually does

An applicant tracking system, or ATS, is the database behind an employer’s careers page. With your resume, it does four things:

• Parses it. It extracts the text and tries to sort it into fields: name, contact details, employers, titles, dates, education, and skills. Those fields fill the candidate record recruiters see, and often the application form you are asked to check after uploading.
• Makes it searchable. Recruiters search and filter candidates by keywords, titles, locations, and answers to questions, for the role you applied to and for later ones. A resume can resurface months after the application.
• Asks knockout questions. Forms include screening questions on work authorisation, relocation, notice period, or years with a technology, and employers can set answers that reject an application automatically. In most setups, this is where automatic rejections come from, and it has nothing to do with formatting.
• Tracks the process. Stages, interview feedback, and templated emails, including the one that begins “Unfortunately”.

Some newer systems also rank applicants by similarity to the posting. A recruiter still decides how much weight that ranking gets, and the fixes below help with both the ranking and the human read.

Myths you can stop worrying about

Myth	What is actually true
“Most resumes are rejected by software before a human sees them.”	Automatic rejections mostly come from knockout questions and filters that recruiters set up. A badly parsed resume is harder to find and read, which hurts, but it is not a robot’s verdict.
“You must match a fixed percentage of keywords.”	There is no universal threshold. Recruiters search for a few terms they care about, usually the core language, framework, and domain.
“An ATS cannot read PDFs.”	Text-based PDFs parse well in most modern systems. Scanned documents and images do not. Upload Word format when a portal asks for it.
“Keywords hidden in white text help.”	Hidden words appear in the parsed text and in any plain-text view a recruiter opens, where they read as an attempt to game the system. It is the fastest way to lose credibility.
“A template sold as ATS-friendly is safe.”	Many use two columns, tables, or icons that scramble the reading order. Test any template yourself.

Formatting rules that survive parsing

• One column, top to bottom. Many parsers read a page in horizontal lines, so two columns can splice your skills list into the middle of your job history.
• Standard section headings: Summary, Experience, Projects, Skills, Education, Certifications. A creative heading such as “Where I’ve made an impact” may not be recognised as your experience.
• Real text everywhere. No skill bars, star ratings, icons in place of labels, or text inside images. Four stars in Java means nothing to a reader and nothing to a parser.
• Contact details in the body, not in the page header or footer, which some parsers skip: name, phone, email, city, LinkedIn, and GitHub.
• Consistent dates, such as “Mar 2022 – Present”, on the same line as each title, with company names written the same way throughout.
• Plain fonts and bullets, and no tables for layout.
• A sensible file: a text-based PDF unless the portal asks for .docx, named like Firstname-Lastname-Backend-Engineer.pdf rather than resume_final_v3.pdf.

Leave out what many Indian resume templates still carry: a photo, date of birth, marital status, father’s name, full postal address, and the closing “I hereby declare” paragraph. None of it helps a software application, and the space is better spent on evidence. If you can join quickly, a line near the top such as “Notice period: 30 days” answers a question almost every Indian recruiter asks.

A bullet formula that shows impact

Weak resumes list duties. Strong ones show what changed because you were there. Build each bullet from four parts: an action that starts with a verb, the scope it touched (a service, a team, a volume of users or data), the tool, named the way postings name it, and the result, measured if you can and described plainly if you cannot.

The numbers in these rewrites are illustrative; use your own.

Weak	Stronger (example)
Worked on backend APIs for the payments module.	Built six REST endpoints in Spring Boot for refund processing, replacing a spreadsheet process the support team ran by hand every day.
Responsible for testing.	Automated about 180 checkout regression cases with Playwright in GitHub Actions, cutting release sign-off from two days to half a day.
Used AWS for deployments.	Moved nightly batch jobs from a single EC2 instance to AWS Batch, defined in Terraform, removing the single point of failure behind three missed reports in one quarter.
Did a machine learning project. (Fresher)	Trained a gradient-boosted model in scikit-learn to flag late deliveries in a public dataset, beat a logistic regression baseline on recall, and documented why the extra complexity was worth it.

With no metric to hand, name the consequence instead: who stopped doing manual work, which class of incident went away, which team adopted what you built.

A skills section that matches your real experience

Recruiters search the skills section, and interviewers pick questions from it. Treat every entry as a promise that you can discuss it for ten minutes.

• Group it: Languages; Frameworks and libraries; Databases and messaging; Cloud and DevOps; Testing and tools.
• Write each skill the way postings do, adding the common abbreviation once where people search with it: “Kubernetes (K8s)”, “Google Cloud (GCP)”.
• Back each skill with at least one bullet or project that uses it. A skill with no evidence anywhere else reads as padding.
• Cut tools you touched once in a training programme, and anything every developer is assumed to know, such as MS Office or Windows.
• Drop self-ratings like “expert” or “intermediate”. Depth shows in the bullets.

How matching tools compare skill lists, and why exact wording matters, is covered in resume keyword matching explained.

Tailoring a resume in fifteen minutes

Keep one master resume containing every bullet you might use, and cut a version from it for each application:

1. Minutes 1–3: read the posting and mark its three or four hard requirements and its central problem (see how to read a job description).
2. Minutes 4–7: reorder the bullets in your latest role so the ones answering those requirements come first, and swap in a more relevant project if you have one.
3. Minutes 8–10: rewrite the two-line summary for this role, using the posting’s terms where they truthfully describe your work.
4. Minutes 11–13: reorder the skills section to lead with what the posting names. Do not add anything you do not have.
5. Minutes 14–15: export, run the parse test, name the file, and record the version in your application tracker.

Length, section order, and the summary

One page, until your relevant experience genuinely no longer fits on one. Two pages for experienced engineers, with older roles cut to a line or two each. Past two pages, you are writing for yourself rather than the reader.

Order sections by what proves the most. With work experience: Summary, Experience, Skills, Projects, Education. As a fresher: Summary, Education (with CGPA and relevant coursework), Projects, Internships, Skills. By your second job, education shrinks to a single line at the bottom.

Keep the summary to two lines that say what you build, with what, and at what level. For example: “Backend engineer with four years building order and payment services in Java and Spring Boot on AWS. Comfortable owning services in production, including on-call and query tuning.” Drop objectives such as “seeking a challenging position”; they describe what you want, not what you offer.

Final checklist before you upload

• Single column, standard headings, no tables, icons, or images.
• Contact details in the body, including city, LinkedIn, and GitHub.
• Passes the plain-text paste test.
• Every bullet starts with a verb and shows a result or consequence.
• Every listed skill is backed by a bullet or project.
• The summary and first bullets answer this posting’s hard requirements.
• Dates are consistent, and any gap of more than a few months has a one-line explanation (see job hunting after a layoff or career gap).
• No photo, date of birth, marital status, or declaration.
• A sensible file name, and a text-based PDF unless the portal asks for Word.
• Knockout answers on the form are accurate. Never claim work authorisation or years of experience you do not have; it surfaces at background verification, if not sooner.