Resume Bullet Points Examples Software Engineer: 10 Before-and-After Rewrites
Published ยท Finch Team
Updated
Most resume bullet points for software engineer roles are bad. Not because the experience behind them is bad, but because people describe what they did instead of what they accomplished. "Worked on the backend" tells a recruiter nothing. "Reduced API response time by 40% by implementing Redis caching on the 3 most-hit endpoints" tells them exactly what kind of engineer you are.
I'm going to show you 10 real resume bullets, rewritten from the kind of thing most CS students write to the kind of thing that actually gets interview callbacks. Each one uses a simple framework and comes from a common situation: internships, class projects, TA roles, hackathons, and research.
The XYZ Formula (And Why It Works)
Google's recruiters popularized this and it's still the best structure for resume bullet points:
Accomplished [X] by doing [Y], resulting in [Z].
X is the impact or achievement. Y is what you specifically did. Z is the measurable result.
Not every bullet needs all three parts. Sometimes you don't have a measurable result and that's fine. But the structure forces you to lead with impact instead of leading with a task description. That shift (from "what I was assigned" to "what I delivered") is the whole difference between a resume that gets skimmed and one that gets a callback.
Let's get into the rewrites.
Rewrite 1: The Vague Internship Bullet
Before: "Worked on the backend team to develop new features for the platform."
After: "Designed and implemented 3 RESTful API endpoints for user notification preferences, serving 12K daily active users and reducing support tickets related to notification settings by 35%."
What changed: "Worked on" became specific endpoints with a number. "The platform" became a feature with user count. The result (fewer support tickets) ties the work to business impact.
You almost always know more specifics than you think. How many users? How many endpoints? What was the feature? Even rough numbers ("~10K users") are better than no numbers.
Rewrite 2: The Class Project With No Context
Before: "Built a web application for our software engineering class using React and Node.js."
After: "Built a full-stack event management app (React, Node.js, PostgreSQL) supporting user auth, RSVP tracking, and email notifications, deployed on AWS EC2 with CI/CD via GitHub Actions."
What changed: Named the actual application instead of just "web app." Listed the tech stack with specifics. Mentioned deployment and CI/CD, which shows the project went beyond localhost. Class projects are fine on resumes, but they need to sound like real projects, not homework.
For more on making projects look strong on your resume, check out our guide on how to list projects on your resume.
Rewrite 3: The TA Who Just "Helped Students"
Before: "Helped students with programming assignments during office hours."
After: "Held 6 hours/week of office hours for 180-student Data Structures course, debugging student implementations of AVL trees, hash maps, and graph algorithms in Java."
What changed: Added the scale (180 students, 6 hours/week). Named the specific data structures. Mentioned the language. This turns a generic "I was a TA" bullet into evidence that you know data structures well enough to teach and debug them.
Rewrite 4: The Hackathon Without Results
Before: "Participated in HackTX and built a project with my team in 24 hours."
After: "Won Best Use of AI prize at HackTX (200+ participants) by building a resume-to-job matcher using OpenAI embeddings and cosine similarity, processing 500+ job listings in under 3 seconds."
What changed: "Participated" became "Won a prize" (if you won one). Named the technical approach. Added a performance metric. If you didn't win anything, you can still make it specific: "Built a real-time collaborative whiteboard using WebSockets and Canvas API, supporting 8 simultaneous users with sub-100ms latency."
The point is to describe what you built and how it performed, not just that you attended.
Rewrite 5: The Research Assistant Doing "Data Analysis"
Before: "Assisted professor with research involving data analysis and machine learning."
After: "Developed a Python pipeline to preprocess and classify 50K+ biomedical abstracts using scikit-learn (SVM, Random Forest), achieving 87% F1 score on multi-label classification of research topics."
What changed: Named the dataset size, the tools, the specific algorithms, and the evaluation metric. Research bullets are where CS students undersell themselves the most. You did real technical work. Describe the technical work.
Rewrite 6: The Internship "Bug Fixer"
Before: "Fixed bugs and wrote unit tests for the codebase."
After: "Resolved 40+ Jira tickets across the payments microservice, including a race condition in transaction processing that had caused $2K/month in duplicate charges, and increased test coverage from 45% to 78%."
What changed: Quantified the bugs fixed. Described the most impactful one specifically. Put a dollar amount on the impact. Showed test coverage improvement with before/after numbers.
You don't always have dollar amounts, but you can almost always get before/after numbers. Test coverage, response time, error rate, build time: something changed because of your work. Find it.
Rewrite 7: The Personal Project That Sounds Like a Tutorial
Before: "Created a to-do list application using React."
After: "Built a task management app with React and Firebase featuring real-time sync, drag-and-drop reordering (react-beautiful-dnd), and Google OAuth, with 95+ Lighthouse accessibility score."
What changed: "To-do list" became "task management app" (same thing, better framing). Listed specific features that go beyond the tutorial version. The Lighthouse score shows you cared about quality, not just functionality.
If your project really is just a basic tutorial follow-along, either extend it with extra features before putting it on your resume or swap it for a project with more substance.
Rewrite 8: The "Used Agile" Bullet
Before: "Worked in an Agile environment using Scrum methodology with bi-weekly sprints."
After: "Shipped 2 features per sprint across 6 sprints as part of a 5-person Scrum team, including a search autocomplete component that reduced average search time from 8 seconds to 2 seconds."
What changed: "Worked in Agile" is a process description, not an achievement. Nobody cares that you had standups. They care what you shipped during those sprints. Name the features, name the results.
Honestly, you can usually drop Agile/Scrum mentions entirely unless the job description specifically asks for it. The space is better used on technical achievements.
Rewrite 9: The Open Source Contributor
Before: "Contributed to open source projects on GitHub."
After: "Authored 4 merged PRs to FastAPI (78K+ stars), including a fix for query parameter validation that resolved 12 open issues, reviewed and approved by a core maintainer."
What changed: Named the specific project and its scale. Described what the contributions actually were. Mentioned that PRs were merged and reviewed, which signals code quality. If you've done open source work, your GitHub profile should back this up with visible contributions.
Rewrite 10: The Leadership Role That's All Fluff
Before: "Served as president of the Computer Science Club and organized events."
After: "Led 30-member CS club, organizing 8 tech talks (avg. 45 attendees) and a mock interview workshop with engineers from Google and Amazon, increasing semester membership by 60%."
What changed: Quantified everything. Number of members, number of events, attendance, growth. Leadership bullets on a software engineering resume need to be just as specific as technical bullets. If you organized something, what was the scale? If you grew something, by how much?
The Pattern Behind Every Good Bullet
Look back at all 10 rewrites. Every good bullet does three things:
-
Starts with a strong action verb. Designed, implemented, resolved, shipped, built, developed, authored, led. Not "worked on," "helped with," "was responsible for," or "assisted in."
-
Includes at least one number. Users served, endpoints built, tickets resolved, percentage improved, team size, event attendance. Numbers make bullets concrete and memorable.
-
Names specific technologies or methods. Not "used a database" but "PostgreSQL." Not "machine learning" but "scikit-learn SVM with 87% F1 score." Specifics prove you actually did the work and they also feed keywords to ATS systems that are scanning your technical skills section.
How to Find Numbers When You Think You Don't Have Any
The most common pushback is "but I don't have metrics." You probably do. Ask yourself:
- How many users/requests/records did the thing handle?
- How much faster/slower/bigger/smaller did something get?
- How many teammates were on the project?
- How many [thing] did you build/fix/review/ship?
- What was the before and after?
If you genuinely can't find a number, that's okay. "Implemented a caching layer using Redis to reduce redundant database queries on the product search endpoint" is still a good bullet without a percentage. But try to find the number first.
And look, doing this for every bullet across every job application is a lot of work. That's partly why we built the first version of Finch, a resume generator. It wrote several versions of each bullet, each from a different angle (technical depth, business impact, and so on), and picked the angle that best matched the target role.
You can do the same by hand. If you're applying to a data engineering position, your internship bullet might emphasize the pipeline you built. If you're applying to a product-focused role, the same internship bullet might emphasize the user impact. Same experience, different framing. Write both versions once and keep them ready.
Write Bullets That Make Interviewers Ask Follow-Up Questions
The ultimate test of a resume bullet is whether it makes someone want to ask you about it. "Worked on backend features" generates zero curiosity. "Reduced API latency by 40% by implementing query result caching" makes an interviewer think "how did they decide what to cache? Did they measure the improvement? What were the tradeoffs?"
That's what you want. Every bullet should be a conversation starter, not a job description.
Go through your resume right now. Pick your three weakest bullets and rewrite them using the XYZ formula. Lead with impact. Add a number. Name the technology. It takes 15 minutes and it's the highest-ROI thing you can do for your job search.
If you're applying to software engineering internships, Finch picks the 3 that fit your major best each week, so you know which applications get your sharpest bullets. It's free, and you start with your major.