Resume Bullets for Software Engineers: What Actually Lands Interviews

Most engineer resumes fail at the bullet level. Not because the person didn’t do interesting work, but because the bullet doesn’t communicate what they did or why it mattered. A good bullet is three things: specific, measurable, and scoped to your contribution.

Here’s the structure, then 20 before/afters so you can see it in practice.

The structure

[Action verb] + [what you did] + [how you did it] + [measurable outcome].

That’s it. Most weak bullets are missing one of the four.

• “Worked on the checkout flow” — missing everything.
• “Rewrote the checkout flow in React, reducing cart-abandonment by 18%” — four for four.

The verbs that carry weight

Strong: shipped, built, led, reduced, increased, migrated, designed, architected, authored, automated, rewrote, debugged, diagnosed, owned, scaled.

Weak: helped, contributed, assisted, worked on, was responsible for, participated in, involved in.

The weak verbs imply proximity without ownership. If you led it, say so. If you only helped, the context matters — were you the second dev on a four-person team, or the intern who reviewed the PR? Be precise.

The numbers that matter

You don’t need ML-grade metrics. Any of these work:

• Performance: p95 latency, bundle size, query time, build time, cold-start time.
• Scale: QPS, DAU/MAU, rows processed, events/sec.
• Cost: dollars/month saved, infra footprint reduced.
• Reliability: uptime, error rate, MTTR.
• Business: conversion, retention, signup rate.

If you don’t know the exact number, approximate and say so. “Cut p95 latency from ~800ms to ~200ms” is fine. “Improved performance significantly” is not.

20 before/afters

Frontend

1. Before: Worked on performance improvements for the dashboard. After: Reduced dashboard time-to-interactive from 3.2s to 900ms by code-splitting five route bundles and deferring a blocking analytics SDK.

2. Before: Migrated app from Redux to Zustand. After: Migrated a 40k-line React app from Redux to Zustand, shrinking the state-management layer by 60% and removing 8 packages from the bundle.

3. Before: Built an internal component library. After: Authored an internal React component library (22 components, Storybook-documented, Chromatic-tested) adopted by four product teams in six months.

4. Before: Improved accessibility. After: Raised WCAG AA coverage from 62% to 94% across the marketing site by fixing contrast, keyboard traps, and missing ARIA labels — verified with axe-core in CI.

5. Before: Worked on the design system. After: Co-led the design-system migration to Tailwind v3 across 14 apps, deprecating 3 legacy CSS-in-JS libraries and cutting first-paint CSS by 40%.

Backend

6. Before: Built a GraphQL API. After: Designed and shipped a GraphQL API serving 120 RPS, with DataLoader-based batching that dropped per-request DB round-trips from 14 to 3.

7. Before: Worked on auth. After: Replaced a session-cookie auth system with JWT + refresh-token rotation, eliminating a class of CSRF vulnerabilities and cutting auth-service RAM usage by 35%.

8. Before: Optimized database queries. After: Diagnosed a Postgres N+1 on the feed endpoint using pg_stat_statements; added a materialized view that cut p95 from 2.4s to 180ms.

9. Before: Helped with a rewrite to Go. After: Ported three high-QPS Python services to Go, cutting per-instance memory from 600MB to 80MB and enabling a 4× pod-density increase on the existing cluster.

10. Before: Added tests. After: Raised backend test coverage from 41% to 82% on the payments service; caught 6 regressions in the first quarter that would otherwise have reached production.

Data / ML

11. Before: Built ETL pipelines. After: Built a 60-table Airflow-to-BigQuery pipeline processing 2B events/day, with a schema-drift detector that has caught 11 upstream schema changes before they broke dashboards.

12. Before: Worked on a recommendation model. After: Shipped a candidate-generation model (Two-Tower, 128-dim embeddings) that increased 7-day click-through by 6.4% in an A/B test against the production LR baseline.

13. Before: Improved data quality. After: Authored 40 Great Expectations checks across 12 source tables; dashboard consumer complaints dropped from ~8/month to <1/month.

Infra / Platform

14. Before: Worked on CI/CD. After: Rebuilt the CI pipeline on GitHub Actions with Nx-aware caching, cutting average PR build time from 22 minutes to 6 minutes across a 14-app monorepo.

15. Before: Migrated to Kubernetes. After: Led the migration of 18 services from Heroku to EKS with zero customer-facing downtime, reducing monthly infra spend by ~$14k.

16. Before: Set up monitoring. After: Deployed a Prometheus + Grafana + Alertmanager stack covering 34 services; authored 60+ alerts that dropped MTTR from 45m to 12m over two quarters.

17. Before: Improved Dockerfile. After: Refactored 9 service Dockerfiles to multi-stage builds, cutting average image size from 1.1GB to 180MB and halving cold-deploy time.

Leadership / cross-cutting

18. Before: Mentored junior engineers. After: Mentored 3 junior engineers across an 18-month span; two were promoted to mid-level within the window, with weekly 1:1s and structured code-review feedback.

19. Before: Led architecture decisions. After: Authored 6 RFCs driving architecture decisions on message-queue choice, service-boundary splits, and the billing-data model; all accepted and implemented.

20. Before: Worked on on-call rotation. After: Owned the on-call rotation for the payments service (8-person rotation); wrote 14 runbooks that reduced average pager response time from 18m to 4m.

Three patterns the strong bullets share

1. The technology is specific. Not “microservices” — “Go services behind an Envoy mesh with gRPC inter-service calls.” Specific tech signals actual experience.
2. The number is believable. “Improved performance by 10,000%” is noise; “cut p95 from 800ms to 200ms” is signal. Pick numbers a skeptical reader can sanity-check.
3. The scope is honest. “Led” a 3-person team is fine. “Led” when you were one of eight engineers will fall apart in the interview.

The common failure mode

The bullet describes the project rather than your contribution. Both of these are about the same work:

• “The team launched a new payments system handling $200M/year.” — project, not you.
• “Led the payments-service rewrite in Go, scaling the platform to $200M/year at 99.98% uptime.” — you.

If a hiring manager reads your bullet and can’t tell which parts you personally did, the bullet isn’t doing its job.

Revising in a pass

For each bullet on your current resume, ask:

1. What’s the verb? (Swap weak for strong.)
2. What’s the technology? (Be specific.)
3. What’s the number? (Add one if missing.)
4. What’s the scope? (Clarify your contribution.)

Most bullets need two of the four fixed. The fourth one is the hardest — you’re often the only person who knows what you actually did.

Starting from a blank line

Rewriting a bullet from scratch is easier if you first just dump everything you remember doing — the tech, the context, the outcome, even the struggles — and then compress. Our Resume Bullet Rewriter does exactly that pass: you paste a loose description and it returns three polished variants you can edit. It’s not a replacement for your own judgment, but it’s a faster starting point than a blinking cursor.

Free, no sign-up, 5 runs per day.