You spent hours on your resume. You hit submit. Nothing.
A week passes. Then two. The silence is the worst part — you don’t even know what went wrong.
Here’s the uncomfortable truth: most resumes are ignored in under 10 seconds. Not because the candidate isn’t good, but because the resume doesn’t make the case fast enough. Recruiters aren’t reading — they’re scanning. Your job is to make that scan impossible to ignore.
This is the checklist I run through every time I update my resume. Fourteen rules. Each one has cost someone a callback when skipped.
Don’t design your resume. Download one. A pre-designed template handles spacing, font hierarchy, and visual balance better than anything you’ll build from scratch in an afternoon. Your energy belongs on the content, not the layout.
Three free templates that are actually good:
If you have under 10 years of experience, one page is the rule, not a suggestion. A second page signals that you haven’t learned to prioritize. Every line should earn its space. If something doesn’t strengthen your case for this specific role, cut it.
Recruiters write job descriptions with specific words. Use those exact words. Not synonyms — the actual words.
If the JD says “contact center automation,” don’t write “IVR pipeline development.” Write “contact center automation.” This matters doubly if the company uses ATS software to filter applications before a human sees them.
Mention the company by name somewhere — ideally in a summary line or a targeted bullet. It signals intent and attention. It tells the recruiter this wasn’t a bulk-apply. That signal matters more than you’d think.
Your first bullet under your most recent role is the most-read line on your resume. Make it directly answer what the job posting is asking for. Don’t bury your most relevant accomplishment three bullets down — put it first.
“Software Engineer” tells someone your function. “Software Engineer — reduced deploy time by 60% through CI/CD overhaul” tells them your value. Wherever possible, push impact into or immediately below your title rather than saving it for the body.
A GitHub profile, a portfolio site, a LinkedIn — whatever is most relevant to your field. It gives a recruiter somewhere to go when they want to know more. If you don’t have one, a blog counts. Even one post shows you can communicate your thinking.
Resumes are written in third-person implied. “Led a team of 5 engineers” not “I led a team of 5 engineers.” Every “I” is wasted space and reads as junior.
Words like passionate, results-driven, team player, hardworking, and detail-oriented mean nothing. Every candidate uses them. They add length without adding signal. A recruiter who reads “dynamic self-starter” learns nothing about you. Replace every buzzword with a specific fact.
Begin each bullet with a strong past-tense verb: Architected, Built, Reduced, Led, Shipped, Automated, Migrated, Mentored. Action verbs force you to describe what you actually did, and they read as confident and direct.
Weak: “Responsible for the maintenance of Lambda functions” Strong: “Maintained and optimised 30+ Python Lambda functions serving 1M+ monthly IVR calls”
Numbers make claims credible. Rough estimates beat vague descriptions every time.
If you don’t have an exact number, estimate conservatively and use it. “Reduced average handle time by roughly 20%” is infinitely stronger than “reduced average handle time.”
The standard sections are: Experience, Projects, Education, Technical Skills. That’s it. Leave out hobbies, references, photos, and an objective statement. For skills, only list years of experience if the number is impressive — otherwise just list the skill.
“Python — 1 year” actively works against you. If you’re not proud of the number, drop it. A flat skills list is fine. Only highlight tenure for skills where longevity is a genuine differentiator.
You will not catch your own typos. You’ve read this document too many times. A fresh pair of eyes catches the things you’ve gone blind to — grammatical awkwardness, missing context, claims that sound clear to you but confuse everyone else.
You’ll hear a lot about writing “ATS-compliant” resumes — plain formatting, keyword stuffing, machine-readable layouts. My honest take: optimising purely for ATS often produces a resume so bland it gets ignored by the humans who see it after the filter. The best approach is to use the job description’s language naturally (rule #3) so you pass the filter, and then make the content compelling enough that the human picks up the phone. Don’t trade human readability for algorithmic compliance.
If you still want to go the ATS route, Jobscan’s templates are a solid starting point.
Also worth reading: How to Write an Effective Developer Resume — Stack Overflow Blog. Written for engineers but the advice is universal.