Rebuilding a resume that scored 3.5 out of 10

The first thing the review said about my resume was that it had an identity crisis. The title block at the top claimed I was a data scientist, an ML engineer, an applied scientist and a backend engineer, all at once. A hiring manager scanning it would not know which job I was applying for, and would assume the answer was “whichever one is open.”

I had asked for that review on purpose. I gave Claude a prompt that turned it into a deliberately hostile hiring manager for top-tier ML roles, with instructions to score every section on a “BS factor”: how much of what the section claims a skeptical reader would discount on sight. My first version scored 3.5 out of 10. Lower is better, and 3.5 meant a meaningful share of my resume was being mentally crossed out before anyone read the details.

This post describes how I rebuilt it: a teardown loop that ran five versions in a week, the rules that make a claim survive a hiring committee, a master resume with four targeted variants, and the part most people skip, making sure every line could survive the follow-up questions it invites. It is part 6 of the 35 companies, 8 offers series.

For context, I had about four years of production ML experience: ranking and personalization at Cars24, a founding engineer role at an AI startup, entity resolution and computer vision at 6sense, and a first-author NLP paper. I was targeting ML engineering, applied scientist and AI engineering roles at the level of large tech companies.

The headline changes:

• BS factor: 3.5 out of 10 (version 1) → 2.2 (version 3) → under 2 (version 5)
• Versions: 5 full revisions in the first week of the search
• Targeting: one generic resume → a master resume plus four role-specific variants
• Defensibility: five consecutive “I don’t know” answers on resume items in a July mock → a plain-language defense of every line before the Google loop

Background: the two jobs a resume has to do#

A resume has two jobs, and most advice only covers the first.

Survive the skim. In an eye-tracking study by The Ladders, recruiters spent an average of 7.4 seconds on the initial screen of a resume, and simple layouts with clear sections and bulleted accomplishments held attention best. The first screen of a resume is a headline, not a document.

Survive the interview. Every line on a resume is an invitation to a question. At the companies I was targeting, interviewers build part of the round from your resume and then drill. A claim that reads well but cannot survive three follow-up questions is worse than no claim, because it converts a strength into a credibility problem in front of someone writing notes.

My first version failed both jobs in specific ways.

An identity crisis. Four job titles in the header meant no clear match to any role.

Buried results. My strongest number, a 90% reduction in LLM inference cost, sat in the middle of a section, after bullets describing the architecture that produced it.

Inflated verbs. Some bullets said “implemented” for work I had contributed to as part of a team. A skeptical reader discounts those, and an interviewer asks about them.

Numbers that disagreed. The same result appeared with different values in two places, because two related metrics from two different systems had blurred together.

Jargon only my team would know. Internal metric names appeared without definitions.

The teardown loop#

The review was not a single pass. It was a loop, run five times in about a week.

graph LR
    A["Draft version N"] --> B["Hostile review:<br/>BS factor per section"]
    B --> C["Strategic rewrite"]
    C --> D["Consistency check:<br/>every number, every title"]
    D --> E["Defense check:<br/>three follow-ups per line"]
    E --> F["Version N+1"]
    F --> B
    E -->|"cannot defend"| G["Cut or reword"]
    G --> F

    class A,F amber
    class B,C violet
    class D,E blue
    class G red

Each review had three parts: a brutal teardown with a score per section, a strategic reconstruction with rewritten bullets, and a competitive reality check against what other candidates for the same roles would bring. The per-section score was the useful part. It told me where to spend the next hour.

Across the five versions, the changes that moved the score most were these:

1. One identity in the header. “ML Engineer” with a one-line focus on ranking, personalization and LLM systems.
2. Strongest role first within the experience section. My ranking and personalization work at Cars24 was the most credible evidence for the roles I wanted, so it got the most space and the most prominent position.
3. Result-first bullets. Every bullet opened with the outcome and its number, then said how.
4. Fewer bullets per role. One role went from seven bullets to three, led by the 90% cost reduction.
5. Quantified claims that had been vague. Cold-start handling became “cold-start coverage from 65% to 100%.”
6. Honest verbs. “Implemented” became “contributed to” wherever the work was shared.

The review also introduced errors of its own. Version 2 accidentally deleted a strong bullet about multi-market ML work and added a duplicate skills section. Both were caught in version 3. A hostile reviewer still needs a diff check.

I did not accept everything. A few things the reviewer flagged, such as some internal system names I wanted interviewers to ask about, I kept deliberately. A hostile review is input, not a verdict.

Claims that survive a committee#

The deeper lesson of the teardown was about what makes a claim credible to people who are paid to doubt it.

Every claim names its measure. Laszlo Bock, who ran people operations at Google, popularized a formula for resume bullets: accomplished X, as measured by Y, by doing Z. The “as measured by” is what separates a claim from a description. “Built a two-tower retrieval model” is a description. “Lifted Click Recall@50 from 12% to 30% by replacing cohort-level ranking with a two-tower retrieval model” is a claim with a measure.

Every number belongs to exactly one system. I had built two different ranking systems at Cars24: a user-level personalization model that lifted Click Recall@50 by 150%, and a separate re-ranker with its own lifts in buyer intent and conversion. On the resume, and later in interviews, those numbers kept merging. In July a review found that a single line in my resume header still combined a metric from one system with the outcome name of the other. I wrote a hard rule into my notes: each number has one system, one definition, and appears with the same value everywhere.

Verbs match ownership. “Led,” “built,” “contributed to” and “implemented” mean different things to an interviewer, who will ask you to walk through the parts you claimed. Using the strongest verb you can defend is good; using one you cannot is the fastest way to lose a round.

Precision about everything checkable. Years of experience, publication venue and year, job titles and dates are all verifiable. I settled on “4+ years” rather than a rounded-up figure, and described my paper exactly as what it was. Small inflations on checkable facts cost far more credibility than they gain.

Before sending a resume, read every number aloud and say which system produced it and how it was measured. Any number you hesitate on is a number an interviewer will find.

One master, four variants#

A single resume cannot be optimal for an applied scientist role, a GenAI startup and a marketplace ranking team at once. I kept one master resume with everything, and cut four variants from it.

graph TD
    A[("Master resume")] --> B["Marketplace ML"]
    A --> C["Fintech and quant"]
    A --> D["Big tech applied scientist"]
    A --> E["GenAI and LLM"]
    B --> F["Per-role keyword pass"]
    C --> F
    D --> F
    E --> F
    F --> G["One page, sent"]

    class A blue
    class B,C,D,E amber
    class F violet
    class G green

The variants differed in order and emphasis, never in facts. The GenAI variant led with LLM systems and inference cost; the marketplace variant led with ranking and conversion; the applied scientist variant gave the publication and experimentation more space.

The keyword pass was the surprise. For specific roles I ran the resume against the job description and scored the match. One match for an ML role came out at about 75%, and almost every gap was vocabulary rather than skill. The job description named specific agent frameworks and “semantic search”; my resume described the same work in different words. The lesson generalizes: a low match score usually means you are describing your work in your team’s language instead of the market’s. The fix is to use the market’s words for work you actually did, never to add work you did not.

One page, strictly. Every round of keyword additions pushed the resume onto a second page, and every time I cut back to one. I moved the resume into LaTeX to control spacing precisely, and drafted a short descriptor line for each role (“team: what the system does, at what scale”) so a recruiter skimming only those lines would still get the story.

Defending every line#

The resume work I am proudest of happened months later, and it was not about writing.

In a July mock interview for the Google ML domain round, the interviewer persona built questions from my resume, the way a real interviewer often does. I said “I don’t know” five times in a row, and every one of those five was about a term on my own resume: uplift modeling, sample ratio mismatch (SRM) detection, Bayesian A/B testing, multiple testing correction, and feature stores. I had listed them as part of an experimentation and infrastructure skills line. I could not explain them at interview depth.

That changed my rule for what belongs on a resume. Every term must survive three follow-up questions. For each item that failed, I had two options: learn it properly or take it off. I spent a session getting plain-language explanations of each statistics term and each infrastructure tool on the page (what it is, why you would use it, and how it connected to systems I had actually built), then drilled them until I could explain each in a sentence and defend it for a minute.

The same discipline paid off again in August. After the main Google loop, the recruiter shared a list of topics the next round would probe, and I revised the resume to surface them. I did it one section at a time, approving each before moving on, and the review caught internal contradictions I had never noticed: one component described two different ways in two bullets, and one percentage stated two different ways in two sections. Each was resolved to a single, defensible version before the round.

Results#

The score moved from 3.5 in the first version to 2.2 by the third and below 2 by the fifth. More usefully, the before-and-after of specific problems looked like this:

The search that ran on this resume reached a first round at 32 of 35 companies, and the resume held up in interviews that built questions from it, including the Google loop.

What I’d do differently#

Run the defense check from day one. I treated the resume as a document to be judged on the page for months before treating it as a list of interview questions. The July mock would have been an April mock.

Keep a metric bank next to the resume. One page listing every number, its system, its definition and how it was measured would have prevented the blended-metric problem entirely.

Diff every version. Two of the five versions introduced errors while fixing others. A quick side-by-side comparison would have caught them in minutes.

Write in the market’s vocabulary first. I would have saved several keyword passes by describing my work in standard industry terms from the beginning, with internal names as secondary detail.

Conclusion#

A resume is a set of claims that will be tested twice: once by a skim and once by an interviewer. The teardown loop made mine survive the skim. The defense rule made it survive the interview, and that is the half that decides offers.

Write only what you can measure, attribute every number to one system, use the strongest verb you can defend, and assume every word on the page will become a question.

Part 6 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.