Guides for engineering managers

Performance review examples for software engineers

Side-by-side weak and stronger examples for every part of an engineering review, from impact to growth areas.

Keel team · · 6 min read

The short version
  • A good review paragraph names what the person did, gives an example with a date or project, and says why it mattered.
  • Below are weak and stronger versions for impact, code quality, collaboration, ownership, communication, and growth areas.
  • Copy the shape, not the words. The specifics are what make a review useful.

Most review examples online are lists of phrases: "consistently delivers high-quality code", "a strong team player". Phrases like these are why reviews feel generic. An engineer can't act on them, and a promotion committee can't weigh them.

Below are examples of the paragraphs that actually go into an engineering review, each shown first as a typical weak version and then as a stronger one. The names and projects are made up. What matters is the shape: behaviour, example, effect.

Impact and delivery

Weak

Alex delivered a lot this half and was very productive.

Stronger

Alex led the move from nightly batch exports to streaming (April to June), which customers had asked for in a third of churn interviews. He scoped it into three releases so we could ship value in weeks instead of one big launch, and the first release alone cut report freshness from 24 hours to under five minutes.

Code quality and technical judgement

Weak

Sam writes clean code and has good technical skills.

Stronger

Sam's design doc for the permissions rewrite was the best this half: it compared three approaches, was explicit about what we were giving up, and got sign-off in one review. Since it shipped we have had no permission-related incidents, after four in the previous quarter. Sam also added the integration tests that caught two regressions before release.

Collaboration and code review

Weak

Jordan is a great team player and always willing to help.

Stronger

Jordan reviewed more of the team's pull requests than anyone else this half, and the reviews teach as well as catch: newer engineers cited them twice in peer feedback as how they learned our data layer. When Mei joined in July, Jordan paired with her for her first two weeks and she shipped her first feature by week three.

Ownership and reliability

Weak

Taylor takes ownership and is reliable.

Stronger

When the payment webhook incident hit on a Saturday in August, Taylor coordinated the response, kept the incident channel updated every 30 minutes, and wrote the postmortem by Tuesday. Two of its four follow-up actions were Taylor's own, and both are done. The retry policy change has removed that class of incident since.

Communication

Weak

Chris communicates well with stakeholders.

Stronger

Chris's weekly update on the onboarding project became the template other teams now copy: three lines on progress, one on risks, one on what he needs. Sales told us they stopped asking engineering for status because the update already answered it.

Growth areas

Growth areas are where reviews most often go wrong. The goal is something the person recognises and can work on, not a label.

Weak

Morgan needs to work on time management.

Stronger

On both the search and billing projects, Morgan's estimates were about twice as long in reality, and the team found out at the deadline. The work itself was strong. Next half, I'd like Morgan to break projects into milestones of a week or less and flag in the project channel when any milestone slips, even by a day. I'll review the first plan with him.

Weak

Riley should be more of a leader.

Stronger

Riley is consistently the strongest debugger on the team, but most of that knowledge stays with her: in two incidents this half, the fix depended on her being online. To reach senior, I'd like Riley to spread it: write runbooks for the two systems she knows best, and lead one incident review as facilitator rather than fixer.

A summary paragraph

Example

Priya operated at the senior level throughout this half. She drove the payments migration from design to launch, mentored two newer engineers through their first on-call rotations, and her reviews set the quality bar for the team. Her main growth area is scope: she tends to absorb work herself instead of delegating it, which made her the bottleneck in July. Rating: exceeds expectations. Next half she will lead the reconciliation project with two engineers, with the goal of shipping it without being on the critical path herself.

What makes these work

The hard part isn't the writing. It's having the examples on hand when you sit down. If you're starting from memory, see how to keep a brag doc for your whole team, and use the structure in how to write an engineering performance review.