Perfly

Resume bullet points that show what you actually did

Most engineering résumés list responsibilities, and the ones that get callbacks list results. Here's a formula, before-and-after examples, how to find numbers when you think you don't have any, and how to tailor your bullets to a specific job.

Start your 30-day free trialUpdated

Describe what changed because of your work

Here’s what most résumé bullets look like, next to what they could say:

Typical Stronger
Responsible for the payments service. Cut failed payment retries by 60% by redesigning the payments service’s retry and idempotency logic.
Worked on frontend performance. Brought checkout’s mobile LCP from 3.8s to 1.9s by splitting the bundle and lazy-loading payment widgets.
Helped onboard new engineers. Cut time to first merged PR for new hires from about two weeks to four days by writing a scripted local setup.
Participated in on-call rotation. Reduced median incident resolution time from 50 to 20 minutes by writing runbooks for our five most common alerts.

The left column tells a recruiter what your job was. The right column tells them what you’d probably do for them, which is what they’re trying to figure out during a very quick first skim.

The XYZ formula

Google’s long-time recruiting advice is to write each accomplishment as: accomplished X, as measured by Y, by doing Z.

  • X is the result.
  • Y is the number that proves it.
  • Z is what you did to get there.

You don’t have to keep that exact order. “Cut CI failures from 18% to 3% by quarantining and fixing flaky tests” puts X and Y together up front, and that’s fine. What matters is that all three parts are there. A bullet with only Z (“Fixed flaky tests”) leaves the reader guessing whether it mattered.

Resume bullet point examples for software engineers

Use these for the shape, then fill in your own systems and numbers.

Backend

  • Migrated billing from the monolith to its own service with zero downtime, unblocking the launch of annual plans three weeks later.
  • Cut p95 latency on the search API from 820ms to 310ms by adding covering indexes and caching the ranking step.

Frontend

  • Raised the checkout conversion rate on mobile by about 4% by getting the page under Core Web Vitals thresholds.

Infrastructure and SRE

  • Cut average deploy time from 25 to 8 minutes by moving 30 services onto a new build pipeline.
  • Reduced cloud spend by about 12% ($9k a month) by finding and removing idle staging clusters.
  • Defined SLOs and error-budget alerts for three tier-1 services, catching slow degradations before customers reported them.

Mobile

  • Improved Android crash-free sessions from 98.9% to 99.7% by fixing an image cache leak and adding crash grouping to the release checklist.

Data

  • Cut the nightly revenue pipeline from three hours to 25 minutes by rebuilding it on incremental models, so finance gets numbers by 9am.

Leadership and mentoring

  • Led a team of four through the notifications rewrite, from RFC to launch, cutting delivery failures from 4% to under 0.5%.
  • Mentored two new engineers who were each shipping to production within their first two weeks.

How to find numbers when you think you don’t have any

Most engineers have more numbers than they think. They just didn’t write them down at the time. Places to look:

  • Dashboards: latency, error rates, uptime, throughput, cost
  • Pull request and design doc descriptions, which often state the before and after
  • Incident write-ups: time to detect, time to resolve, how many customers were affected
  • Release notes, changelogs, and launch announcements
  • Your old weekly updates or status reports, if your team kept them

If you can only estimate, say so with “about” or “~”. A careful estimate is fine on a résumé, an invented number isn’t, and an interviewer will ask how you measured it.

When there’s honestly no metric, describe scale or reach instead: how many users, teams, or services the work touched, or what was possible afterward that wasn’t before.

How many bullets, and how long

  • Three to five bullets for each recent role, fewer for older ones.
  • One line each, two at most. If a bullet needs three lines, it’s usually two bullets.
  • Start with a strong verb: led, built, cut, migrated, designed, shipped, reduced. “Responsible for”, “helped with”, and “worked on” make you sound like a bystander to your own work.
  • Put your strongest bullet first in each role. Plenty of readers never get to the third.

Tailoring your bullets to a job description

Sending the same résumé everywhere is easy, but a tailored one gets read differently. For each application:

  1. Pick out the five or so requirements the job description repeats or puts first.
  2. For each requirement, find the bullet that proves you’ve done it. If you don’t have one, check whether you have the experience and just never wrote it down.
  3. Move the matching bullets to the top of each role and trim the ones that don’t support this job.
  4. Use their wording where it’s honestly accurate. If they say “distributed systems” and you wrote “microservices”, either can be true, and theirs is what their screening tools and recruiters scan for.

Don’t add skills or results you don’t have. Tailoring is choosing and ordering what’s true, and inventing things tends to fall apart in the first technical interview.

Where the raw material comes from

Every bullet above depends on remembering what you did and what changed. Two years after a project, that’s mostly gone, which is why résumé writing turns into a weekend of archaeology.

Keeping a work journal solves most of it. Perfly does the same thing with less effort, and turns the record into a résumé:

  1. You log a few lines a day, or let GitHub, Jira, Google Calendar, or Notion draft entries from your activity. If you use Claude Code, Codex, or Cursor, your agent can send the summary. When an entry would be stronger with a number, Perfly asks for it while you still remember.
  2. Perfly keeps a master résumé written with the XYZ formula from everything you’ve confirmed. Each bullet links to the entries behind it.
  3. It flags weak bullets: a number you recorded but didn’t use, no number at all, a weak opening verb, a bullet that’s too long, or one with nothing behind it.
  4. Paste a job description to get a tailored version drawn from your whole record. You can keep up to ten, and each one lists the job’s main requirements next to the bullets that cover them, so gaps are easy to spot.
  5. Copy it, export it as Markdown, or print it. You can also practice a “walk me through your résumé” interview with an AI interviewer that has read it, and for a tailored version, the job description too.

Haven’t been keeping a record? Connect GitHub and Google Calendar and Perfly can pull in the last 12 months of activity, group it into themes, and let you pick the highlights to start from.

FAQ

Does every bullet need a number?

Most should have one, but not all. A bullet about scope (“Owned the payments service end to end, including on-call”) can stand without a metric. If none of your bullets has a number, though, that’s the first thing to fix.

Is it okay to use AI to write resume bullet points?

For wording, yes. The catch is that AI doesn’t know your results, so it’ll happily produce confident numbers that aren’t yours. Give it real outcomes and real numbers, and check every figure before it goes on the page.

How far back should my résumé go?

Roughly the last ten years in detail. Older roles can shrink to a line or two, or a short list of titles and companies.

Should a software engineer’s résumé be one page?

One page works for most people early in their career. With many years of relevant experience, two pages is fine. Cut older and less relevant bullets before you shrink the font.

How much does Perfly cost?

30 days free with everything unlocked. After that it’s $6.99 a month, or $69.99 a year.

Try it on your own week.

30 days free with everything unlocked, then $6.99/month.

Start free trial