Performance review examples
Software engineer performance review examples, with competencies and goals
Three complete sample reviews for software engineers — one exceeds, one meets, one needs improvement — with the engineering competencies behind them, measurable goals and a review template you can copy.
By the CLEAR Talent team
Engineering reviews fail in two familiar ways. Either they count output — tickets closed, lines changed — which rewards the wrong work, or they fall back on impressions such as “strong engineer” that nobody can act on. Neither helps an engineer understand what the next level asks of them.
The reviews below rate four engineering competencies — technical delivery and quality, system design and technical judgement, operational ownership, and collaboration and knowledge sharing — with the specific work behind each rating, then set goals an engineer can measure during the year.
What to rate
Software engineering competencies to review against
These four competencies apply from junior to senior engineer; what changes with level is the scope. A mid-level engineer meets on system design by contributing well to designs others lead; a senior engineer meets by leading them.
If your team already has a levelling ladder, use its wording and its levels. The point is that every rating is read against a description the engineer has seen before the review.
| Competency | Meets expectations | Exceeds expectations |
|---|---|---|
| Technical delivery and quality | Delivers scoped work to the team’s definition of done — reviewed, tested and documented — and revises estimates when scope changes. | Takes on ambiguous work, breaks it down for others and leaves the codebase easier to change than they found it. |
| System design and technical judgement | Contributes to designs at the scope of their level, weighs alternatives and raises risks before build starts. | Leads designs beyond their level’s scope, writes them up so others can review and reuse them, and makes trade-offs explicit. |
| Operational ownership | Owns what they ship in production: monitors it, responds on call, writes postmortems and closes the actions. | Reduces incidents at the source — alerting, runbooks, fixes to recurring failures — for systems beyond their own. |
| Collaboration and knowledge sharing | Reviews code promptly and usefully, shares context in writing and works smoothly with product and design. | Raises the level of the team: mentoring, reviews that teach, sessions on topics others asked about. |
A starting point to adapt to your own levelling ladder, not a validated model.
Measurable goals
Measurable goals for software engineers
Engineering goals are measurable when they name an outcome in the system or the team rather than an amount of activity. Pair one or two delivery goals with one development goal tied to the next level.
Delivery and reliability goals
A named delivery
Ship the billing-service migration by the end of quarter two behind a feature flag, with no customer-facing incident during cutover.
Performance
Bring the 95th-percentile response time of the search endpoint from 800 ms to under 400 ms by the end of the half, measured on the production dashboard.
Operational follow-through
Write the postmortem within five working days of every incident you lead, and close its actions within two sprints.
Development goals
Design leadership
Write and lead the review of one design document per half for a feature the team owns, approved at the engineering design review.
Code review
Pick up review requests within one working day, and ask two engineers at the half-year whether the reviews help them.
Mentoring
Pair with the team’s newest engineer for an hour a week for their first quarter.
The numbers are placeholders to show the shape of a measurable goal. Set the real figures from your own targets and last year’s results, not from this page.
The software engineer performance review template
Template
Software engineer performance review
Fill in the review details, then one row per competency in the role profile — for engineers, usually the four in the table above, read at the engineer’s level. The overall rating goes in last, once the rows are written.
| Field | What to write |
|---|---|
| Review details | |
| Employee | Name, or an employee ID if the form will travel beyond the manager and HR. |
| Role and team | Job title, team and level, so the reader knows which standard applies. |
| Review period | The dates the review covers. Evidence from outside them does not belong here. |
| Overall rating | Exceeds, meets or needs improvement against what the role requires. Decide it after the rows below, not before. |
| Summary | Three or four sentences: the headline result, the strongest evidence and the one thing to change. The employee should recognise every sentence. |
| Goals for the next period | Two or three goals, each with a number or an observable outcome and a date. |
| For each competency (up to 5) | |
| Competency | A competency from the role profile, with the level the role requires. |
| Rating | Exceeds, meets or needs improvement, for this competency only. |
| Evidence | Two or three specific examples from the period — what happened, when and the result — with figures where the role has them. |
| Next step | What to keep doing, stretch into or change, in one sentence the employee can act on. |
Show the plain-text template
SOFTWARE ENGINEER PERFORMANCE REVIEW Employee: Role and team: Review period: Overall rating: Summary: Goals for the next period: COMPETENCY 1 Competency: Rating: Evidence: Next step: COMPETENCY 2 Competency: Rating: Evidence: Next step: COMPETENCY 3 Competency: Rating: Evidence: Next step: COMPETENCY 4 Competency: Rating: Evidence: Next step: COMPETENCY 5 Competency: Rating: Evidence: Next step:
Nothing here is gated: the spreadsheet and the text file hold exactly the fields shown above, with five blank competency rows.
How to write a software engineer performance review
Most of the evidence already exists in pull requests, design documents and incident records. The work is choosing the right pieces and reading them against the level.
Start from the level, not the person
Re-read what the engineer’s level asks for in each competency before looking at any evidence. A strong year for a mid-level engineer may be an ordinary one for a senior.
Collect evidence from the work itself
Two or three pieces per competency: a shipped feature, a design document, a postmortem, a sample of code reviews. Ask the tech lead and one or two peers what they saw.
Rate impact, not activity
Tickets closed and commits made say little on their own. Ask what changed for users, the system or the team because of the work, and rate that.
Name the gap to the next level
For each competency, say what the engineer would need to do differently to be rated at the next level. That sentence is usually the most useful one in the review.
Agree goals with an owner and a date
Turn the gap into one development goal and pair it with one or two delivery goals, each with a measure the engineer can check without waiting for the next review.
Software engineer performance review examples at three rating levels
A senior engineer who exceeded, a mid-level engineer who met expectations and a mid-level engineer whose year needs improvement. Each rates the same four competencies at the engineer’s own level.
These reviews were written for this page to show a workable level of detail at each rating. They describe no real employee or CLEAR Talent customer, and every figure in them is an illustrative placeholder, not a benchmark.
Exceeds expectations
Example 1: exceeds — a senior software engineer
Senior engineer on a payments platform team of six. Led the year’s largest migration and has been growing two less experienced engineers.
- Role and team
- Senior software engineer, payments platform
- Review period
- January to December
- Overall rating
- Exceeds expectations
- Summary
- Led the payment-retry migration from design to release with no customer-facing incident, and wrote a design that two other teams have since adopted. Mentoring has visibly changed how two engineers work. On-call follow-through is solid but one postmortem action slipped.
- Goals for the next period
- Lead the design of the refunds rework through review by the end of quarter two; close every postmortem action within two sprints; present the queue-based retry pattern at the engineering all-hands in quarter one.
Competency 1
- Competency
- Technical delivery and quality (role requires: senior)
- Rating
- Exceeds
- Evidence
- Moved card-payment retries to a queue-based service in two phases behind a feature flag. Cutover in May with no customer-facing incident; the old retry code was removed in June.
- Next step
- Apply the same phased approach to the refunds rework.
Competency 2
- Competency
- System design and technical judgement (senior)
- Rating
- Exceeds
- Evidence
- The retry design document set out three alternatives and the trade-offs between them. Two other teams adopted the pattern for their own retries in quarter three.
- Next step
- Lead the refunds design and invite one of the adopting teams to review it.
Competency 3
- Competency
- Operational ownership (senior)
- Rating
- Meets
- Evidence
- On call one week a month. Led two incidents, both resolved within the agreed time, with postmortems written inside the week. One postmortem action, an alert threshold change, slipped two sprints.
- Next step
- Book postmortem actions into the sprint they are agreed in.
Competency 4
- Competency
- Collaboration and knowledge sharing (senior)
- Rating
- Exceeds
- Evidence
- Paired weekly with two engineers through the year; both now ship features without senior review of the design. Ran two internal sessions on the payments domain.
- Next step
- Keep the pairing with one engineer and hand the other to a newer senior.
Meets expectations
Example 2: meets — a mid-level mobile engineer
Mid-level engineer on the mobile app team, two years in role. Delivers reliably; code reviews are where the year was weakest.
- Role and team
- Software engineer, mobile app
- Review period
- January to December
- Overall rating
- Meets expectations
- Summary
- Delivered every committed feature at the expected quality and fixed the app’s most frequent crash from the crash reports. Contributions to design reviews are thoughtful. Code reviews were slow, which held up others more than once.
- Goals for the next period
- Pick up review requests within one working day from February; write and lead the design review for one feature by the end of quarter two; keep the crash-free session rate at or above its current level.
Competency 1
- Competency
- Technical delivery and quality (mid-level)
- Rating
- Meets
- Evidence
- Shipped the offline mode and the new onboarding flow on the planned releases, with tests and release notes. Re-estimated the onboarding work when the scope grew rather than letting the date slip silently.
- Next step
- Keep the practice; take on one piece of work with unclear scope next half.
Competency 2
- Competency
- System design and technical judgement (mid-level)
- Rating
- Meets
- Evidence
- Raised the conflict case in the offline-sync design that would have overwritten user edits; the design was changed before build.
- Next step
- Write and lead the review of a design document for one feature.
Competency 3
- Competency
- Operational ownership (mid-level)
- Rating
- Exceeds
- Evidence
- Traced the most frequent crash in the app to a race condition from crash reports alone and fixed it in the next release. Added a runbook for the release process that the team now follows.
- Next step
- Share the crash-investigation approach at a team session.
Competency 4
- Competency
- Collaboration and knowledge sharing (mid-level)
- Rating
- Needs improvement
- Evidence
- Pull requests waited an average of three working days for their review, and twice a release was held for it. Reviews, when given, were careful and useful.
- Next step
- Pick up review requests within one working day; block two short review slots a day.
Needs improvement
Example 3: needs improvement — a mid-level data engineer
Mid-level engineer on a data platform team, eighteen months in role. Good design instincts, but delivery and ownership of production pipelines fell short of the level.
- Role and team
- Software engineer, data platform
- Review period
- January to December
- Overall rating
- Needs improvement
- Summary
- Contributed good ideas to design work, but three of five committed pieces of work carried over and two incidents on owned pipelines had no runbook. This rating is about delivery habits and production ownership, both of which can change quickly with the support below.
- Goals for the next period
- Deliver committed work in the sprint it was planned for in at least four of every five sprints; write runbooks for all three owned pipelines by the end of February; raise scope changes at stand-up within a day of finding them.
Competency 1
- Competency
- Technical delivery and quality (mid-level)
- Rating
- Needs improvement
- Evidence
- Three of five committed items carried over at least one sprint. In each case the scope had grown and the estimate was not revised until the sprint review.
- Next step
- Raise scope changes at stand-up within a day; pair with the tech lead on breaking down the next two items.
Competency 2
- Competency
- System design and technical judgement (mid-level)
- Rating
- Meets
- Evidence
- Proposed the partitioning scheme adopted for the events table, with a clear write-up of the trade-offs.
- Next step
- Keep contributing; take a design through review end to end next half.
Competency 3
- Competency
- Operational ownership (mid-level)
- Rating
- Needs improvement
- Evidence
- Two incidents on pipelines this engineer owns had no runbook, which lengthened recovery. A noisy alert was silenced rather than fixed and missed a real failure in October.
- Next step
- Write runbooks for all owned pipelines and fix, rather than silence, noisy alerts.
Competency 4
- Competency
- Collaboration and knowledge sharing (mid-level)
- Rating
- Meets
- Evidence
- Code reviews are timely and constructive. Answers questions from the analytics team in the shared channel.
- Next step
- Write up the events-table design for the analytics team’s wiki.
From template to review cycle
Running engineering reviews on a competency framework
In CLEAR Talent the competencies on this page would sit in one competency library, each with behavioural anchors and proficiency levels, and a role profile sets the competencies the role requires and the target level for each. A rating can require evidence — a project, a deliverable or an observed behaviour — and self-assessment and manager assessment are compared side by side, so both sides argue from the same facts.
Competency scales are configured by you, with three to seven levels each, and different scales can run for technical, leadership and individual-contributor roles — so an engineering levelling ladder can be expressed as role profiles with a target level per competency rather than kept in a separate document.
The same competencies run through reviews, 360° feedback and development plans. Each assessment drafts an individual development plan around the competencies that matter most for the role, ranked by the size of the gap, and the next review re-scores them on the same scale — so you can see whether a needs-improvement rating actually moved.