I lead ML research and development for medical AI products, which means a few times a year I end up reading a stack of resumes for an engineering or research role. I am not a recruiter and I have no training in hiring. I am an engineer who has to decide which five people out of eighty are worth an hour of my team's time. That constraint shapes everything about how I read.
What I have learned from doing it badly and then slightly less badly is that most technical resumes fail for one boring reason: they describe what the person was assigned, not what changed because they were there.
"Worked on backend services using Java and Spring Boot" is a job description. It tells me a team existed and you were on it. "Rebuilt the retry and error-handling path in our payment service, cutting failed transactions by roughly a factor of five" is a claim about you. I can ask questions about it. I can imagine you doing something similar for us. The second version is not more impressive because it has a number in it — it is more impressive because it has a decision in it.
That is the whole game, and most of what follows is mechanics in service of it.
The ATS thing is real, but not the way you have been told
You have probably read that applicant tracking systems auto-reject three quarters of resumes, that a machine scores you and bins you before any person looks. This is mostly folklore, and it has spawned an entire industry of resume-optimisation services selling a fix for a problem that is misdescribed.
Here is what is actually true. Applicant tracking software is near-universal at large employers — Jobscan's survey of Fortune 500 hiring tools found one in place at 489 of the 500. But the common ATS is a database with search on top. It stores applications, lets a recruiter filter and sort them, and tracks candidates through stages. Most of the time nothing is auto-rejecting you. A human is typing a query — "Kubernetes", "PyTorch", "FDA" — and reading what comes back.
The practical consequence is different from the myth, and smaller. You do not need to defeat a robot. You need to be findable by a tired person running searches, and you need your file to parse cleanly enough that your work history lands in the right fields. That means:
- Use the words the job description uses, where they honestly apply to you. If they say "observability" and you wrote "monitoring", say both.
- Submit a normally structured document. Multi-column layouts, text inside images, and skills rendered as little rating bars parse unpredictably.
- Do not keyword-stuff. A block of 60 technologies at the bottom of the page is visible to humans too, and it reads as either desperate or dishonest. I have discarded resumes over it.
Paste your resume into a plain text editor before you send it. If it still makes sense as plain text, you are fine.
Structure, briefly
Contact details at the top: name, email, city, LinkedIn, and GitHub only if there is something there worth opening. No full postal address. No photo in markets where photos are not standard, which includes most of North America, the UK and Australia.
Then a technical skills block, near the top, organised into two or three honest categories. The test for whether something belongs on that list: could you survive twenty minutes of questions about it from someone who uses it daily? If not, cut it. I have watched candidates deflate in real time when asked about a language they listed and had touched once in a university lab.
Then experience, newest first, three to five bullets per role. More than five and you are padding; I will read the first two anyway.
Then projects — and if you are early-career or changing specialisation, this section matters more than your experience section. Name the project, link the repo, say what it does in a sentence, then say what was hard about it. "Real-time price tracker" tells me nothing. "Real-time price tracker; the interesting part was handling out-of-order updates from the websocket feed without blocking the render path" tells me you have met a real problem.
Education at the bottom unless you graduated within the last two years. I have a PhD and I still put mine at the bottom.
"I don't have metrics"
This is the most common pushback I hear, usually from people whose work genuinely was not instrumented. Fair. But you are allowed to be approximate and you are allowed to describe scale instead of change.
Did something get faster? Even "page load went from about four seconds to just over one" is useful. Did you reduce toil? How many manual steps disappeared. Did you write documentation? Did the same question stop coming up in the team channel. Did you refactor something? How large was it, and did anything measurable improve — build time, test coverage, incident rate.
When you truly have no numbers, use scope: a codebase of this size, a platform with this many users, a team of this many engineers, a regulated domain with this review burden. Scope is context, and context is most of what I am trying to build while reading.
One warning. Do not invent numbers. If your resume says you improved latency 90% and you cannot, under mild questioning, tell me what the baseline measurement was or how it was taken, the interview is effectively over — not because you failed a trick question, but because I now have to discount everything else on the page.
Things to cut
The objective statement. "Seeking a challenging role where I can leverage my skills" is content-free and occupies the most valuable space on the document.
Soft skills as a list. "Team player, fast learner, excellent communicator" is an assertion anyone can make. If it is true it shows up in how you describe collaborative work, and I will notice.
Version archaeology. "Java 8, Java 11, Java 17" is one skill, written three times.
Length: under five years, one page. Five to fifteen, one or two. Beyond that, two pages maximum with your earliest roles compressed to a line each. Nobody has ever been rejected for concision.
Tailoring, and how much it actually matters
Rewriting your resume for every application is not sustainable and not necessary. Keep one strong base document and adjust the top third — summary, skills order, and the emphasis of your two most recent roles — per application. That is where a reader's attention actually goes.
The emphasis differs by employer type more than people expect. Small companies are buying ownership: can you take an ambiguous problem and be responsible for it end to end. Large companies are buying scale and legibility: what systems, what traffic, what cross-team coordination, mapped to whatever internal rubric they use. Research-adjacent teams like mine are buying evidence that you can be wrong in public and keep going — which shows up as writing, as published work, as projects you clearly iterated on rather than finished in one weekend.
If you are switching specialisations, nobody is fooled into thinking you have five years in the new field, and you should not try. What I am looking for in a switcher is whether the learning is real and self-directed. A small project that you clearly struggled with is better evidence than a certificate.
The last check
Hand your resume to one person who has actually hired in your field, and ask them a specific question: what are the first three things you would ask me about, based on this. If their three things are not the three things you want to talk about, your emphasis is wrong and the fix is editing, not a new template.
Your resume's only job is to earn a conversation. It cannot convey what you are like to work with, and it will not get you hired on its own. It just has to make someone think the conversation is worth an hour.
Tags
Taresh Sharan