How to Write Resume Bullet Points That Show Impact, Not Just Activity
TL;DR
- Most resume bullets describe activity. Good bullets show outcomes.
- The "so what" test: after every bullet, ask yourself "so what?" If you can answer that question, it should be in the bullet.
- Metrics help, but they're not required. Specificity is what matters.
- Weak verbs ("worked on," "helped with," "was responsible for") are the most common problem.
- Before/after rewrites are the fastest way to improve a resume.
The most common resume mistake is not lying. It's underselling.
Candidates write bullets that describe what they did at a surface level, but leave out the part that actually tells a hiring manager whether to be interested.
"Worked on the authentication system" is a real thing you did. It doesn't tell anyone what you built, what problem it solved, how complex it was, or what the result was. It asks the reader to do interpretive work, and most readers won't.
Writing bullets that show impact instead of just activity is a skill. It's learnable. And it changes the response rate on your applications more than almost any other resume improvement.
The Core Difference: Activity vs. Outcome
An activity bullet describes what you were doing.
An outcome bullet describes what happened because you did it.
Here's the same piece of work written both ways:
Activity: Worked on improving database queries for the admin dashboard.
Outcome: Rewrote slow admin dashboard queries using indexed lookups, reducing average page load time from 4 seconds to under 1.
Same job. Same code. Completely different signal to the reader.
The activity version tells the hiring manager you touched some database code. The outcome version tells them you identified a performance problem, understood the cause (missing indexes), implemented a fix, and measured the result. That's a different level of engineering than "worked on queries."
The work was the same. The writing is what changed.
The "So What" Test
For every bullet on your resume, ask one question after writing it: so what?
"Implemented user authentication using JWT." So what?
So what means: why does that matter? What changed because you did it? What problem did it solve? What did it enable?
If you can answer "so what," the answer belongs in the bullet.
"Implemented user authentication using JWT, enabling secure session management across a multi-tenant SaaS application serving three client accounts."
Now it's not just a technology name. It's a feature that served a real purpose in a real system with real users.
The "so what" test catches the most common failure mode in resume writing: stopping one step before the useful information.
Strong Verbs vs. Weak Verbs
The verb that opens each bullet sets the tone for everything that follows.
Weak verbs that lose you credibility: - Worked on - Helped with - Was responsible for - Assisted in - Participated in - Involved in
These verbs put you in a passive or supporting role, even if you were the main engineer on the work. "Worked on the payment integration" could mean you wrote every line. It sounds like you handed someone a coffee while they worked.
Strong verbs that place you as the actor: - Built - Designed - Implemented - Refactored - Reduced - Migrated - Automated - Deployed - Integrated - Debugged - Architected - Wrote
Pick the verb that most accurately describes what you actually did. If you designed something, say designed, not "worked on the design." If you were the person who reduced the error rate, own that verb.
What to Do When You Have No Metrics
"I don't have numbers to put in my bullets" is the most common objection to this kind of resume advice.
Here's the thing: specific language matters more than quantified language.
Metrics are one form of specificity. They're the best form when you have them. But specificity can come from other places.
Consider the difference between:
Generic: Built a feature for user notifications.
Specific (no metrics): Built a real-time notification system using WebSockets that delivered event alerts to users without requiring page refreshes.
The second bullet has no numbers. But it tells you the technology (WebSockets), the mechanism (real-time delivery), the specific behavior eliminated (page refreshes), and the user-facing outcome (event alerts delivered). That is a useful bullet.
Specificity comes from: - The technology you used (not just "database" but "PostgreSQL with Redis caching") - The problem you were solving ("to reduce duplicate support tickets") - The scale or context ("across 12 microservices," "for a team of 8 engineers") - The outcome in concrete terms ("which allowed users to complete checkout without re-entering shipping information")
You almost always know more than you're writing. The problem is usually that you're being vague out of habit, not because you lack information.
Before/After Examples
Here are rewrites across a few common situations:
Situation: Internship experience
Before: Assisted the backend team with various API development tasks.
After: Built three REST API endpoints for the user profile service in Python/Flask, including input validation and error handling, as part of a team of four engineers.
Situation: Portfolio project
Before: Created a full-stack web application using React and Node.js.
After: Built a recipe management app with React and Node.js that lets users save, tag, and search recipes by ingredient, with user authentication and persistent data storage via PostgreSQL.
Situation: Performance improvement (no exact metric)
Before: Worked on optimizing the front-end performance of the application.
After: Identified and removed unnecessary re-renders in the React component tree, improving perceived load time on low-bandwidth connections.
Situation: Infrastructure/DevOps
Before: Helped set up CI/CD pipeline for the team.
After: Configured GitHub Actions CI/CD pipeline for automated testing and deployment, reducing manual deployment steps from eight to two.
Situation: Bug fix that mattered
Before: Fixed bugs in the codebase.
After: Tracked down and fixed a race condition in the session token refresh logic that was silently logging users out on mobile devices.
In every case, the rewritten bullet uses a strong verb, is specific about the technology and the problem, and includes some form of outcome or context that makes the work legible to someone who wasn't there.
The Length Question
Resume bullets should be one to two lines. Three lines is too long almost every time.
If a bullet runs three lines, it usually means one of two things: you're describing multiple pieces of work in a single bullet (split them), or you're over-explaining at the expense of clarity.
One strong line is better than two vague lines. Two specific lines are better than one impressive-sounding but vague line.
Aim for bullets that a reader can absorb in two seconds. They are not reading your resume top to bottom. They are scanning, then reading sections that catch their attention. Understanding that scan pattern changes how you structure every bullet.
How Many Bullets Per Entry
For a job or internship with several months of work: three to five bullets.
For a project entry: two to three bullets, sometimes four if the project was significant.
More than five bullets per entry usually means you're padding. Less than two usually means you're underselling.
The question to ask about each bullet before including it: does this demonstrate a skill, a decision, or an outcome that the hiring manager for this role would care about? If yes, keep it. If you're including it because you did it and it took you a while, that's not a good reason.
A Common Trap: Listing Technologies Instead of Work
Some bullets turn into technology inventories.
"Used React, Redux, TypeScript, Styled Components, and React Router to build the front end."
That's a list of imports. It tells the reader nothing about what you built, what decisions you made, or what problems you solved.
Technologies belong in bullets as context for the work, not as the point of the bullet.
Better: "Built the front-end routing and global state management in React and Redux, enabling navigation between five app sections without full page reloads."
Now the tech names appear, but in service of explaining what you did and why it mattered. That's how technology mentions work in a resume bullet.
Tailoring Bullets to the Job Description
The same project can be described in different ways depending on what a specific job is emphasizing.
If you're applying to a role that focuses on backend systems, lead your project bullet with the backend work. If the role emphasizes front-end, lead with that. You're not changing what you built. You're choosing which aspect to surface first.
This is the right kind of tailoring. Not fabricating qualifications you don't have, but choosing which true things to emphasize for which audience.
Scan the job description for the technologies and responsibilities they mention most. Then look at your bullets and ask: am I making it easy to see the overlap? If a job says "experience with database optimization" and your bullet says "worked on queries," you have the experience. Your bullet just doesn't show it.
A resume that passes the recruiter's initial scan still needs bullets that hold up under a real read. Bullet quality is what converts an initial screening into a call.
Writing Bullets When You're Still in School
If you're currently finishing a degree or bootcamp and writing bullets for coursework or class projects, the same rules apply.
"Completed CS 361 Operating Systems course" is activity language. "Implemented a multi-threaded process scheduler in C as part of Operating Systems coursework, handling priority queues and deadlock detection" is outcome language.
You don't need work experience to write outcome bullets. You need to describe what you built, what it did, and what you learned to apply.
For more on how to present project work specifically, the projects section guide covers the full format for project entries and how to decide what to include.
Strong bullet points are the engine of a resume. They're what converts a recruiter's initial interest into a request for an interview. The software engineering resume guide covers where bullets fit into the overall structure and what each section of the resume is doing.
If you want hands-on help rewriting your specific resume bullets with feedback on what's working and what isn't, here's how the Globally Scoped program works.
Interested in the program?