A senior recruiter at a mid-size fintech company told me she spends roughly 7 seconds on a resume before deciding whether to read it properly. Not 30 seconds. Seven. That number has stuck with me because it changes how you should think about what a resume is actually for.
A resume isn’t a career history. It’s a filter-passing document. Its job is to survive an ATS scan, survive a 7-second human skim, and earn a longer read. That’s the whole function.
How ATS actually works (and what it doesn’t do)
Most engineers overestimate how smart applicant tracking systems are. They’re mostly keyword matchers running against a parsed version of your document. The parsing is the problem. A two-column layout, a text box, a table, or a header/footer with contact info can all cause parsing failures where your name shows up as part of your job title, or your skills section disappears entirely.
Single-column. Standard section headers (“Work Experience”, not “Where I’ve Been”). No text boxes. Export as PDF, but confirm the job posting doesn’t ask for Word. These aren’t stylistic preferences, they’re parse-safety choices.
The BLS Occupational Outlook Handbook projects software developer roles to grow 17% through 2033, faster than almost any other professional category. More candidates per opening. ATS rejection before human eyes is increasingly the norm, not the exception.
The bullet format that actually gets read
The XYZ formula is older than most of the frameworks you use, but it holds up: “Accomplished X, as measured by Y, by doing Z.” You don’t need to be rigid about the order. But every bullet needs all three elements.
Bad: “Responsible for improving application performance.”
Better: “Cut API response time from 840ms to 190ms by replacing synchronous ORM calls with a batched async query layer, reducing p99 latency for 47,000 daily active users.”
The specific odd number (47,000, not “thousands”) is doing work there. It signals that you actually know the scale of what you built. Vague bullets read as either delegated work or remembered-wrong work.
One thing I’m genuinely unsure about: whether quantifying every bullet backfires at senior levels. Some hiring managers I’ve talked to say that a staff engineer resume full of metrics starts to look like you’re optimizing for the resume, not the work. I don’t have good data on this either way, so take that as an open question rather than advice.
Skills sections: shorter is usually better
The instinct is to list everything. React, Next.js, TypeScript, JavaScript, Node.js, Express, PostgreSQL, MySQL, MongoDB, Redis, Docker, Kubernetes, AWS, GCP, Azure, Git, GitHub, CI/CD, Agile, Scrum, Jira.
That list is noise. A hiring manager scanning it learns almost nothing about how good you are at any of it. Worse, listing AWS, GCP, and Azure together signals surface-level exposure to all three, not depth in any.
Group by genuine proficiency. Keep the list to 13 or fewer technologies where you can speak credibly for 20 minutes. Move the rest to “familiar with” at the bottom, or drop them entirely. If it comes up in the interview, you can mention it then.
Projects and open-source work
For engineers with under 3 years of experience, this section matters more than most resume advice acknowledges. A well-described side project with real users, a GitHub repo with actual stars, or a PR merged into a notable open-source library can outweigh a mediocre work history at a company that didn’t ship much.
For senior engineers, I’d push back on including projects at all unless they’re directly relevant to the role. A staff-level candidate’s two-page resume doesn’t have room for a weather app they built in 2019.
The tailoring problem
Job descriptions are usually written by a recruiter translating a hiring manager’s notes. They’re imprecise. But they contain signal: the specific technologies mentioned, the verb choices (“design” vs. “implement” vs. “own”), the order of requirements.
You don’t need to rewrite your resume for every application. You need one version of your resume per rough job family: one for backend IC roles, one for platform/infra roles, one for tech lead roles. Swapping 4 bullet points per application is about the right level of tailoring effort.
The 2024 Stack Overflow Developer Survey found that roughly 62% of developers who changed jobs in the previous year applied to fewer than 10 companies. Targeted beats high-volume. A tighter application list with better-tailored materials consistently outperforms spray-and-pray.
What interviewers actually skip
Objective statements. Nobody reads them. If your resume opens with “Seeking a challenging software engineering role where I can grow my skills and contribute to a dynamic team,” the next 7 seconds are gone.
References available upon request. Obviously. Drop it.
Full mailing address. City and state is enough. A full street address on a resume submitted online serves no purpose and slightly increases risk.
Formatting perfection. A minor inconsistency in bullet size will not cost you an interview. Getting the substance right matters more than pixel-level polish. Spend your effort on the bullets, not the margins.
If you’re preparing for actual interviews after the resume starts working, Craqly’s AI interview copilot lets you practice answering questions about your own resume before you’re in the room. Worth running through once before your first call.
The resume gets you the conversation. What you do in the conversation is a different problem entirely.