For a long time, review was treated as a by-product of engineering. Everyone did it, nobody was assessed on it, and the quality varied enormously. In the Software Engineering standard, code review is now one of six capability areas alongside design, testing, maintenance, documentation and performance, and it is assessed on evidence like the rest.
Why review deserved its own capability
As more first-draft code is produced with automated assistance, the value of a careful reviewer has gone up, not down. Our employer council was consistent on this point: the engineers they promote are the ones whose review comments make other people better. Until now there was no consistent way to recognise that.
You can tell a senior engineer by their review history faster than by their commit history. One shows what they can do; the other shows what they make possible.
What good review evidence looks like
We are not interested in volume. Approving a hundred pull requests says very little. Assessors look for review threads that show judgement, for example:
- Comments that explain the reasoning behind a request, so the author learns something transferable.
- Catching a design problem early, before it became expensive to change.
- Knowing when not to comment, and letting a reasonable choice stand.
- Improving the practice itself: guidelines, checklists or the way a team shares the review load.
- Reviewing machine-generated code as rigorously as any other, and being able to say what you checked.
How expectations rise through the levels
At BIPS Foundation, candidates should understand why review exists. At BIPS Practitioner, delivering features within an established codebase, we look for evidence of receiving review well and giving thoughtful review to peers. At BIPS Professional, owning a service over time, review should visibly shape its quality.
At BIPS Specialist and BIPS Expert we expect you to have set the review culture others work within. At BIPS Fellow, where recognition comes through contribution to the profession, the evidence often extends to open-source maintenance or teaching others how to review.
In the professional discussion
Evidence does not have to come from a single employer or a single codebase. Review threads from open-source projects, internal repositories and client work are all acceptable, redacted where needed, provided the evidence review can confirm they are yours.
Expect to be shown one of your own review threads and asked why you wrote what you did. What were you worried about? Would you say it the same way today? It is often the most revealing part of the conversation, and candidates who review with care usually enjoy it.