An engineering resume is read twice in quick succession, and the two reads are looking for different things. The recruiter is looking for stack signals and a seniority match. The hiring manager — usually an engineering manager or staff engineer — is looking for scope, ownership, and judgment. Strong engineering resumes are tuned to hit both reads.

This post is what each reader is actually scanning for, and what specific edits move a resume up a level.

The two-tier scan

Most candidates write their engineering resume for the hiring manager and forget about the recruiter. Both reads matter, and they happen in sequence — the recruiter screens first, then forwards to the hiring manager. If you fail the recruiter pass, the hiring manager never sees the page.

Recruiter pass (~10 seconds). What stack is on this? How many years of experience? What level title? Does this match the requisition I'm filling? The recruiter is matching nouns to nouns — your stack to the JD's stack, your years to the JD's range, your title to the JD's title.

Hiring-manager pass (~60-90 seconds). What did this person actually do? Did they own things or were they contributors? What's the scope of their work? Can they design systems or just execute features? The hiring manager is reading verbs and impact lines.

The same resume needs to deliver on both. Optimizing for one at the expense of the other is the single most common mistake on engineering resumes.

The two keyword sets

The keyword diff above shows the structural mismatch. A typical engineering resume has the recruiter-side keywords — stack names, years, role titles — because candidates tune for ATS readability. They often miss the hiring-manager keywords — leadership verbs, ownership phrases, scope indicators.

The fix is not to rewrite the whole resume. It's to add a small number of phrases that signal hiring-manager-grade work without changing the structure. Phrases that work:

• "Led the design of..."
• "Owned end-to-end..."
• "Drove the decision to..."
• "Scaled X from Y to Z..."
• "On-call for..." (significant signal for senior backend roles)
• "Reviewed and shipped..." (vs. just "shipped")

Two or three of these phrases per role is enough to flip how a hiring manager reads the resume.

For more on how ATS and recruiter keyword layers differ, see ats-keywords-vs-recruiter-keywords.

What seniority actually sounds like in a bullet

The compare-list is the working filter for your bullets. Run each bullet through it: does the verb describe a senior contribution, or does it describe a contributor's contribution?

The most common failure mode is the verb "worked on." It is the verbal equivalent of a beige paint sample. It does not communicate whether you wrote three lines of the project or led it for nine months. Recruiters and hiring managers both read "worked on" as the candidate hedging — usually toward less involvement than they had.

The second failure mode is omitting the team-and-scope context. "Built REST APIs" doesn't tell anyone whether you were the only engineer or one of fifty. "Built the public REST + webhooks API as the senior engineer on a 3-person team" tells them everything in one sentence.

Five concrete edits

The five edits above are the highest-leverage moves you can make on an engineering resume in a single sitting. Each one is mechanical — you can run them all in 45 minutes — and each one has an outsized effect on how the resume reads.

The most underrated edit is putting the stack in the role line. A typical engineering resume buries the stack in scattered bullets, forcing the recruiter to hunt. A clean resume puts the stack in a single line under each role:

Senior Software Engineer · [Company] · 2022 – 2025 Stack: Python, Django, PostgreSQL, Kafka, Kubernetes, AWS, Terraform

This single line lets the recruiter check stack-match in 3 seconds. It also frees the bullets to focus on what you actually did rather than what tools you used.

For broader bullet-rewriting patterns, see achievements-vs-responsibilities. For action-verb choices that aren't recycled clichés, see resume-action-verbs-that-arent-cliche.

The structure that holds up under the two-tier scan

The skeleton of a strong engineering resume:

Top of page: Name, contact, LinkedIn, GitHub (if your GitHub is real and recent). 3-4 lines max.

Summary section (optional): Two lines. "Senior backend engineer with 8 years building B2B SaaS infrastructure. Last 4 years on platform teams owning payments, identity, and developer APIs." Skip if it would be generic; see resume-summary-section.

Experience section: Reverse chronological. Role title, company, dates, stack line, 4-6 bullets per role. Bullets should be achievement-led, scoped, and end on impact.

Skills section: Single block at the bottom. Languages, frameworks, infra, tools. No skill bars or proficiency ratings — they don't help.

Education: One line. Degree, school, year. Skip if 10+ years out.

Optional sections: Open-source contributions (if substantial), publications (if peer-reviewed), notable side projects (if relevant). Skip filler.

Most engineering resumes try to do too much. Two pages of bullets across 6 roles is harder to scan than 1.5 pages across 4 well-edited roles.

What the hiring manager looks for that the recruiter doesn't

The hiring manager is checking for three patterns that the recruiter doesn't have time to look for:

Did you ship something hard? A 1-sentence description of a project that was genuinely difficult — a migration, a refactor, a new architecture — anchors the resume. Hiring managers remember resumes that have one specific war story.

Do you own things? Ownership shows up in how you describe outcomes. "Reduced P1 incidents 60%" implies you were on-call and accountable. "Helped reduce P1 incidents" implies you were one of many. The hiring manager reads both lines and treats them very differently.

Can you make decisions? Phrases like "drove the decision to..." or "made the call to..." signal architectural judgment. They're rare on resumes and disproportionately valued.

For more on quantifying impact when you don't have hard numbers, see quantifying-resume-without-metrics.

What this isn't

A few clarifications:

• It's not a portfolio. Your GitHub and writing show what you've built. The resume shows what you've delivered in a job.
• It's not a list of every framework you've touched. Listing 28 technologies tells the reader you've used none of them deeply. List the 8-12 you'd be comfortable being interviewed on.
• It's not the same as a PM or design resume. Engineering resumes can use technical specificity that other roles can't. Use it.

The short version: the recruiter scans for stack and years; the hiring manager scans for ownership and scope. The same page needs to deliver both. Five edits, 45 minutes, and the same resume moves up a level for the same person.