Concept
A resume's job is narrow and specific: get you to the next step (a recruiter screen or a hiring-manager conversation), not to fully document your career. Most resumes fail this narrow job not because the candidate lacks real accomplishments, but because those accomplishments are described in a way that requires the reader to do work to understand their significance, and a resume getting a 30-90 second first pass from a busy hiring manager or recruiter doesn't get that benefit of the doubt. The fix is almost entirely mechanical: a specific bullet-writing formula, ruthless prioritization of what actually belongs on the page, and a portfolio that answers a hiring manager's real, practical question in the first few seconds of looking at it.
The bullet formula: Action + Context + Result
The single highest-leverage resume skill is rewriting bullets from a "responsibilities" framing (what you were assigned to do) into an "accomplishments" framing (what actually happened because of you) using a consistent formula: a strong action verb, the context that establishes scope or difficulty, and a concrete result, ideally quantified.
WEAK: "Responsible for the checkout flow."
BETTER: "Rebuilt the checkout flow's form validation, reducing
cart-abandonment-due-to-errors by 18% over the following quarter."
WEAK: "Worked on improving site performance."
BETTER: "Diagnosed and fixed a render-blocking third-party script,
cutting median page load time from 4.1s to 1.6s."
WEAK: "Helped the team migrate to TypeScript."
BETTER: "Led a phased TypeScript migration across a 40k-line codebase
with zero production incidents, converting ~3k lines/week
while the team continued shipping features in parallel."Notice the pattern in each "better" version: a specific verb that names what was actually done (rebuilt, diagnosed and fixed, led), enough context to convey real scope or difficulty (40k-line codebase, third-party script specifically, not "some code"), and a result that's either quantified (18%, 4.1s to 1.6s, 3k lines/week) or at minimum concrete and checkable (zero production incidents) rather than a vague adjective ("significantly," "greatly"). Not every bullet will have a clean number, for bullets without an obvious metric, concrete specificity about scope and outcome still beats a number-free vague claim.
Quantification when you don't have a clean number
A common objection is "I don't have metrics for this work", often true, especially for work whose impact wasn't directly instrumented at the time. Several fallback approaches still beat a vague, unquantified bullet: scale (number of users affected, size of codebase, size of team), frequency (how often the thing you built/fixed runs or is used), before/after even without precise numbers (a qualitative but specific before/after: "previously required manual deployment; now deploys automatically on merge"), and relative comparison ("the fastest of the three approaches we prototyped"). The goal isn't manufacturing a fake-precise number, it's giving the reader SOME concrete anchor instead of an adjective they have to just take on faith.
What a frontend portfolio actually needs to show
A hiring manager looking at a frontend portfolio is usually trying to answer one practical question fast: "can this person build things that work well, and can I tell that from what's here." The most common portfolio mistake is optimizing for volume (many small demo projects) over depth (one or two projects that show real decision-making), a hiring manager skimming a portfolio in a few minutes gets far more signal from one project with a clear write-up of the actual technical decisions made (why this state-management approach, what trade-off was considered and rejected, what broke and how it was fixed) than from ten polished-but-shallow demo apps that all look similarly competent without revealing how the candidate actually thinks.
A strong portfolio project entry answers, ideally without the reader having to dig: what problem the project solves (not just what it is), what YOUR specific role/contribution was if it wasn't solo work, at least one genuinely interesting technical decision and why you made it, and a live, working link, a portfolio project that's broken or unreachable when a hiring manager actually clicks it is worse than not including that project at all, since it actively raises doubt about the candidate's attention to detail on shipped work.
Prioritization and length
Resumes for candidates with more than a few years of experience should almost always be one page, not because more experience isn't valuable, but because the OLDEST and least-relevant experience is exactly the material a reader has the least patience for, and a resume that includes everything ever done signals an inability to prioritize, which is itself a negative signal for a role that requires judgment about what matters. The fix is ruthless: for each role beyond the most recent 2-3, ask "does this bullet materially change how a hiring manager evaluates me for THIS specific role I'm applying to", if not, cut it or compress it to a single line.
Try It
Here's a real (weak) resume bullet. Rewrite it using the Action + Context + Result formula before revealing a strengthened version.
"Worked on the company's React codebase, fixing bugs and adding features as needed."
Solution
This bullet fails on all three parts of the formula: the "action" (worked on) is generic rather than specific, there's no context establishing scope or difficulty (how big was the codebase, what kind of bugs, what features), and there's no result at all, it describes an ongoing responsibility, not an accomplishment.
A strengthened version needs real specifics from the candidate's actual work to fill in, a plausible example: "Fixed a memory leak in a data-visualization dashboard used by ~200 internal analysts daily, caused by an uncleaned event listener in a chart component, cutting the dashboard's reported crash rate by roughly 90% over the following month." This version has a specific action (fixed a specific, named bug), context that conveys real scope (200 daily users, a specific component type), and a concrete, checkable result (90% crash-rate reduction, with a specific timeframe). The lesson generalizes beyond this specific example: whenever a bullet describes an ongoing responsibility rather than a specific accomplishment, the fix is finding ONE specific instance of that responsibility that had a real, describable outcome, and writing about that instance instead of the responsibility in the abstract.
Implement It Yourself
Using the Action + Context + Result formula, rewrite three of your own current resume bullets. For each one, fill out this worksheet.
ORIGINAL BULLET: _______________________________________
Action (specific verb, what did you actually DO, not what were
you "responsible for"): _____________________________
Context (scope/difficulty that makes the action meaningful, team
size, codebase size, user count, constraint you were under):
_______________________________________________________
Result (a number if you have one; if not, use scale/frequency/
before-after/relative-comparison as a fallback):
_______________________________________________________
REWRITTEN BULLET (combine the above into one sentence):
_______________________________________________________
Self-check:
[ ] Could a stranger who's never met you understand roughly what
you did and why it mattered, from this bullet alone?
[ ] Is there at least one concrete, specific detail (a number, a
named technology, a scale) rather than only adjectives?
[ ] Does the bullet describe something YOU did, not something your
TEAM did in general (unless explicitly framed as team leadership)?There's no single correct answer since this draws on your actual work history, but if any self-check box is unchecked, that's the specific gap to close before the bullet goes on an actual resume.
Common Mistakes
1. Responsibilities instead of accomplishments
❌ "Responsible for frontend development of the checkout page."This describes a job description, not an accomplishment, it tells the reader what the candidate was ASSIGNED, not what they actually achieved. Every bullet should describe something that happened because of the candidate, not a standing duty.
2. Vague quantifiers instead of real numbers
❌ "Significantly improved page load performance.""Significantly" asks the reader to trust an unverifiable adjective. Even an approximate real number ("~60% faster," "from 4s to 1.5s") is far more persuasive than any adjective, because it's checkable and specific.
3. A portfolio with many shallow projects instead of few deep ones
Ten small, similarly-polished demo apps with no write-up of actual decisions give a hiring manager far less signal than one or two projects with a clear account of a real technical trade-off considered and made, volume without depth reads as "went through tutorials," not "can make real engineering decisions."
4. Broken or unreachable portfolio links
A project entry linking to a live demo that 404s, or a GitHub repo with no README explaining what the project even is, actively costs more than not including the project, it signals carelessness about exactly the kind of detail (does the shipped thing actually work) the reader is trying to evaluate.
5. A resume that tries to include everything
Padding a resume with every role and every task ever performed, rather than prioritizing what's relevant to the specific role being applied for, signals an inability to prioritize, itself a negative signal, separate from whatever the padded content actually says.
Best Practices
- Rewrite every bullet through the Action + Context + Result formula, specific verb, real scope/difficulty, concrete (ideally quantified) outcome.
- Use scale, frequency, before/after, or relative comparison as fallbacks whenever a clean percentage or metric genuinely isn't available, anything concrete beats an adjective.
- Prioritize portfolio depth over volume, one or two projects with a real account of technical decision-making outweigh many shallow, similarly-polished demos.
- Verify every portfolio link actually works before sending the resume out, and re-check periodically, a broken link discovered by a hiring manager is worse than the project not being listed at all.
- Tailor which bullets appear and how prominently based on the specific role being applied for, cut or compress material that doesn't change how a reader evaluates you for THIS role.
Performance Tips
- Keep the resume to one page for most candidates (roughly up to 8-10 years of directly relevant experience), the oldest, least-relevant material is exactly what a time-constrained reader has the least patience for, so trimming it is a net gain, not a loss.
- Lead each bullet with the strongest, most specific part (often the result or the distinctive action), since a reader skimming quickly may not get to the end of a long bullet, front-loading the most persuasive content protects against partial reading.
- For a portfolio, put the strongest project first and make sure it's reachable within one click from the landing page, don't assume a time-constrained reviewer will dig through a full project list to find the best example.
