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

TL;DR#

• Senior не «избегает конфликтов» — он переводит их из эмоциональной плоскости в плоскость данных, рисков и trade-off’ов.
• Технические споры решаются критериями, а не громкостью голоса: SLA, стоимость, сроки, поддерживаемость, обратимость решения.
• Disagree and commit — ключевой навык: ты можешь быть против, но после принятия решения исполняешь его как своё и не саботируешь.
• С легаси работаешь инкрементально и с измеримой ценностью, а не «давайте всё перепишем».
• Со стейкхолдерами говоришь на их языке (деньги, риски, сроки, клиент), а не на языке стектрейсов.
• Пушбэк на нереалистичные сроки — это не «нет», а «вот варианты scope/quality/time, выбирайте».

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

Природа конфликта на senior-уровне#

Интервьюер проверяет не «бесконфликтность» (это red flag — значит человек либо избегает ответственности, либо врёт), а зрелость: умеешь ли ты не доводить разногласие до личного, отделять позицию человека от проблемы, и доводить ситуацию до решения, с которым команда может жить.

Базовая модель ответа на любой конфликтный вопрос — STAR + урок:

• Situation — короткий контекст (1-2 предложения).
• Task — в чём была твоя зона ответственности.
• Action — что конкретно ты сделал (не «мы»).
• Result — измеримый итог.
• Урок — что бы сделал иначе / что вынес.

Важно: на senior+ интервьюер слушает прежде всего Action и проверяет, не свалил ли ты вину на других.

Разногласия по техническим решениям#

Принцип: спор должен иметь критерий разрешения. Если два инженера спорят «gRPC vs REST» без критериев — это religious war. Senior сразу спрашивает: «По какому признаку мы поймём, кто прав? Latency? Команда уже знает технологию? Стоимость поддержки?»

Алгоритм:

1. Зафиксировать, что цель у всех общая (надёжный сервис, а не «моя правота»).
2. Выписать варианты и trade-off’ы письменно (мини-RFC / Decision Doc / ADR).
3. Привести данные: бенчмарк, прототип, цифры из прода.
4. Если данные не решают — выбрать обратимое решение (two-way door) и заложить точку пересмотра.
5. Эскалировать к решающему лицу (tech lead / архитектор), если deadlock.

Пример формулировки:

«Мы с коллегой разошлись: он за то, чтобы вынести логику в отдельный микросервис, я считал, что это преждевременно. Вместо спора я предложил критерии: текущая нагрузка, частота релизов этого модуля, размер команды. По цифрам выходило, что выделять рано — связность данных высокая, отдельный деплой даст больше боли, чем пользы. Я набросал короткий decision doc с обоими вариантами и метриками, мы прошлись по нему с тимлидом. Решили оставить монолит, но выделить чёткий пакет-границу, чтобы вынести потом дёшево. Через полгода границы как раз пригодились, когда нагрузка выросла.»

Disagree and commit#

Это не «прогнуться». Это: я честно высказал аргументы, решение приняли против меня, и теперь я исполняю его добросовестно и не хожу по углам с «я же говорил». Саботаж принятого решения — главный признак не-senior.

Где проходит красная линия: если решение этическое или критично по безопасности/данным — там не commit, а письменная фиксация несогласия и эскалация. Senior отличает «мне не нравится подход» (commit) от «это приведёт к утечке персональных данных» (escalate).

Пример формулировки:

«Я был против выбранной очереди — считал, что для нашего профиля нагрузки Kafka избыточна. Но команда и тимлид взвесили и решили иначе, аргументы были разумные. Я записал свои опасения в ADR, чтобы при ретро было видно контекст, и дальше вкладывался в решение полностью — написал обвязку, документацию, обучил двоих. В итоге опасения частично подтвердились по стоимости эксплуатации, но мы это спокойно обсудили на ретро без “я же говорил”.»

Работа с легаси#

Антипаттерн — «давайте всё перепишем». Senior знает, что Big Bang rewrite почти всегда проигрывает (теряется знание, зашитое в багфиксах, бизнес встаёт на полгода). Подход:

• Понять, почему код такой — обычно за «уродством» стоят реальные требования и хотфиксы.
• Покрыть тестами / characterization tests перед изменением.
• Strangler Fig — постепенно перенаправлять трафик на новый код, оставляя старый рабочим.
• Привязать рефакторинг к бизнес-ценности — рефакторить то, что часто меняется или часто ломается, а не то, что эстетически не нравится.
• Boy Scout Rule: оставляй модуль чуть чище, чем нашёл, в рамках текущей задачи.

Пример формулировки:

«Достался сервис без тестов, который все боялись трогать. Я не стал предлагать переписать — вместо этого добавил characterization-тесты на ключевые сценарии, чтобы зафиксировать текущее поведение, потом по Strangler перенёс самый горящий кусок (расчёт цены, который чаще всего ломался) за новый интерфейс. Рефакторинг я обосновал не “код плохой”, а тем, что этот модуль давал 40% инцидентов. После этого инциденты по нему упали, и команда перестала бояться релизов.»

Общение со стейкхолдерами#

Главное правило: переводи технику в их валюту. Продакт думает фичами и сроками, бизнес — деньгами и рисками, поддержка — количеством тикетов. «У нас техдолг» им не говорит ничего; «из-за этого участка кода каждый релиз занимает на 2 дня дольше и даёт N инцидентов» — говорит.

Приёмы:

• Начинай с вывода/рекомендации, потом обоснование (пирамида Минто).
• Давай варианты с trade-off’ами, а не один ультиматум.
• Не прячь плохие новости — приноси их рано и с планом.
• Управляй ожиданиями: лучше обещать консервативно и перевыполнить.

Пример формулировки:

«Продакт хотел фичу к дате запуска маркетинга. Я не сказал просто “не успеем”. Я показал: есть полный вариант на 3 недели и есть MVP на 1 неделю без редактирования и с ручной модерацией. Объяснил, что MVP покрывает 80% сценариев запуска, а остальное докатим следом. Он выбрал MVP, маркетинг не сдвинулся, и мы не выгорели.»

Пушбэк на нереалистичные сроки#

Senior никогда не говорит просто «нет» и не молча геройствует, выгорая. Он делает дедлайн разговором о trade-off’ах через треугольник scope / time / quality (resources обычно не масштабируется мгновенно — закон Брукса).

Алгоритм:

1. Уточнить, откуда дата и что за ней стоит (жёсткое внешнее обязательство или «хотелось бы»).
2. Дать честную оценку с разбивкой и допущениями.
3. Предложить варианты: урезать scope, сдвинуть дату, осознанно срезать quality (с явной фиксацией техдолга), фазировать поставку.
4. Подсветить риски молчаливого согласия (что сломается, какой долг накопится).
5. Зафиксировать решение письменно.

Пример формулировки:

«Мне дали 2 недели на то, что честно тянет на 5. Я не стал кивать. Разбил задачу, показал, где основная неопределённость — интеграция со сторонним API без песочницы. Предложил три варианта: выкатить к дате только happy-path и без retry-логики, сдвинуть на неделю ради устойчивости, либо параллельно подключить второго человека на интеграцию. Менеджер выбрал фазирование. Главное — я зафиксировал, что happy-path-версия требует доработки в следующем спринте, чтобы это не забылось как “уже сделано”.»

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

• «У меня не было конфликтов» — звучит как избегание ответственности или неумение в рефлексию.
• Обвинение других — «команда тупила», «менеджер не понимал». Интервьюер сразу ставит минус.
• Геройство в ущерб себе и команде — молча согласиться на нереальный срок и выгореть.
• Религиозные войны без критериев — спор ради правоты, а не результата.
• Big Bang rewrite легаси без тестов и без бизнес-обоснования.
• «Я же говорил» после disagree and commit — саботаж принятого решения.
• Техножаргон со стейкхолдерами — «у нас гонка горутин», когда надо «сервис иногда отдаёт неверные данные под нагрузкой».
• Конфликт переходит на личность — «он всегда так делает» вместо «это решение даёт такие риски».
• Эскалация как первый шаг вместо попытки решить на своём уровне (или наоборот — эскалация слишком поздно, когда уже горит).

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

В: Расскажи о техническом разногласии с коллегой. Как разрешили? О: STAR. Подчеркни: общая цель, перевод спора в критерии, данные/прототип, письменная фиксация, и итог — включая что отношения с коллегой не пострадали. Главное — покажи, что был готов оказаться неправым.

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

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

В: Продакт настаивает на сроке, который нереален. Твои действия? О: Не «нет», а варианты через scope/time/quality. Честная оценка с допущениями, подсветка рисков молчаливого согласия, письменная фиксация выбранного варианта и накопленного долга.

В: Как объяснишь не-техническому стейкхолдеру, зачем нужен месяц на техдолг? О: Переведи в их валюту: скорость релизов, число инцидентов, риск для конкретного клиента/выручки. Дай варианты (всё/частично/ничего) с последствиями каждого. Не моральное «надо», а цифры и риск.

В: Опиши конфликт, который ты разрешил плохо. Что бы сделал иначе? О: Не уходи в «у меня всё всегда хорошо». Возьми реальный кейс, где, например, эскалировал слишком поздно или продавил своё решение силой авторитета. Покажи рефлексию и конкретное изменение в поведении.

В: Член твоей команды постоянно не согласен и тормозит решения. Как поступишь? О: Сначала 1:1 — понять, это техническая позиция или что-то личное/процессное. Дать пространство высказаться, ввести критерии и таймбокс на решение, при deadlock — эскалация с зафиксированными вариантами. Цель — разблокировать команду, не «победить» человека.

В: Тебе дали задачу, которая, по-твоему, вообще не нужна бизнесу. Что делаешь? О: Не молча делать и не молча отказываться. Уточнить цель и метрику успеха задачи у заказчика — часто всплывает контекст, которого не видел. Если после этого всё ещё считаешь её бесполезной — аргументировать с альтернативой, но быть готовым к disagree and commit.

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

• «Я» vs «мы»: senior берёт ответственность за конкретные действия, а не прячется за командой. Но и не приписывает себе всё.
• Перевод на язык бизнеса: умеешь ли ты говорить со стейкхолдерами не стектрейсами, а рисками/деньгами/сроками.
• Обратимость решений: понимаешь ли разницу между one-way и two-way door — для обратимых решений быстро коммититься, для необратимых требовать данных.
• Управление вверх (managing up): пушбэк на сроки и на менеджмент — без агрессии, через варианты и фиксацию.
• Эмоциональная зрелость: отделяешь позицию от человека, не носишь обиды, чинишь отношения после конфликта.
• Системность: после конфликта меняешь процесс (ADR, критерии, ретро), чтобы такое не повторялось, а не только тушишь конкретный пожар.
• Где красная линия: понимаешь, когда disagree-and-commit неуместен (безопасность, данные, этика, legal) и надо эскалировать письменно.