Home / Blog / The resume strategy that beats the ATS (Google XYZ formula)

The resume strategy that beats the ATS (Google XYZ formula)

PrepHike · 7 min read

Your resume has two readers: a keyword filter that decides if a human ever sees it, and a tired recruiter who skims for thirty seconds. Most engineers in India write for neither. The XYZ formula fixes both at once, and it makes every line something you can defend in the room.

Why good engineers get filtered out before anyone reads them

You can be the strongest engineer on your team and still never get a call back. That is not a skill problem. It is a translation problem. Two filters sit between your work and the interview. The first is the ATS, the applicant tracking system that scans your resume for the words in the job description. The second is a human who spends roughly thirty seconds deciding whether you are worth a screen. If your resume reads like a job description of your current role, you fail both.

The fix is not a fancy template or a colorful sidebar. It is how each line is written. The most reliable pattern, made well known by Google's own recruiting advice, is the XYZ formula. Once you write to it, your resume stops listing what you were responsible for and starts proving what you changed.

The XYZ formula, stated plainly

The formula is one sentence: Accomplished X, as measured by Y, by doing Z.

• X is the result. What got better.
• Y is the number that proves it. The metric.
• Z is what you actually did. The technical work.

Notice the order. The result comes first, the number second, and the technology last. Most engineers do the reverse. They lead with the tech stack and bury the result, if they mention one at all. The recruiter scanning for thirty seconds reads the front of each line, so the front of each line has to carry the outcome.

Duties versus results, side by side

Here is a duty-style bullet, the kind that fills most resumes in India:

Responsible for optimizing backend APIs and improving database performance using Spring Boot and PostgreSQL.

It says nothing. Responsible how? Improved by how much? Now the same work in XYZ form:

Cut p95 API latency from 1.2s to 280ms (X and Y) by adding Redis caching and rewriting three N+1 queries in a Spring Boot service handling 4M requests a day (Z).

The second version is shorter on fluff and longer on signal. A recruiter sees the result in the first four words. The ATS sees Redis, Spring Boot, caching, and query optimization. And in the interview you can talk for ten minutes about exactly how you found those N+1 queries, because it is your real work. That last point matters more than people think. We cover it in depth in how to answer "tell me about this project".

Results over duties, even when you are not sure of the number

The most common objection from engineers in India is honest: "My company never gave me dashboards. I do not know my numbers." That is fine. You do not need a metrics platform to write XYZ bullets. You need to reconstruct the number defensibly.

Ask yourself what changed and roughly by how much. If a report that took the ops team two hours every morning now runs on a schedule, that is "saved the ops team about 10 hours a week." If a flaky deploy used to break twice a sprint and now does not, that is "reduced production deploy failures from roughly twice a sprint to near zero." If you cannot measure latency, you can often measure volume, frequency, time saved, error rate, or scale: requests per day, records processed, users supported, services owned.

Two rules keep this honest. First, round and qualify. "About 40 percent" or "roughly 10 hours a week" is more credible than "41.7 percent" and protects you when asked to explain it. Second, never write a number you cannot walk through. If a bullet says you improved something by 60 percent, you must be able to say what it was before, what it is now, and how you know. A claim you cannot defend is worse than no claim, because it fails you in the room instead of on the page. If you are unsure what your work is actually worth in the market, start with the market value audit most underpaid engineers skip.

Make it readable by the machine

ATS-readability is mostly about not being clever. The systems that parse your resume are simple, and they break on layout tricks. Keep these in mind for any ats resume:

• Single column. Two-column layouts and sidebars get read out of order or scrambled. The fancy template you downloaded is often the reason your resume parses as nonsense.
• Real text, not images. Never put your name, contact details, or skills inside a graphic or an icon. If it is not selectable text, the parser cannot read it.
• Standard section headings. Use Experience, Skills, Education, Projects. Cute headings like "Where I have made a dent" confuse the parser.
• Plain bullets and standard fonts. Skip text boxes, tables for layout, and headers or footers for key content. Many parsers ignore the header region entirely.
• Save as a text-based PDF unless the portal asks for .docx. Export from your editor, do not scan or screenshot.

A quick test: copy your whole resume and paste it into a plain notepad. If the order is wrong or text goes missing, the ATS sees the same mess. Fix the layout until the paste reads top to bottom in the right order.

Keyword matching, done without stuffing

The ATS ranks you partly on how well your resume matches the job description. This is where keyword matching earns its place, and where people overdo it. The goal is not to hide white text or dump a skills cloud. The goal is to use the same words the JD uses for things you have genuinely done.

Read the target JD and pull out the concrete nouns: the languages, frameworks, databases, cloud services, and practices. If the JD says "Kafka" and you have written "event streaming," change it to "Kafka (event streaming)" so both the human and the machine match. If it says "CI/CD" and you wrote "deployment pipelines," name the actual tools: Jenkins, GitHub Actions, whatever you used. Mirror their vocabulary, but only for work you can defend in an interview. Tailoring per role beats one generic resume sent everywhere, and it is the difference between a 5 percent reply rate and a 25 percent one.

One caution for engineers in India applying to a mix of startups, MNCs, and GCCs: the same experience should be described differently for each. A product startup wants ownership and speed. A GCC wants scale and process. The bullets stay true, the emphasis shifts.

A simple structure for the page

Order matters as much as wording. For a software engineer resume india with 2 to 6 years of experience, this order works:

• Name and contact as plain text at the top, with a GitHub or portfolio link if it is real.
• A two-line summary only if it says something specific. Skip the "passionate engineer seeking challenging role" line.
• Skills, grouped (Languages, Frameworks, Data, Cloud, Tools), matched to the roles you target.
• Experience, most recent first, three to five XYZ bullets per role, results first.
• Projects, if they add signal a job did not.
• Education, brief, at the bottom.

Keep it to one page at this experience level, two only if every line earns its space. Recruiters do not read long resumes more carefully. They read them less.

The thread that ties it together

The XYZ formula is not a writing trick. It is a forcing function. It makes you state a result, attach a number, and own the work, which is exactly what the interview will test. A resume full of defendable XYZ bullets does three jobs at once: it passes the keyword filter, it survives the thirty-second skim, and it sets up the stories you will tell out loud. Those stories matter as much as the page, which is why STAR stories that do not sound rehearsed are the natural next step.

If you want this done with a second pair of eyes, rebuilding every bullet so it reads as a result and holds up under questioning, that is the first thing we do in our method. The resume is where the salary conversation quietly begins.