You Don't Need Big Numbers — Small Metrics That Make Resumes Land

In Part 3, we covered the four pieces of a Career Story — Domain, Identity, Quantified Impact, and Differentiator. Of those four, there's one that locks up more than the others: Quantified Impact.

When entry-level job seekers sit down to add numbers to their resumes, two walls usually hit at the same time. One is the pressure of not having impressive numbers like "drove 30% YoY revenue growth." The other is that even when you have a number, writing the result alone hides the person who actually did the work.

This post unpacks both of those at once. Here's the conclusion upfront: you don't need big numbers as an entry-level candidate. What you need is small numbers from your actual work, pulled out precisely, with the process that produced them.

What Recruiters Actually Want From a Quantified Result

Recruiters look for numbers for one reason: they want evidence that the identity on the resume is real. So the number itself matters less than what the number points to.

— "Drove 30% revenue growth" → signals revenue-impact roles

— "Lifted usability by 23%" → signals UX research and iteration

— "Cut API response time from 800ms to 320ms" → signals backend performance work

Same number type, different identities. Which is why a small number that fits your target role is enough. 12 user interviews. 5 prototype iterations. 8 pull requests merged. 4 meetings facilitated. These are entry-level numbers — and entry-level recruiters know what entry-level numbers look like. What they're checking is whether you measured your own work precisely.

A 4-Step Guide to Pulling Out Your Numbers

Here's a four-step walkthrough for finding numbers in your own work. Run through these in order when your head is blank.

Step 1 — List your activities in chronological order

Write out every project, internship, side project, club role, and capstone you've done, in order. Don't just list the impressive ones. Include the short, the average, the ones you almost forgot. Numbers often hide in unexpected places.

Step 2 — For each activity, recall what was measurable

For each activity, ask what could have been counted or measured. Some categories to scan:

— People: interviews conducted, meetings facilitated, team size, audience reached

— Outputs: design iterations, pull requests merged, pages of documentation, prototype versions

— Service metrics: usability scores, response times, revenue, users, page views, conversion

— Time saved: hours of manual work eliminated, weeks shaved off a process

You don't need a big number. A small one that accurately reflects what you did is strong.

Step 3 — Specify the unit and the comparison baseline

A number alone is weak. A number with a baseline is strong.

Weak: "Lifted usability score by 23 points."

Strong: "Lifted usability score by 23% compared to the beta version."

"Compared to last year," "compared to baseline," "compared to before launch" — these baselines turn a number into evidence. A bare absolute number doesn't carry much.

Step 4 — Make your contribution unmistakable

Distinguish between team outcomes and your individual contribution. Even as an entry-level candidate, you can be precise about which parts were yours.

Weak: "Cut payment API response time by 60%." (Reads like a solo effort by default)

Strong: "As the sole owner of the payment API latency reduction initiative, cut response time by 60%." (Your scope is clear)

Phrases like "owned," "as the lead," "in my portion of the work" draw a line around what was actually yours.

Why the Result Alone Isn't Enough — The Value of Process

Pulling out the number is half the job. What recruiters really want to see is how you got there.

Same number, very different impressions depending on whether the process is visible.

Weak: "Lifted usability scores by 23%."

Strong: "Ran 12 user interviews to surface three core pain points, then iterated on the Figma prototype five times to lift usability scores by 23%."

Same 23%. But with process, what comes through is "this is how this person works." Which tools you used, which steps you took, which people you worked with — that's where your texture as a worker shows up. This connects directly back to the Differentiator from Part 3.

This is also where the STAR method comes from (Situation, Task, Action, Result). The four steps above map cleanly onto STAR — and they exist because hiring managers across industries consistently say the same thing: results without process don't land.

Before / After

This series follows two fictional job seekers — Pearl Kim, a design student building hackathon products, and Jasper Brooks, a CS student with open source contributions and a Series A fintech internship. Same experience — but watch what happens at three levels of detail.

Pearl Kim (Design) — Weekend Hackathon Project

Before

"Worked on a hackathon project and improved the user experience."

After — result only

"Lifted prototype usability scores by 23% during a hackathon."

After — result plus process

"Ran 12 user interviews with remote workers to surface three core friction points. Iterated on the Figma prototype five times to lift usability scores by 23% compared to the initial version, and the team's project made the hackathon's top 5 demos."

Comparing all three: the Before shows nothing about Pearl. The "result only" version shows a number but not the work. The "result plus process" version is where Pearl's identity as a research-driven designer who iterates fast actually comes through.

Jasper Brooks (CS) — Series A Fintech Internship

Before

"Worked on payment API performance as a backend intern."

After — result only

"Cut payment API response time by 60% as a backend intern."

After — result plus process

"As the sole owner of the payment API latency reduction initiative, profiled query bottlenecks, redesigned the indexing strategy, and rolled out a Redis caching layer. Cut p95 response time from 800ms to 320ms (a 60% reduction) and lifted checkout completion by 12%."

In the "result plus process" version, Jasper's identity as a backend engineer who owns performance problems end-to-end — from diagnosis to deployment — fits into a single paragraph.

A Prompt Template for Pulling Result and Process Together

Once you've run through the four steps yourself, hand the structured input to AI and you'll get back a paragraph that holds both result and process. Copy this into ChatGPT or Claude and fill in your own information.

I'm a [major/role] job seeker, and I did [work description] on [project]. Write a single resume paragraph based on the following.

Result (numbers): [measured outcomes with baselines]

Process: [methods and tools used, step by step]

My contribution: [team vs. solo work, with my scope made clear]

Role connection: [what this number signals about the role I'm targeting]

Conditions:

- Two to three sentences

- Include process, not just result

- Specify units and baselines

- No vague verbs like "participated," "contributed," "carried out"

Pearl's prompt

I'm a design student and a job seeker, and I led design on a 48-hour hackathon project building a focus-tracking app for remote workers. Write a single resume paragraph based on the following.

Result (numbers): Usability scores up 23% from initial to final prototype, project made the hackathon's top 5 demos

Process: 12 user interviews with remote workers to surface three friction points, 5 iterations on the Figma prototype, daily design crit with the team

My contribution: Design lead on a 4-person team, sole owner of UX research and prototyping

Role connection: Product designer skilled at finding friction points through user research and validating fast with prototypes

Jasper's prompt

I'm a CS student and a job seeker, and I worked as a backend engineering intern at a Series A consumer fintech for 4 months. Write a single resume paragraph based on the following.

Result (numbers): p95 response time cut from 800ms to 320ms (60% reduction), checkout completion rate up 12%

Process: Query bottleneck profiling, index redesign, Redis caching layer, 3 rounds of senior engineer code review

My contribution: Sole owner of the payment API latency reduction initiative

Role connection: Backend engineer who owns performance problems from diagnosis to deployment

But Where Do You Pull These Numbers From?

Even after running through the four steps, you'll hit a wall somewhere. "How many people did I interview during that hackathon, exactly?" "What was the baseline usability score before our iterations started?" "By exactly how many milliseconds did p95 drop?" Are those numbers still sharp in your head?

Most of the time, they aren't. The numbers live scattered across Slack threads, Notion pages, Discord servers, Linear tickets, GitHub pull requests, Figma comments. Which means writing strong quantified results really comes down to a different question — how do you store your own contribution numbers in the first place, while the work is still fresh?

That's what Part 6 of this series is about.

Today's Takeaways

· Entry-level candidates don't need big numbers. Pulling small numbers from your actual work, precisely, is what counts.

· The four-step guide: list activities → recall measurables → specify baselines → make contribution clear.

· Result alone isn't enough. Result plus process is where your texture as a worker comes through.

· The hardest part is that the raw numbers and process detail live scattered across your tools. Part 6 handles that.

The Full Series

This series publishes one post a day, six days in a row.

· Part 1 (May 9, Sat) — 5 Traps Job Seekers Fall Into When Writing AI Resumes in 2026

· Part 2 (May 10, Sun) — The AI Resume Difference Recruiters Actually Recognize

· Part 3 (May 11, Mon) — The First Line That Decides Your Resume

· Part 4 (May 12, Tue) — You Don't Need Big Numbers ← this post

· Part 5 (May 13, Wed) — The One Line AI Can't Write: References Inside Your Resume

· Part 6 (May 14, Thu) — From Scattered Slack, Notion, and PDF Records to a Single Resume

Each part gets linked back to this page after it goes live.

One More Thing

Up next: The One Line AI Can't Write: References Inside Your Resume (Part 5, May 13 Wednesday)

What if your numbers and process details were building themselves up automatically as you worked? That's what Part 6 is about. If you want a preview now — find your team, build real projects together, and build a resume recruiters actually read. → [Try Perplz Resume]