Before we begin:
I’m doing free resume/linkedin reviews for all founding subscribers! Email me your info to randomrecruiter3@gmail.com once upgraded.
If you want to send in a mailbag question, you can email it to me as well, this is for all paid subscribers.
In this issue
Why most resume bullets sound like job descriptions
The three questions every bullet should answer
How to use the Google XYZ method
What to do when you don’t have metrics
I’ve reviewed thousands of resumes over the last ten years and lot of them come from strong candidates who’ve worked on important projects and solved difficult problems.
You’d just never know it from reading their resume.
The experience is usually buried under bullets like:
Responsible for developing Java applications
Worked with business stakeholders
Participated in cloud migration projects
Helped improve application performance
None of these bullets are technically wrong, they’re just not telling me anything useful.
Being responsible for developing applications doesn’t mean you were good at it. Participating in a cloud migration could mean you designed the entire thing or sat quietly through a few Teams calls.
A resume shouldn’t just confirm that you had a job but should show me what happened because you were there.
Stop Copying Your Job Description
This is usually where the problem starts.
Someone decides to update their resume, pulls up the original job description, and rewrites the responsibilities in the past tense.
The job description says:
“Responsible for designing and maintaining scalable software applications.”
So the resume says:
“Designed and maintained scalable software applications.”
Congratulations. We now know you did what the company hired you to do.
Your job description explains what the company expected from you but resume should explain what you actually delivered.
Those aren’t the same thing.
If you’re a recruiter, I already know you sourced candidates and worked with hiring managers. If you’re a software engineer, I already know you wrote code and fixed bugs.
That’s the basic function of the job, so why repeat yourself?
You need to focus on the actual impact you made while you were there.
Did you fill 40 roles? Did you reduce production incidents? Did you speed up a release? Did you automate a process that was wasting 20 hours every week?
That’s what belongs on the resume.
Every Bullet Should Answer Three Questions
When I’m helping someone rewrite a resume, I keep asking the same three questions:
What did you do?
How did you do it?
Why did it matter?
Most resume bullets only answer the first question, and even then the answer is usually vague.
Let’s take a common engineering bullet:
“Improved application performance.”
Fine. But what does that even mean?
What part of the application did you improve? What was causing the problem? What did you change? How much better did it perform?
Usually, once I ask the candidate a few questions, I get the real story.
The application was taking eight seconds to load. Customers were abandoning transactions. The engineer found several slow database queries, rewrote them, and introduced caching. Load time dropped to three seconds.
That’s the bullet:
“Reduced application load time from eight seconds to three by rewriting slow SQL queries and introducing Redis caching, improving transaction completion for customers.”
Now I understand what you did, how you did it, and why it mattered.
The candidate had all of that information in their head. They just wrote “improved application performance” because they assumed the hiring manager would fill in the blanks.
They won’t.
Your resume might get 20 or 30 seconds on the first review. Nobody’s sitting there thinking deeply about what you may have meant. If the value isn’t clear, the reader moves on.
What to do about it: Read every bullet and ask those three questions. If the answer isn’t on the page, add it. The reader should understand your contribution without interviewing you first.
Use The Google XYZ Method
If you’re struggling to put a bullet together, use the Google XYZ method:
“Accomplished X, measured by Y, by doing Z.”
X is what you accomplished.
Y is the result.
Z is how you did it.
For example:
“Reduced production incidents by 30% by adding automated testing and improving deployment checks.”
You accomplished a reduction in incidents. The improvement was measured at 30%. You did it by adding testing and improving the deployment process.
That’s a complete bullet.
The formula works because it forces you to move past responsibilities and explain impact. It also gives the interviewer something specific to ask about.
But don’t force every bullet into the exact same sentence structure. When every bullet follows the formula perfectly, the resume starts sounding like it was assembled in a lab.
The XYZ method is a framework, not a legal requirement.
Sometimes the result belongs at the beginning:
“Cut incident response time from 90 minutes to 35 minutes by creating automated alerts and a clearer escalation process.”
Sometimes the action should come first:
“Automated weekly financial reporting using Python, saving the finance team eight hours of manual work each month.”
Both work.
The order matters less than including the right information.
You Probably Have More Metrics Than You Think
The most common objection I hear is, “I don’t have any numbers.”
Sometimes that’s true. Most of the time, the person just isn’t thinking broadly enough.
A metric doesn’t always need to be revenue generated or costs reduced. You can use the number of users you supported, applications you migrated, people you hired, tickets you resolved, projects you delivered, customers you onboarded, or hours of manual work you eliminated.
You can also use time.
Maybe a process took five days before you changed it and now takes two. Maybe your team released software once a month and now releases every week. Maybe it took 90 minutes to respond to an incident and now it takes 30.
Those are real results.
Let’s say a recruiter writes:
“Recruited software engineers for several business units.”
That could become:
“Filled 38 software engineering roles across four business units by building targeted sourcing campaigns and creating a weekly interview process with hiring managers.”
We now know the hiring volume, the scope, and how the recruiter did it.
If you don’t have a number, explain the result in plain English. Maybe you fixed a recurring outage, helped the company pass an audit, or completed a migration before a data center shutdown.
That’s still impact.
I’d rather see an honest result without a number than a suspiciously perfect metric you can’t explain. If your resume says you improved efficiency by 37%, someone might ask how you calculated it.
You’d better have an answer.
Your Resume Should Make The Interview Easier
Good resume bullets don’t just help you get selected for an interview. They help shape the conversation once you’re there.
If your resume says you “worked on a cloud migration,” the interviewer has to drag the story out of you.
If it says you “migrated 45 applications to AWS before a data center shutdown,” the interviewer already knows where to start.
How did you prioritize the applications? What problems came up? How did you work with security?
Those are good questions because you’ve done the work and you know the answers.
Before you add another bullet, ask yourself:
What did I do?
How did I do it?
Why did it matter?
If the bullet answers all three, keep it.
If it only explains what your job was, rewrite it.