Most weak resume bullets describe activity. Strong bullets show what changed because of your work.

"Worked on the reporting service" is too vague. It tells the reader where you spent time, but not what you improved, built, fixed, or owned.

A stronger version is:

"Reduced report generation time from 12 minutes to 4 minutes by adding query-level caching and removing duplicate database calls."

That bullet gives a hiring manager something useful. It shows the result, explains the technical work, and gives enough detail to make the claim believable.

A good engineering bullet usually answers three questions:

When a bullet answers all three, it stops describing a duty and starts showing an accomplishment.

A bullet that answers only the first question reads like a job description. The method and the result are what turn it into evidence a hiring manager can judge.

You may see this called the X-Y-Z format: accomplished X by doing Y, which led to Z. Do not treat it like a sentence template. Treat it like a quick check. If a bullet explains the work, the method, and the result, it is usually much stronger than a duty statement.

This matters because a hiring manager is not just checking what you were assigned to do. They are trying to understand your judgment, ownership, and results. "Responsible for backend APIs" describes the job. "Built three billing APIs used by 40K monthly customers" shows scope. "Reduced checkout errors by 18% by adding request validation and clearer retry handling" shows impact.

Numbers help because they make a claim more concrete. They can show impact, scale, frequency, speed, cost, reliability, volume, or team size. Not every bullet needs a perfect business metric, and not every job gives you clean dashboards. But most work has some way to describe size or effect.

When you do not have an official metric, use honest scale instead. How many users? How many files? How many services? How often did the job run? How long did the manual process take before and after? A conservative estimate is fine if it is based on real information and you can explain it in an interview.

Start with a specific verb

Use verbs that show real work: built, designed, migrated, automated, reduced, improved, shipped, debugged, refactored, led, tested, or documented.

Avoid starting too many bullets with "worked on," "helped with," "responsible for," or "assisted in." Those phrases are not always wrong, but they usually hide your actual contribution. If you helped, say exactly how you helped.

If you are stuck, write the plain version first: "I fixed slow reports." Then make it more specific: what was slow, what did you change, and what improved?

Lead with the result when possible

If the result is strong, put it near the front: lower latency, fewer failures, faster releases, less manual work, better test coverage, more reliable deployments, or a clearer user experience.

This helps the reader understand why the work mattered before they get into the technical details.

Explain how you did it

The method is where your engineering judgment shows. "Improved performance" is vague. "Improved performance by adding Redis caching and removing two N+1 queries" is much more useful.

The technical detail also gives your bullet useful keywords without turning it into a list of tools.

Quantify what you can

Use numbers when they are real and defensible. You can quantify:

Do not invent numbers. Do not exaggerate. A modest number you can explain is stronger than an impressive number you cannot defend.

Keep the focus on your contribution

Resume bullets usually skip "I," so write "Built the migration tool," not "I built the migration tool."

But the bullet should still make your role clear. If the work was shared, say what part you owned: "Implemented the backfill job," "owned API integration," "wrote the test suite," or "led the rollout plan." Hiring managers know software is teamwork. They still need to understand what you personally contributed.

Keep bullets readable

Most bullets should be one or two lines. Three lines can be fine for a major accomplishment, but long bullets are harder to scan.

If a bullet keeps growing, it may contain two separate ideas. Split it, or keep the stronger point and cut the weaker one.

Do not turn bullets into tech lists

Mention the stack when it helps, but keep the accomplishment first.

"Built user authentication with JWT, OAuth, Node.js, Express, MongoDB, Redis, Docker, and AWS" reads like a tools list. "Built JWT-based authentication with password reset and session management for a Node.js app" gives the reader a clearer picture of what you actually built.

Here is the basic shape of an X-Y-Z bullet.

In real resumes, the order can vary. Sometimes the result comes first. Sometimes the method comes first because the technical work is the impressive part. Use the format as a checklist, not a rigid sentence pattern.

The difference between a weak bullet and a strong one is usually specificity. Here are three common cases.

Bad:

Better:

Why the better version works: It names the problem, gives a result, and explains the technical work. The stack is included naturally, but it does not take over the bullet.

Bad:

Better:

Why the better version works: The rewrite shows scope, method, and care. It is specific enough to discuss in an interview, and it does not pretend the person owned every part of a large migration if they did not.

Bad (a new grad with no industry metrics):

Better:

Why the better version works: Priya may not have business metrics, but she can still show scope and functionality. The stronger bullet tells the reader what the app actually did and what technical pieces she handled.

When a bullet falls flat, the cause is usually that the reader cannot tell what you specifically did or what changed because of it, and the items below are the ways that information goes missing.