Mentoring Junior Engineers: Code Review Practices That Actually Help

The two failure modes of code review as mentorship

The first is the rubber stamp — "LGTM," merged, nothing learned. The second, more well-intentioned but just as unproductive, is the review that lists ten style nitpicks and no discussion of the actual design decision underneath the PR. Both miss the point: a code review is one of the highest-leverage teaching moments available, because it's grounded in real code the engineer just spent real effort writing, not an abstract lesson.

Ask "why," don't just say "change this"

The single highest-leverage habit I've built into my review process is replacing directive comments with questions, wherever the answer isn't a hard correctness issue:

• Instead of "use a Map instead of an object here" → "what made you reach for a plain object here — did you consider a Map, and if so what ruled it out?"
• Instead of "this should be async" → "what happens to the caller if this function takes longer than expected — is it currently safe?"

The directive version fixes one line. The question version, when it lands well, changes how the engineer approaches the next ten similar situations, because they've reasoned through the tradeoff themselves rather than pattern-matched a rule.

Separate "must fix" from "worth thinking about"

A review with fifteen unlabeled comments reads as uniformly critical, and a junior engineer often can't tell which three actually block the merge and which twelve are optional suggestions for next time. I explicitly tag comments — blocking: for correctness or security issues that must be addressed, consider: for genuine improvements that aren't required, and nit: for pure style preferences the author can take or leave. This alone measurably reduced how defensive reviews felt to receive, because the signal-to-noise of "what actually needs to change" became explicit instead of implied.

Review the design before the implementation

The most expensive reviews to give — and the ones that help the most — happen before code is written at all: a quick design conversation about the approach, ideally as a rough plan or even just a Slack message, before someone spends two days building something that needs a fundamentally different structure. A PR-stage comment that says "this whole approach needs to change" after the implementation is done is demoralizing in a way that the same feedback given a day earlier, at the design stage, simply isn't.

Pairing on the fix, not just flagging the problem

For genuinely difficult feedback — a security issue, a race condition, an architectural problem — a 15-minute pairing session walking through the fix together teaches more than any comment thread could, and it signals that the feedback is collaborative rather than a judgment being handed down. I reserve this for the cases that are actually worth the time investment, not every review, but the cases where I use it are consistently the ones junior engineers cite later as when something genuinely clicked.

The metric that actually matters

The real signal that mentorship through code review is working isn't fewer review comments over time — it's the kind of comments shifting, from correctness and design issues toward genuine architectural discussion between peers. That transition, watching someone go from needing guidance on basic patterns to pushing back thoughtfully on your own suggestions, is the actual measure of whether the mentoring worked.