Mentoring juniors

As an SDE2 you will onboard interns, help juniors and teach through code review. This is not charity; it is how teams scale and how you demonstrate senior leverage.

New people drown in context. Your job is a runway, not a pop quiz.

Walking through onboarding

• First-week wins. A small production change in days one to five beats a week of only reading. Confidence compounds.
• Maps, not encyclopedias. Sketch the service boundaries, where logs live, who to ask for what. Link runbooks; do not recite them.
• Pair on the first incident-shaped task. Sit together (or share a screen) for the first non-trivial debug. Narrate how you search, not just the answer.
• Office hours. A standing "ask me anything" slot beats constant interrupts and teaches them to batch questions.

Reviews are the highest-frequency mentorship channel you have. Prefer questions that build judgment over drive-by rewrites:

• "What happens if this RPC fails mid-batch?"
• "Could a reader tell why we chose eventual consistency here?"
• "Want to extract this for testability, or is the deadline binding?"

When you must insist, say so and why ("we need the timeout — we burned production on this last quarter"). Separate nits (optional) from blockers.

If you always jump to the answer, you create dependents. If you never help, you create frustration. The middle path:

1. Ask what they have tried and what they think is true.
2. Give the next hint, not the full solution — a search term, a file, a hypothesis to test.
3. Time-box the struggle ("try for 25 more minutes, then we'll pair").
4. Afterward, ask them to write the fix or the learning in a short note. Teaching sticks when they articulate it.

A simple intern / new-grad arc beats improvisation:

Write feedback for their manager while details are fresh. Interns disappear from your brain after the farewell pizza; contemporaneous notes are a kindness and a professionalism signal.

Not everything needs a formal label. Invite a junior to a design review and assign them one question to research beforehand. CC them on a decision email with a one-line "FYI — good example of how we trade scope." After you debug something gnarly, spend ten minutes turning it into a team FAQ.

Common mistakes

• Answer vending machine: you solve every problem for them.
• Pop-quiz onboarding with no first-week win.
• Coaching through a sev. Say you are in answer mode.

Check yourself

A junior pings during a sev. Coach or answer?

Answer directly, then explain why. Coach when the blast radius is small.

An intern finishes in three weeks. When do you write feedback?

While details are fresh — not after the farewell pizza.

Key takeaways

• First-week production win, maps not encyclopedias, pair on the first gnarly debug.
• Reviews teach with questions; nits are optional, blockers are named.
• Productive struggle with a time box, unless the cost of delay is high.
• Interns: a 30-day arc and contemporaneous feedback.

Further learning

Next, stop depending on one hero: building a mentor bench.