Модуль: Behavioral · Уровень: Senior

TL;DR#

• Senior лидирует без формальной власти: через техническую репутацию, ясность аргументации и помощь другим, а не через приказы.
• Менторство — это не «давать ответы», а поднимать самостоятельность: задавать вопросы, давать рамку, отпускать ответственность.
• Code review — главный масштабируемый инструмент влияния. Тон, фокус на важном и обучающие комментарии важнее, чем количество найденных проблем.
• Архитектурные решения senior принимает с обоснованием и обратимостью: ADR, прототип, понятный trade-off, путь отката.
• Техническое влияние измеряется не «я был прав», а «решение приняли и оно сработало», и тем, что другие выросли рядом с тобой.

Теория / Подход#

Лидерство без формальной власти#

На senior у тебя обычно нет людей в подчинении, но есть ожидание, что ты двигаешь команду. Источники влияния:

• Компетентность — тебе доверяют, потому что твои прошлые решения сработали.
• Ясность — ты умеешь объяснить сложное просто и предложить конкретику, а не критику.
• Надёжность — ты доводишь до конца и не подводишь по обещаниям.
• Щедрость — ты помогаешь, делишься контекстом, не копишь знания.

Формулировка для интервью:

«У меня не было прямых подчинённых, но я был техническим owner’ом платёжного домена. Влияние строил так: когда предлагал изменение, приходил не с “надо переписать”, а с прототипом, бенчмарком и одностраничным ADR с альтернативами. Люди соглашались, потому что видели обоснование, а не моё мнение.»

Менторство джунов и middle#

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

Рабочая модель — постепенная передача ответственности:

1. Я делаю, ты смотришь — показываешь подход на реальной задаче, проговаривая ход мысли.
2. Мы делаем вместе — паринг, человек ведёт, ты подстраховываешь.
3. Ты делаешь, я ревьюю — отдаёшь задачу целиком, остаёшься на подхвате.
4. Ты делаешь сам — выходишь из цикла.

Техники:

• Сократический метод. Вместо «здесь нужен mutex» — «что будет, если две горутины зайдут сюда одновременно?». Человек находит сам и запоминает.
• Давать задачи на вырост. Чуть сложнее текущего уровня, с подстраховкой. Зона комфорта роста не даёт.
• Нормализовать незнание. «Я тоже не помню сигнатуру, гуглю каждый раз» снимает страх спрашивать.
• Обратная связь регулярно и конкретно. Не «ты молодец», а «твой PR был хорошо разбит на коммиты, это сильно упростило ревью».

Формулировка:

«Менторил джуна полгода. В начале он приходил с вопросом “как сделать X”, я отвечал вопросом “а какие у тебя есть варианты и какой минус у каждого?”. Сначала это его фрустрировало, но через пару месяцев он стал приходить уже с готовыми вариантами и обоснованием. Это и было целью — не чтобы он знал ответы, а чтобы умел их находить. К концу он вёл свою фичу от дизайна до прода самостоятельно.»

Культура code review#

Code review для senior — это не «гейткипинг», а:

• Обучение — комментарии учат всю команду, не только автора.
• Распространение контекста — ревью держит знание о коде неэксклюзивным.
• Подъём планки качества — через примеры, а не через регламенты.

Принципы здорового ревью:

• Разделяй уровни замечаний. Помечай: blocking (надо исправить), suggestion (на усмотрение), nit (мелочь, можно игнорить), question (хочу понять). Это снимает напряжение «всё подряд требуют».
• Критикуй код, не человека. «Этот цикл аллоцирует на каждой итерации» вместо «ты плохо написал».
• Объясняй почему. Не «вынеси в функцию», а «вынесем — переиспользуем в хендлере экспорта и упростим тест».
• Хвали хорошее. Положительный комментарий — тоже обучение и поддержка.
• Не блокируй на вкусовщине. Стиль решает линтер (gofumpt, golangci-lint), а не ревьюер. Это экономит конфликты.
• Знай, когда отпустить. Идеальный код, который не выходит в прод, хуже хорошего, который выходит. Не превращай ревью в бесконечный пинг-понг.

В Go-контексте полезные обучающие темы для ревью: обработка ошибок с %w и контекстом, отмена через context, утечки горутин, защита разделяемого состояния, корректность интерфейсов на границах пакетов, отсутствие лишних аллокаций в горячем пути.

Техническое влияние и принятие архитектурных решений#

Senior двигает решения процессом, который масштабируется и переживает спор:

• RFC / ADR. Документ: проблема, контекст, рассмотренные варианты, выбор, последствия, trade-off’ы. Письменный артефакт превращает спор мнений в обсуждение фактов и остаётся как память команды.
• Прототип вместо спора. Когда два решения «звучат правильно» — спайк за день закрывает вопрос данными.
• Обратимость. Предпочитай решения, которые можно откатить (feature flag, canary, постепенная миграция). «Решение в одну сторону» (one-way door) требует больше согласования, чем обратимое.
• Привлекай людей рано. Решение, в которое команда вложилась на этапе дизайна, не саботируется на этапе внедрения. Соавторство > навязывание.

Формулировка:

«Мы спорили, брать ли gRPC или оставить REST для внутренних сервисов. Вместо недели дебатов я написал ADR с тремя осями сравнения — latency, удобство контрактов, стоимость миграции — и сделал спайк на одном сервисе. Цифры показали выигрыш по latency, но реальной болью оказалась не она, а отсутствие контрактов. Команда согласилась на gRPC именно из-за этого аргумента, который без прототипа мы бы не увидели.»

Антипаттерны#

• Лидерство через авторитет. «Делайте так, потому что я senior» убивает доверие и инициативу.
• Менторство-диктат. Решать за подопечного и переписывать его код молча — он не растёт и теряет мотивацию.
• Ревью как самоутверждение. Демонстрация ума, разнос на людях, блокировка на вкусовщине.
• Bottleneck-герой. Всё держится на тебе, ты ревьюишь всё, без тебя команда стоит. Это анти-масштаб и риск для проекта.
• Knowledge hoarding. Скрывать контекст, чтобы быть незаменимым. Senior, наоборот, делает себя заменимым в рутине.
• Архитектура «в голове». Решения без документа — спор пересобирается каждый раз, новые люди не понимают «почему так».
• One-way doors без обсуждения. Необратимое технологическое решение, принятое в одиночку.
• Менторство только «приятным». Избегать неудобной обратной связи — медвежья услуга для роста человека.

Вопросы на собеседовании#

В: Расскажи, как ты менторил кого-то. Какой был результат? О: Конкретный человек, начальная и конечная точка его роста, твои техники (сократический метод, передача ответственности), измеримый итог (стал вести фичи сам, прошёл на middle). Сигнал — ты растишь самостоятельность, а не зависимость от себя.

В: Как ты влияешь на технические решения, не имея формальной власти? О: Через артефакты (ADR/RFC), прототипы и вовлечение людей рано. Приведи кейс, где решение приняли благодаря твоему обоснованию, а не должности. Подчеркни, что иногда твой вариант не побеждал — и это нормально.

В: Опиши твой подход к code review. О: Разделение уровней замечаний, фокус на важном, обучающий тон, делегирование стиля линтеру, знание когда отпустить. Покажи, что видишь ревью как инструмент роста команды и распространения контекста, а не как контроль.

В: Был случай, когда твоё техническое предложение отвергли? Что ты сделал? О: Покажи зрелость: отстоял аргументами, но принял коллективное решение (disagree and commit), и — сильный ход — потом признал, если решение команды оказалось верным. Это снимает образ «упрямого гения».

В: Как ты передаёшь знания в команде? О: ADR, парное программирование, обучающие комментарии в ревью, внутренние доклады/доки, отказ от bus factor = 1. Сигнал — ты осознанно борешься с собственной незаменимостью.

В: Как ты понимаешь, что подопечный готов к более сложным задачам? О: По тому, что он приходит с вариантами а не вопросами, сам видит риски, задаёт правильные вопросы. Покажи, что осознанно повышаешь сложность с подстраховкой, а не бросаешь в воду.

В: Расскажи о трудном разговоре с менее опытным коллегой (фидбэк). О: Конкретная ситуация (качество кода/пропуск дедлайнов), как ты дал фидбэк по фактам и наедине, как сфокусировался на поведении а не личности, какой был результат. Избегай историй, где фидбэк ничего не изменил и ты сдался.

На что копают на senior+#

• Растишь ли людей реально. «Где этот человек сейчас?» — проверяют долгосрочный эффект менторства, а не разовую помощь.
• Не bottleneck ли ты. «Что происходит с командой, когда тебя нет?» Здоровый ответ — «работает без меня, я убрал зависимость от себя».
• Влияние vs упрямство. Различают, умеешь ли ты убеждать данными и при этом отступать, или просто продавливаешь.
• Качество архитектурных решений во времени. «Какое твоё решение не пережило год и почему?» Проверяют рефлексию и масштаб мышления.
• Тон и эмпатия в ревью. На senior+ ищут того, кто поднимает планку без выгорания команды.
• Баланс между качеством и поставкой. Перфекционизм, мешающий релизам, — анти-сигнал. Ищут прагматика.
• Способность делать необратимые решения осознанно. Понимаешь ли разницу между one-way и two-way door и согласуешь ли первое.