702+ examples
Self-review examples for software engineers.
Self-evaluation examples and the matching performance review phrases for managers, by level, competency and rating. Pick the sentences that fit, fill in your own projects and numbers, and copy the draft.
Writing
Level
Competency
Rating
Technical execution, meets, mid-level
Click a sentence to add it to your draft. Switch competency or rating to add more.
Your draft
Your picks show up here. Edit them in place: replace each [placeholder] with your own project, metric or example.
702+
phrases, in the first and third person
5
levels, from junior to engineering manager
9
competencies from engineering career ladders
How to write a strong self-review, in three habits.
Keep a brag doc. Nobody remembers in December what they shipped in March. Keep a running doc with a line or two each week: what you shipped, what you fixed, who you helped, any number you can attach. Link the PR, the dashboard or the message where someone said thanks. At review time you're choosing from evidence instead of guessing.
Write impact, not activity. "Worked on" and "helped with" tell the reader you were there. Say what changed because of you: for users, for the team, for the business. Lead with the two or three biggest things, not every ticket.
Use numbers. Latency, error rates, conversion, cost, time saved, pages per shift, review turnaround. A rough number with a source beats no number. If the work was enabling, count what it enabled: "three teams now ship on it".
- I worked on the payments migration.I led the payments migration, moving 40k merchants with zero downtime and cutting failed charges from 2.1% to 0.6%.
- I did a lot of code reviews.I gave the first review on 180 PRs this half, with a median turnaround under four hours.
- I helped the new hires.I was onboarding buddy for two new engineers. Both shipped to production in their first week.
- I was on call.I handled 14 pages across five shifts, and my alert cleanup cut noise on the search service by 60%.
Be honest about one thing that didn't go well. A short, specific growth area with what you changed reads as maturity. Leaving it out makes the reader wonder what else is missing. And write for your level: a senior engineer's review should show influence beyond their own tickets, and a staff engineer's should show impact across teams.
A self-review template to copy.
The structure most engineering review forms ask for, in the order a reader wants it. Fill each section from your brag doc, and use the examples above for the competencies.
Self-review: [cycle, e.g. H2 2026]
Summary
Two or three sentences: the most important thing I delivered, the impact it had, and how I grew.
Key accomplishments
For each, what I did, why it mattered, and the result in numbers.
- [Project]: I [what you did]. This [result, e.g. cut p95 latency from 800 ms to 300 ms / raised activation from 31% to 38%].
- [Project]: ...
- [Project]: ...
How I worked
One or two examples each for the competencies on our ladder: technical execution, code quality, ownership, collaboration, communication, mentoring, reliability.
What didn't go well, and what I learned
- [Something that slipped or went wrong], and what I'm doing differently now.
Feedback I received
- [Quote or summary from a peer, review or retro.]
Goals for next cycle
- [Goal 1, with how we'll know it's done]
- [Goal 2]
What I need from my manager
- [Support, scope or opportunities that would help.]
Copy pastes as formatted text into Google Docs, Notion or Confluence. Markdown is for GitHub, Jira or Slack.
Performance review phrases for managers.
Switch the tool above to A review as manager and every example turns into the third person, with [Name] filled in from the name you type. A few of the most searched categories:
Quality of work
- [Name] writes some of the cleanest code on the team. Reviewers often point to their PRs as examples.
- [Name] raised test coverage on [service] from [X]% to [Y]%, focused on the paths that had caused incidents.
- [Name] writes small, focused PRs with clear descriptions, which makes them easy to review.
- [Name] adds tests with every change, and bugs rarely come back from QA.
- [Name]'s PRs are often too large to review well. [X] of [Y] this cycle were over [Z] lines.
- [Name] needs to add tests for new behavior. Several bugs in [feature] would have been caught by a unit test.
Job knowledge
- [Name] has deep knowledge of [system] and is the person the team goes to with questions about it.
- [Name] understands how [service] fits into the wider architecture and uses that to avoid problems for other teams.
- [Name] keeps up with changes in [language or framework] and brings useful ideas back to the team.
- [Name] knows the codebase well enough to work independently on most tickets in [area].
- [Name] needs to build a deeper understanding of [system] before taking on larger changes there.
- [Name] would benefit from learning more about [domain, like billing], so technical choices match how the business works.
How to write a performance review people can act on: gather examples from the whole cycle (your 1:1 notes, the person's brag doc, peer feedback), then for each competency give one or two examples of what they did and what it changed. Keep strengths and growth areas in proportion to reality, and phrase growth areas as what to do next. If something in the review would surprise them, you waited too long to say it.
For someone whose gaps are serious and haven't changed with feedback, a performance improvement plan sets clear goals and support. For the ongoing conversations, use the 1:1 meeting template.
Self-evaluation examples by competency.
One sentence per competency for a mid-level engineer who meets expectations, as a starting point. The tool has five or more for every level and rating.
Technical execution
I delivered [project] on the date we agreed, and scope changes were discussed before they happened.
Code quality
I write small, focused PRs with clear descriptions, which makes them easy to review.
Ownership
I follow through on what I commit to, and say early when something won't happen.
Collaboration
I work well with product and design, and bring them in early when something technical changes the plan.
Communication
I write clear PR descriptions and design docs that explain the problem, the approach and the tradeoffs.
Mentoring
I help newer teammates when they're stuck and explain the why behind each suggestion.
Impact and business outcomes
I shipped [feature], which [X]% of active users now use.
Reliability and on-call
I handle on-call shifts calmly and follow the runbook.
Growth
I seek out feedback and act on it.
Questions
What should I write in a self-evaluation?
Lead with the two or three things that had the most impact, each with what you did, why it mattered and a number. Then cover how you worked against your company's competencies, one thing that didn't go well and what you learned, and your goals for next cycle.
What is a good example of a self-review comment?
A specific one with a result: “I led the migration of checkout to the new payments API, which cut failed payments from 2.1% to 0.6% and let us retire two legacy services.” It names the work, your part in it and the outcome.
How do you write a performance review for an employee?
Collect examples across the whole cycle, not just the last month. For each competency, give a rating and one or two specific examples of behavior and its impact. Balance strengths and growth areas, keep it about the work, and end with clear goals. Nothing in it should be a surprise.
What are examples of performance review phrases?
For quality of work: “[Name] writes small, focused PRs with clear descriptions.” For job knowledge: “[Name] is the person the team goes to for questions about [system].” For a growth area: “[Name] needs to raise risks earlier.” The tool above has hundreds more by level and rating.
How do you write about weaknesses in a self-review?
Pick one real growth area, give a short example, and say what you're already doing about it. “I took on too much in Q3 and two tickets slipped; I now flag risk by the sprint midpoint” shows self-awareness without underselling your work.
How long should a self-review be?
Usually one to two pages. Reviewers read many of them, so a few strong, specific examples with numbers beat a long list of tasks.