Before & After: Rewriting an Engineer's Resume That Got Zero Callbacks
Before & After: Rewriting an Engineer's Resume That Got Zero Callbacks
Here is a resume that belongs to a real category of engineer: five years of experience, shipped production systems, never had a layoff, got promoted once. By any reasonable measure, a strong candidate.
After 47 applications, they had two phone screens.
The resume wasn't lying. It had all the right companies, the right stack, the right tenure. What it didn't have was a story — or evidence. It looked like a list of things someone did, written by someone who didn't want to seem like they were bragging. Recruiters have a word for that category of resume: filtered out.
This post walks through that resume line by line — the summary, skills section, and two job entries — explains each problem, then shows the rewrite, with a note on why each change works.
The Subject
The composite engineer we're working with — call them Alex — has this background:
- 5 years of experience, two companies
- Current title: Backend Engineer at a mid-size B2B SaaS company
- Stack: Python, FastAPI, PostgreSQL, AWS (ECS, Lambda, RDS), some React for internal tools
- What they actually did: Built the data export pipeline that now handles 12M events per day. Led the migration of their team's monolith services to microservices. Reduced on-call incident rate by rearchitecting their alerting stack.
- What their resume said: almost none of that
The Before Resume
Here is a lightly condensed version of Alex's original resume — the version that got 2 responses from 47 applications.
SUMMARY
Experienced software engineer with a background in backend development and a passion for building scalable systems. Strong problem-solver who works well in team environments. Eager to contribute to innovative companies driving meaningful impact.
SKILLS
Python, JavaScript, TypeScript, React, Node.js, FastAPI, Django, Flask, Go, Java, PostgreSQL, MySQL, MongoDB, Redis, DynamoDB, AWS, GCP, Azure, Docker, Kubernetes, Git, CI/CD, Agile, REST APIs
EXPERIENCE
Backend Engineer — [Current Company], 2023–Present
- Worked on the data pipeline team and was involved in the design of the export service
- Helped migrate services from a monolith to microservices architecture
- Participated in on-call rotations and assisted with incident response
- Contributed to improving system reliability and performance
- Used Python and AWS services to build backend features
Software Engineer — [Previous Company], 2021–2023
- Developed various backend features for the company's main product
- Worked on API development and database optimization
- Collaborated with the frontend team to integrate services
- Assisted in the deployment pipeline and testing infrastructure
- Participated in code reviews and agile ceremonies
The Teardown
Alex's resume has five problems that compound each other. Any one of them is survivable. Together, they guarantee filtering.
Problem 1: The summary says nothing
"Passion for building scalable systems. Strong problem-solver."
Every engineer on the market says exactly this. A recruiter reading 200 resumes in a day has seen this sentence ten times before lunch. It tells them nothing about what Alex specializes in, what companies Alex has shipped for, or why Alex is worth fifteen minutes on the phone.
The summary has two jobs: establish your positioning and earn the recruiter's attention in two sentences. Alex's summary does neither.
Problem 2: The skills section is noise
Twenty-five-plus items in an undifferentiated list. Python sits next to Agile. AWS is listed at the same weight as Redis. There's no hierarchy, no evidence that any of these are real strengths versus things Alex touched once in 2022.
Modern ATS platforms and the humans who read filtered results both penalize this. AI-enhanced ATS treats undifferentiated breadth as a noise signal — it lowers your relevance score for the specific role because the system can't determine what you actually specialize in. The recruiter who does read it can't either.
Problem 3: Every bullet is a task, not an outcome
"Worked on the data pipeline team and was involved in the design of the export service."
This tells a reader what Alex was around, not what Alex did. "Involved in the design" is one of the most common resume bullet patterns — and one of the most damaging, because it explicitly signals passive participation. The bullet that should be the strongest entry on Alex's resume is instead an argument for a junior IC.
Recruiters spend an average of 7.4 seconds on a resume. In those 7.4 seconds they're scanning for three things: system scale, technical ownership, and measurable impact. Alex's bullets answer none of those questions.
Problem 4: The passive vocabulary undermines credibility
Count the hedging words: worked on, helped, participated in, assisted with, contributed to, collaborated with, was involved in. These are phrases that signal supporting cast. They're what you write when you don't want to overclaim — but they read as if you accomplished nothing.
Engineers who shipped real work have better language available: designed, owned, led, reduced, migrated, rearchitected, shipped. If those words aren't on your resume, you look like a side character in your own career story — even if you were the person who actually built the thing.
Problem 5: There is no narrative thread
The two jobs could belong to two different engineers. Nothing connects them. There's no specialization signal, no progression visible, no hint of what kind of problems Alex is built to solve. A hiring manager reading both roles can't tell what Alex wants to do next or why the target role would be a natural fit.
This is the core problem that resume narrative is trying to solve — and it doesn't fix itself by adding better bullet points. It requires knowing what story you're telling before you start writing.
The Rewrite
Here is the same resume — same two jobs, same actual work history — after a structured rewrite. Nothing was fabricated. Everything was in the original; it just wasn't surfaced.
SUMMARY
Backend engineer with 5 years building high-throughput data systems on Python and AWS. At [Current Company], designed the event export pipeline now processing 12M events/day and led a 6-service monolith-to-microservices migration that cut mean deployment time by 60%. Looking for backend or platform roles where data infrastructure and service architecture are core to the work.
SKILLS
Languages: Python, TypeScript, Go Frameworks: FastAPI, React Cloud: AWS (ECS, Lambda, RDS, S3) Databases: PostgreSQL, Redis, DynamoDB Infrastructure: Docker, Kubernetes, Terraform Observability: Datadog, CloudWatch, PagerDuty
EXPERIENCE
Backend Engineer — [Current Company], 2023–Present
- Designed and owned the event export service processing 12M events/day across 40+ enterprise customers; reduced median export latency from 4.2s to 380ms via async queue architecture (FastAPI + SQS + Lambda)
- Led migration of 6 monolith services to microservices over 8 months; reduced mean deployment time from 3.5 hours to 85 minutes and eliminated 4 classes of cross-service coupling bugs
- Rearchitected on-call alerting stack (PagerDuty + CloudWatch composite alarms); cut false-positive page rate by 73%, reducing team on-call incidents from ~22/month to ~6
- Designed schema and query optimization for high-read PostgreSQL tables (1.2B rows); p99 query latency dropped from 1.8s to 140ms
Software Engineer — [Previous Company], 2021–2023
- Built and shipped the customer billing API serving 8,000 daily active accounts; the first engineer to own an external-facing API end-to-end at the company
- Reduced database query time for the main product dashboard by 62% through index analysis and query restructuring (PostgreSQL); directly unblocked a sales motion on a 200-seat enterprise account
- Implemented integration test suite for the deployment pipeline from scratch; raised coverage on the payments module from 34% to 91%, cutting production incidents in that module by half in the following quarter
- Mentored 2 junior engineers on backend architecture patterns; both were promoted within a year
What Changed and Why
The summary now establishes positioning
The rewritten summary does three things: names the specialization (data systems, Python, AWS), leads with the highest-impact proof point (12M events/day), and states what Alex is looking for. A recruiter reading this in 7 seconds now has a complete answer to "should I move this person to the phone screen" pile.
The old summary would fit any engineer. The new one could only be Alex.
The skills section has hierarchy and depth
The list went from 25+ items to ~18, organized by category. Languages are cut to the three Alex would actually use. Cloud is broken down to specific AWS services — parsers look for ECS, Lambda, and RDS separately from the platform name. Observability is added as its own category, which is a differentiating signal for senior roles that most candidates skip.
What got removed: Django, Flask, Node.js, Java, GCP, Azure, MySQL, MongoDB, Agile. All real but none relevant to the roles Alex is targeting. Every irrelevant keyword dilutes the overall relevance score.
Every bullet answers "what got better because I was here?"
The rewrite follows a simple formula: verb that signals ownership + what the system was + scale or constraint + the measured result. Every single bullet in the rewrite has a number. Not because numbers are magic, but because numbers are the only way to give a recruiter a reference point.
"Designed and owned the event export service processing 12M events/day" is specific enough that a recruiter can ask a real question about it in a phone screen. "Worked on the data pipeline team" is not.
The vocabulary shifted from observer to owner
The hedging verbs are gone. Alex designed, led, built, shipped, rearchitected, implemented, mentored. These aren't bragging — they're just accurate. Alex did these things. A resume's job is to represent what you did, not to be modest about it.
There's a narrative now
Both entries now read like a backend engineer who specializes in high-throughput data systems and infrastructure — which is exactly what Alex wants to do next. The second job shows the trajectory: first engineer to own an external API, mentored junior engineers, built test infrastructure from scratch. The first job shows the scale that followed. Together they tell the story of someone who grew into a data infrastructure specialist.
A hiring manager targeting a senior backend or platform role now has a coherent answer to: why does this person want this job, and do they have the experience to be credible?
The Self-Audit Framework
Use this to review your own resume before you send the next application:
- Does your summary name your specialization? If it could describe any engineer, rewrite it.
- Does every bullet have a number? If not, go find the number — deployment frequency, query latency, event volume, team size, timeline, something. The number is almost always accessible if you look.
- Count the hedging verbs. Any bullet starting with worked on, helped, assisted, participated in, contributed to needs a rewrite.
- Is your skills section organized by category with depth? If it's a flat list of 20+ items, cut it to the 12–15 that matter for the roles you're targeting.
- Can a recruiter who reads both jobs identify what you specialize in? If the answer is "backend" or "software" — not a specialization. Name the domain: data infrastructure, payments, distributed systems, ML platform, whatever it actually is.
For the full framework on structuring your experience section: The Engineer's Guide to Resume Writing in 2026.
The Uncomfortable Part
The reason most engineers write resumes like Alex's original isn't laziness. It's discomfort with self-advocacy combined with a genuine uncertainty about what's worth claiming.
"I didn't design it alone — I worked with the team." True. But you led the migration. That's yours to claim.
"The latency numbers might be slightly off." Check Datadog. Get close. "From ~4s to ~400ms" is more useful than no number at all.
"I don't want to oversell." There's a wide gap between overselling and accurately representing what you built. Most engineers who think they're being appropriately modest are actually underselling by a lot.
The rewritten resume isn't a different story. It's the same story, told by someone who knows what they did and isn't afraid to say so.
That's the only change that matters.
If your resume reads more like Alex's original than the rewrite, Wrok can help close the gap. You tell Wrok what you worked on — the projects, the systems, the scale — and Wrok extracts the narrative, finds the numbers worth surfacing, and rewrites your experience into the format that actually gets callbacks.
For a deeper look at why the top-of-funnel works the way it does: The Resume Funnel: Why Most Software Engineers Never Get Interviews.