Guide · Self-reviews

Self-review examples for frontend engineers.

Frontend work is visible, which cuts both ways. Everyone sees the new screen, so it's tempting to list screens and stop. Reviewers want the layer under the screens: was it fast, could everyone use it, and did you leave the codebase easier for the next feature?

What reviewers look for in a frontend engineer

What users felt. Load time, responsiveness, fewer broken states. Real-user numbers beat lab numbers, and lab numbers beat adjectives.
Accessibility. Keyboard paths, screen reader labels, contrast. It's easy to skip, so doing it well shows judgement.
Shared foundations. Components, design tokens and patterns that other people reuse.
Partnership with design. How early you raised constraints, and how many rounds a handoff took.
An honest bundle. Dependencies you added or removed, and why.

Example: impact

The projects, people and numbers in these examples are made up. Keep the shape and use your own facts.

Impact • Rebuilt the Recipe App 2.0 web editor on the shared component library. 14 screens moved over, and the editor's CSS shrank by about a third. • Brought Largest Contentful Paint on recipe pages from about 3.1 s to 1.9 s on a mid-range Android phone (lab test), by lazy-loading images and splitting the editor out of the main bundle. • Fixed 23 issues from the accessibility audit (APP-512). Keyboard and screen reader users can now create and publish a recipe without a mouse.

The device matters as much as the number. 1.9 s on a fast laptop and 1.9 s on a mid-range phone are different claims.

Example: collaboration

Collaboration • Met Neha (design) weekly while we built the component library. We agreed tokens before code, and most screens needed one round of design QA instead of three. • Wrote "Adding a component", a two-page guide. Two new joiners shipped their first component from it without pairing. • Reviewed the Sync SDK team's front-end pull requests for the sync status indicator, so it matches the rest of the app.

Example: growth

Growth • Learned to profile with the browser's performance panel instead of guessing. The paint-time work above started there. • Made my first cross-team decision: replacing our date library. I wrote the comparison, Ravi pushed back on bundle size, and we picked the smaller option. • Next half: performance budgets in CI, so a regression fails a build instead of reaching users.

Phrases that land

"Keyboard users can now…": a capability someone gained.
"from 3.1 s to 1.9 s on a mid-range phone": number, before, after, and the device.
"Removed 9 one-off button styles": deletions count, and reviewers notice them.
"one round of design QA instead of three": collaboration written as an outcome.

Phrases that don't

"Pixel-perfect implementation." Reviewers already assume you matched the design.
"Made the UI better." Better for whom, and measured how?
"Worked closely with design." Everyone writes it. Say what changed because of it.
"Built 14 screens." That's output. Say what the screens let people do.

Gather your evidence

Filter your history to the folders you own. This shows your commits to components and pages over six months, with dates:

git log --since="6 months ago" --author="$(git config user.email)" --no-merges \ --date=short --format='%ad %s' -- src/components src/pages

Change the paths to match your repo. Then collect what git can't hold: before and after screenshots, performance reports from the lab and from real users, the accessibility audit with what you closed from it, and the design files your work matched.

Let Sill keep the record

Front-end wins pile up as small commits across many weeks, and that's exactly what memory drops first. Sill keeps the record while you work. On the Mac it reads your local git history (commit messages and times, never code). On every device it records the tasks you finish, the releases you ship and the follow-ups you send, with receipts like day 6, asked 3×.

At review time, Sill Pro's Review generator turns months of that into a draft per project: what shipped, commit counts and ticket IDs, and every dependency you waited on. Where Apple Intelligence is available it writes a first-person draft on the device, and nothing leaves it. Commits come only from the Mac app. The last 7 days are free; longer periods need Sill Pro, an optional paid upgrade.

Get Sill on the App Store — for Mac, iPhone, iPad and Apple Watch. The daily standup and its set-time reminder are free.

More self-review examples: backend engineers · iOS engineers · Android engineers · QA engineers · SRE and DevOps engineers · data engineers · engineering managers · product designers · product managers. Or start with how to write a self-review.