I went into this expecting to find some secret sauce. What I actually found was more boring and more useful than that.
Over the past few months I've been obsessively collecting anonymised resumes from people who got into Google, Meta, Amazon and similar.
Specifically ones where I could also see the version that didn't get through. Two hundred and something applications, plus conversations with a handful of recruiters who work at places recieving millions of apps a year.
The patterns that emerged were pretty consistent.
Annoyingly so, actually...
The recruiter attention thing is real, and it's brutal.
There's a Ladders eye-tracking study that gets cited endlessly, and I used to roll my eyes at it.
Six or seven seconds before they decide?
Surely not. But after talking to actual recruiters who are processing hundreds of resumes a week, I believe it now. They're not reading. They're scanning for signals, numbers, company names, technologies they recognise. If those signals aren't visible immediately, it's over.
The implication of this is that the top third of your CV is doing almost all the work. Which is a problem if, like most people, you've buried your best stuff halfway down under a wall of responsibilities.
The before/afters were genuinely surprising...
The craziest example I came across was a mid-level backend engineer who'd been rejected three times. Same person, same experience, same job history.
The difference in the revised resume was mostly just adding numbers to things.
"Worked on backend services" became "Architected and deployed 4 microservices handling 12M daily requests using Node.js, PostgreSQL, and Redis."
"Improved database performance" became something like "optimised queries and added a caching layer, cutting p99 latency by 68% and saving about $3k/month on database costs."
Same job. Same work. Completely different read. Within two weeks they had interviews at Meta, Amazon and Stripe.
I saw this pattern over and over. The people who were getting through weren't necessarily doing more impressive work they were just describing it in a way that gave the recruiter something to hold onto.
What the new grad example taught me.
One of the most interesting cases was a new grad with one internship and no full-time experience. On paper, not obviously hireable at Google. But their project section was doing something clever, every project followed a problem, action, result structure.
Not "Built a distributed task scheduler using Go and Redis." But: "Built a distributed task scheduler handling 10K+ concurrent jobs, reducing average completion time by 43% vs a baseline single-threaded implementation."
The difference is that the second version shows engineering thinking, not just a technology list. They're demonstrating they understand why the choices they made mattered.
Their competitive programming scores were also front and centre top 5% on Codeforces, LeetCode rating over 1800, which for an algorithmically-focused company like Google does actually signal something meaningful.
The ATS stuff is less sexy but genuinely important
Before any human sees your CV, an automated system is parsing it.
These systems are dumber than you'd expect. Tables break them. Text boxes break them. Anything in a header or footer often gets ignored entirely.
Fancy design means your carefully written bullet points arriving as garbled nonsense in a recruiter's dashboard.
The resumes that cleared ATS reliably were boring to look at.
Plain text, standard section headings like Experience and Education, no columns, no icons. Save the creativity for your portfolio.
Patterns across everything I looked at.
A few things came up in basically every successful application.
The verb choices matter more than people think. Engineered, architected, optimised, scaled —> versus "responsible for" or "involved in." The first set implies agency. The second implies you were nearby when something happened.
Every bullet point had at least one number. Latency reductions, user counts, request volumes, cost savings, time saved through automation.
If you can't put a number on something, you probably need to either dig into it more or cut the bullet entirely.
Technical skills sections worked best grouped by category, Languages, Frameworks, Tools, Cloud and without self assessed proficiency ratings. "Python four out of five stars" tells me nothing. Where you used Python and what you built tells me everything.
Education went at the bottom, unless it was a recent graduation or the programme was clearly relevant.
No objective statements. No references. No photos, and I'm genuinely still seeing this in 2026.
The thing that surprised me most
One candidate updated their CV by adding metrics to five bullet points and reorganising their skills section. Their callback rate went from 8% to 34% across 50 applications.
That's not a small tweak, that's a fundamentally different outcome from what was essentially an afternoon of editing.
I expected the successful resumes to have some structural secret I hadn't thought of. Instead most of the gap between rejected and accepted came down to this: did you quantify your impact, and is that impact visible in the first few seconds of someone looking at your page?
That's it, really.
If you want to check how your own CV stacks up against this stuff, I've been building a tool at helpthe.dev that analyses developer resumes against exactly these patterns.
Still early but it'll tell you specifically what's missing rather than just giving you generic tips.
Hope that's useful. Happy to dig into any specific part of this if people have questions, particularly the ATS parsing stuff, which I think is more nuanced than most guides make out.
Top comments (0)