Mentoring, Code Review, Design Review

Зачем знать на Middle 3: код перестаёт быть единственным measure of impact. На Middle 3 от инженера ждут, чтобы он “размножал” себя через джунов: давал обратную связь, ускорял команду через грамотный review, формулировал технические решения в design docs, которые читают senior+. Это soft skills, которые в FAANG напрямую попадают в performance review (impact, leadership, technical guidance).

Содержание

1. Концепция
2. Глубже: mentoring frameworks, code review rules, design doc templates
3. Gotchas / Best practices
4. Real cases
5. Вопросы (20, в т.ч. behavioral)
6. Practice
7. Источники

---

1. Концепция

Mentoring: что это и не это

Mentoring это:

• Помощь росту через постановку задач чуть выше текущего уровня (zone of proximal development).
• Регулярные 1:1.
• Обратная связь по конкретным ситуациям.
• “Учить ловить рыбу”, а не давать готовые решения.

Mentoring не:

• Делать за подопечного.
• Раздавать только похвалу или только критику.
• Контролировать каждый шаг (micro-management).
• Дружба без структуры.

Code Review культура

Цели code review:

1. Bug detection — найти ошибки.
2. Knowledge sharing — распространить контекст.
3. Code quality — общий стандарт.
4. Mentoring — помочь автору расти.

Принципы (по Google Code Review Guidelines):

• В целом ревьюер должен одобрить, если CL улучшает систему, даже если он не идеален.
• Не блокировать на личных стилевых предпочтениях.
• Различать: nit: (мелочь), suggestion: (стоит подумать), issue: (надо исправить).

Design Review

Design doc — документ, описывающий решение задачи на уровне архитектуры:

• Что мы делаем.
• Почему так.
• Какие альтернативы рассмотрели.
• Какие trade-offs.

Это средство мышления автора и способ собрать обратную связь до того, как код написан.

---

2. Глубже

2.1 Mentoring frameworks

GROW model (структура 1:1 / coaching):

• Goal: чего хочется?
• Reality: где мы сейчас?
• Options: что можно сделать?
• Will / Way forward: что будем делать?

SMART goals:

• Specific, Measurable, Achievable, Relevant, Time-bound.

Пример: “Освоить gRPC и реализовать миграцию двух endpoint’ов из REST до конца Q2”.

Career ladder:

• Установите с менти явный target level (Middle 1, Middle 2, Senior).
• Покажите ladder (внутренний, либо общедоступные — Dropbox, Comcast, Patreon).
• Из ladder вытащите 2-3 поведения, которых пока не хватает.

1:1 structure (30 min):

• 10 min: статус, блокеры, цели на неделю.
• 10 min: career, growth, longer-term.
• 10 min: feedback (двусторонний), peer interactions.

2.2 Feedback frameworks

SBI (Situation-Behavior-Impact):

• Situation: “На вчерашнем дейли”
• Behavior: “ты перебил Petra несколько раз”
• Impact: “из-за этого его idea не была озвучена и команда потеряла важный контекст”.

FBI (Feeling-Behavior-Impact): вариант с feeling.

Radical Candor (Kim Scott):

• Caring personally (заботиться о человеке).
• Challenging directly (говорить прямо).
• Anti-patterns: ruinous empathy (только caring), obnoxious aggression (только direct), manipulative insincerity (ни того, ни другого).

Praise rules:

• Конкретно (не “молодец”, а “хорошо разобрал edge case с retry”).
• Публично, если ок.
• Приватно — для глубокой похвалы.

Critique rules:

• Приватно.
• На поведение, не на личность.
• Быстро, пока контекст свеж.

2.3 Code Review: best practices

Author checklist:

• PR <400 LoC (исключения: вынос модуля).
• Self-review перед request review.
• Описание: “что”, “почему”, “как тестировать”, скриншоты/логи.
• Все CI зелёные.
• Один PR — одна логическая задача (не ”+ rename + fix”).

Reviewer checklist:

• Timeliness: первый отклик в течение 4 часов в рабочее время, полный review в течение 24h.
• Не «штампуй LGTM» — реально читай.
• Различай must-fix vs nice-to-have явно.
• Тон: вопросы вместо приказов. “Можно ли это вынести в helper?” вместо “вынеси”.

Conventional Comments (https://conventionalcomments.org):

praise: Хороший test для timeout case.
nitpick (non-blocking): можно вынести magic number в const.
suggestion: рассмотри context.WithTimeout вместо time.AfterFunc.
question: что произойдёт, если ctx уже cancelled при входе?
issue (blocking): эта горутина не закрывается при error → leak.
todo (non-blocking): добавь metric для observability.

Go-specific code review checklist:

• Error handling: каждый error обработан (не _ = err).
• context.Context первым параметром, не nil.
• Не использовать panic в библиотечном коде.
• defer на закрытие ресурсов (Body, файлы, locks).
• Concurrency safety: go vet race detector, sync.Mutex инициализация (только value, не указатель если копируешь struct).
• Goroutine leaks: каждая горутина имеет exit condition.
• Channel direction (chan<-, <-chan) в сигнатурах.
• Слайсы: размер при append (capacity hint).
• Naming: short for local, descriptive for public.
• Exported идентификаторы документированы (godoc).
• Tests: subtests с t.Run, table-driven.

Анти-паттерны review:

• LGTM-rubberstamp — без чтения.
• Bikeshedding — спор о стиле важнее логики.
• Ego review — “я бы написал иначе” без бенефита.
• Endless review — 10 раундов на детали; merge тогда, когда ценность дельты ≤ времени.
• Personal attacks — “ты не умеешь писать Go”.

2.4 Pull Request size

Исследование SmartBear (2008): defect detection падает резко после 400 LoC. Google рекомендует <200. Большие PR:

• Разбивать на серию: refactor → feature → cleanup.
• Stack PRs (Phabricator, gh-stack, Graphite).
• Behind feature flag — мерджить инкрементально без user impact.

2.5 Design doc: шаблон

# RFC-NN: <Название>

| Status  | Draft / In Review / Approved / Implemented |
| Author  | <name> |
| Created | 2026-05-21 |
| Updated | 2026-05-25 |
| Reviewers | @senior1, @arch |

## TL;DR
Один абзац.

## Background / Context
Что есть сейчас. Почему задача появилась.

## Goals
- ...

## Non-goals
- ...

## Proposed design
Архитектура + диаграмма (Mermaid / ASCII).
Компоненты, потоки, API.

## Alternatives considered
1. Опция A — pros/cons.
2. Опция B — pros/cons.
3. Опция C — pros/cons.

## Trade-offs
- Performance vs cost.
- Time-to-market vs scalability.

## Migration plan
Phase 1, 2, 3. Rollback plan.

## Operability
- Metrics / SLO.
- Alerts.
- Runbook.

## Security
STRIDE per component.

## Open questions
- ...

Process:

1. Автор — async draft.
2. Comments в Google Docs / Notion / Markdown PR.
3. Reviewers (3-5 человек). Один — primary.
4. Sync review meeting только если async не сходится.
5. Approval: либо single approver (DRI), либо консенсус.
6. Архив в внутренней wiki / репе docs/rfcs/.

2.6 Design review meeting

• 30-60 min, fixed time-box.
• Pre-read обязателен (отправить doc ≥ 24h до встречи).
• Скип “presentation mode” — спрашивай “у кого есть вопросы или возражения?”.
• Записывай decisions/action items в реальном времени.
• Decision Owner — один человек.

2.7 Tech Lead responsibilities

• Tech direction — выбор технологий, паттернов.
• Quality bar — стандарты code review.
• Mentoring — рост команды.
• Cross-team alignment — синхронизация архитектуры.
• Hiring — интервью, on-boarding.
• Communication — переводить tech ↔ business.

Anti-pattern: Tech Lead = “tech super-coder”. Лидер ≠ best coder, лидер = тот, кто поднимает уровень команды.

2.8 On-boarding нового члена команды

Первые 30/60/90 дней:

• 30: настроить окружение, читать код, фиксить bug small.
• 60: первый feature, проводить code review.
• 90: independent работа, mentor для последнего newcomer.

Buddy system: одна assigned точка контакта (не PM, не TL).

---

3. Gotchas / Best practices

⚠️ Mentor burnout — слишком много менти. Lim 1-2 active mentee.

⚠️ Code review queue — pile of unreviewed PRs снижает скорость команды экспоненциально. Daily slot review.

⚠️ “Я бы сделал иначе” — не повод блокировать.

⚠️ Asynchronous design review работает только если все читают. Назначьте deadline + nudge.

⚠️ Design doc без ownership — никто не двигает, лежит вечно.

⚠️ PR description пустой — заставь автора заполнить шаблон.

⚠️ Review без context — попроси описать “почему так”, если непонятно.

⚠️ Personality conflict — если ты не можешь дать честный feedback, попроси посредника (TL, manager).

⚠️ Time zone misalignment — для distributed teams: ассинхронность по default; sync только когда асинх неприемлем.

⚠️ Junior pushback — не сдавайся, но проверь себя: вдруг ты не прав.

Best practices

• Pair programming session 1-2/week с менти.
• Daily review slot (30-60 min утром).
• Brag doc для каждого — пусть пишут свои достижения.
• Calibration — раз в квартал сверь self-assessment с твоим.
• Public praise / private critique (Bridgewater Ray Dalio — обратное часто работает, но рискованно для культуры).
• Read design docs других команд → понимаешь breadth организации.
• Write postmortem для каждого инцидента — blameless.

---

4. Real cases

4.1 Google Code Review Guidelines

Публичный документ (https://google.github.io/eng-practices/review/). Ключевые идеи:

• “In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.”
• Reviewer pushback на edge cases, security, тесты — ОБЯЗАТЕЛЕН.
• Размер: max few hundred lines.

4.2 Stripe RFC process

Внутренний RFC repo. Каждый дизайн doc — markdown в git. PR → comments → merge means “approved”. Author owner. Implementation tracked in отдельном issue.

4.3 Amazon “PR/FAQ”

Перед началом проекта пишется фейковый Press Release: что будет, зачем, кому. + Internal FAQ. Если “press release” звучит unconvincing → проект не идёт.

Применимо к dev: дизайн doc начинать с “пользовательской ценности”, не с архитектуры.

4.4 Кейс: Junior дев и PR на 2000 строк

Junior сделал PR на 2k строк (новая feature + refactor + cleanup). Reviewer закрыл и попросил разбить.

Урок: лучше потерять час на split, чем неделю на review monolith.

4.5 Кейс: design doc спас от 3-месячного фейла

Команда собиралась мигрировать на gRPC. Design doc прошёл review, на котором senior из соседней команды показал, что один из клиентов — IoT с ограниченным CPU и proto reflection unsupported. Спасли проект от частичной миграции и rollback.

---

5. Вопросы (20)

Технические

1. Что входит в Code Review Checklist для Go?
2. Чем nit: отличается от issue: в conventional comments?
3. Какой максимальный размер PR с т.з. defect detection?
4. Что такое stacked PRs и зачем они нужны?
5. Какие секции обязательны в design doc?
6. Чем “alternatives considered” отличается от “non-goals”?
7. Кто такой Decision Owner и зачем он?
8. Что такое blameless postmortem?

Behavioral / leadership

9. Расскажи о ситуации, когда ты не согласился с тех. решением senior. Что сделал?
10. Как давал negative feedback подчинённому? Реакция?
11. Опиши кейс, когда твой mentee не справлялся. Что предпринял?
12. Расскажи о провалившемся проекте. Что вынес?
13. Опиши конфликт в команде. Как разрулил?
14. Как ты доносил необходимость рефакторинга до PM/business?
15. Что ты сделал, чтобы повысить уровень junior за 3 месяца?
16. Какой code review был самым полезным для тебя как автора?
17. Как принимаешь решение между two-pizza standups vs detailed design reviews?
18. Что ты бы изменил в текущем процессе code review команды?
19. Как балансируешь “хочу всё разобрать на ревью” vs “PR должен мерджиться сегодня”?
20. Расскажи о design doc, который ты написал. Какое было ключевое решение?

---

6. Practice

1. Возьми последний свой PR. Сделай self-review с conventional comments к каждому файлу.
2. Напиши design doc на 1 страницу для какой-то фичи (по шаблону выше).
3. Проведи pair programming session с младшим коллегой; зафиксируй, что узнал ты сам.
4. Запиши 5 SBI feedback событий за неделю (можно про себя).
5. Поставь 1:1 с менти на 30 min; structure: GROW.
6. Возьми чужой open-source PR и проведи review: какие комменты ты бы дал?
7. Перепиши свою недавнюю задачу через PR/FAQ (как Amazon).
8. Создай internal RFC repo (если нет) с README и шаблоном.
9. Проведи async design review (твоему дизайну) с 3 коллегами; собери feedback за 48h.
10. Для каждого junior’а в команде — определи “next-level skill” и план на 1 месяц.

---

7. Источники

1. Google Engineering Practices: https://google.github.io/eng-practices/
2. “The Manager’s Path” — Camille Fournier
3. “Staff Engineer” — Will Larson
4. “An Elegant Puzzle” — Will Larson
5. “Radical Candor” — Kim Scott
6. “The Coaching Habit” — Michael Bungay Stanier
7. “Death by Meeting” — Patrick Lencioni
8. Conventional Comments: https://conventionalcomments.org
9. SmartBear “Best Kept Secrets of Peer Code Review” (2008)
10. Stripe Engineering Blog — RFCs
11. Amazon PR/FAQ approach (Working Backwards)
12. Bridgewater Principles (Ray Dalio)
13. Camille Fournier blog (skamille)
14. Lara Hogan “Resilient Management”
15. “The Pragmatic Programmer” 20th ed.
16. Phabricator (deprecated, but historic)
17. Gerrit Code Review
18. GitHub PR best practices
19. “How Google Tests Software” — Whittaker
20. Patrick Kua — “The Retrospective Handbook”