Review Junior Engineer PRs — Code Reviews That Help, Part 9

Code Reviews That Help · Part 9

A review is the highest-bandwidth teaching moment a senior engineer gets — and the fastest way to waste it is to rewrite a junior's code for them and move on. Done well, reviewing a junior's PR grows an engineer; done badly, it grows a rubber-stamper who stops trying. This walks through reviewing junior PRs to teach: prioritizing the few issues that matter, explaining the why, and leaving them ownership of the fix.

Code review is a teaching opportunity. Get it right; juniors grow. Get it wrong; they shrink.

Step 1: Prioritize the Top Issues (10 min)

A junior's PR may have 30 issues. Comment on the top 5:

• Critical correctness

• Major patterns to learn

• Specific habits worth building

The other 25? Let them go. Or roll into one summary comment.

Drowning them in nits = paralysis.

Step 2: Explain the Why (10 min)

✗ "Don't do this."
✓ "Avoid mutable global state because two requests can interleave. Here's an example: ..."

Show the reasoning. Junior learns the principle.

For repeated patterns, link to docs or your team wiki.

Step 3: Suggest, Don't Dictate (10 min)

✓ "Consider extracting this into a helper — would make the test cleaner."
✗ "Extract this into a helper."

Even when you're sure: framing as suggestion preserves their judgment.

If they push back with reasoning: maybe they have a point. Listen.

Step 4: Praise Specifically (10 min)

"Nice — early return makes the happy path much clearer here."
"Good test coverage; you covered the empty case I would have forgotten."
"Clean naming throughout."

Specific praise teaches what's good.

Junior learns: "ah, this is the pattern I should reach for."

Step 5: Ask Questions (10 min)

"Why did you choose recursion here vs. iteration?"

"Have you considered what happens if the list is empty?"

"What's the failure mode if X service is down?"

Questions teach to think. Better than asserting answers.

Often: the question itself surfaces the answer in the junior's head.

Step 6: Don't Rewrite (10 min)

Tempting:

"Here's a complete rewrite that's better."

What the junior learns: "I'm not good enough; the senior just rewrites."

Reviewing juniors is also where experienced engineers' own habits show; see The Senior Engineer's Blind Spot.

Better: comment on what to change; let them make the changes.

Exception: very tight deadline, low stakes — pair on it instead.

Step 7: Show Examples (10 min)

"Here's a similar pattern from elsewhere in the codebase: [link]"

Or:

"Example of the pattern I'm suggesting:
   ```python
   def example(): ...

"

Concrete > abstract. Easier to apply next time.

## Step 8: Multi-Round Mentality (5 min)

Junior PRs may need 3-4 rounds of review. That's fine.

Each round, fewer issues. Eventually:

- Round 1: 5 critical comments
- Round 2: 2 follow-ups
- Round 3: LGTM

Don't sigh at multiple rounds. It's how learning happens.

## Step 9: Pair on Hard Stuff (10 min)

For genuinely complex changes:

- 1-hour pair session
- Walk through it together
- Junior drives; senior advises

Beats 20 review comments.

Lower friction; faster learning.

## Step 10: Give Them Ownership (10 min)

After enough success: trust them.

- Smaller PRs without senior review
- Owning a feature area
- Reviewing others' PRs themselves

The arc: heavy mentorship → light mentorship → independence → mentor.

Speeds the curve. Builds the team.

## What You Just Did

Junior reviews: prioritize, explain why, suggest, praise specifically, ask questions, don't rewrite, examples, multi-round, pair sometimes, grow ownership. Mentorship through review.

## Common Failure Modes

**100 nits on a junior's first PR.** Demoralizing.

**Rewrite instead of feedback.** Junior doesn't learn.

**Curt "this is wrong; fix it."** Confusing; alienating.

**Same nits repeated; no growth.** Either junior isn't learning or feedback isn't clear.

**Hand-holding forever.** No independence; bottleneck.

---

## Continue the Code Reviews That Help path

- **Previous —** [Part 8: Handle Disagreement in Reviews](/post/tutorial-8-handle-disagreement-in-reviews)
- **Next —** [Part 10: Measure Review Health](/post/tutorial-10-measure-review-health)

_Part of the **Code Reviews That Help** learning path._