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

TL;DR#

• Поведенческое интервью проверяет, как ты реально действовал в прошлом, а не как «считаешь правильным». Прошлое поведение — лучший предиктор будущего.
• Используй метод STAR: Situation → Task → Result, через Action. 70% времени ответа — на Action и Result.
• На senior уровне важны не сами факты, а демонстрация владения (ownership), влияния (impact) и рефлексии: что ты решил, почему, чему научился, что измерил.
• Готовь заранее 6–8 «историй» из опыта и переиспользуй их под разные вопросы. Одна сильная история закрывает 3–4 темы.
• Цифры и trade-off’ы продают senior’а. «Снизили p99 latency с 1.2s до 180ms» сильнее, чем «улучшили производительность».

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

Что на самом деле оценивают#

Поведенческая секция — это не «проверка на адекватность». Интервьюер собирает сигналы по компетенциям, которые у компании прописаны в гайде. Для senior это обычно:

• Ownership — берёшь ли ответственность за результат, а не за «свой кусок».
• Impact / scope — масштаб влияния: на свою задачу, на команду, на организацию.
• Collaboration & influence — умеешь ли двигать решения без формальной власти.
• Dealing with ambiguity — действуешь ли в условиях неопределённости и неполных данных.
• Self-awareness — видишь ли свои ошибки, рос ли ты на них.

Senior отличается от middle тем, что в его историях есть второй порядок мышления: не «я сделал фичу», а «я понял, что фича не нужна в таком виде, и предложил альтернативу, которая сэкономила квартал работы».

Метод STAR (и его расширение STAR-L)#

• Situation (10–15%) — контекст коротко. Где, какая система, какой масштаб, какая проблема. Без воды.
• Task (10%) — что именно было твоей задачей/ответственностью. Чётко вычлени своё «я» из «мы».
• Action (50%) — что ты конкретно делал. Это ядро. Решения, альтернативы, почему выбрал так, как координировал людей.
• Result (20%) — измеримый итог. Цифры, бизнес-эффект, что изменилось.
• Learning (5–10%) — что вынес. Особенно критично для вопросов про факапы.

Частая ошибка: кандидат тратит 80% времени на Situation («у нас был такой сервис, он работал так, и ещё был другой сервис…») и не доходит до Action. Интервьюер слышит «контекст» вместо «тебя».

Как готовить банк историй#

Составь таблицу: 6–8 ситуаций × теги тем. Пример тегов: сложная техническая задача, конфликт, факап/инцидент, лидерство, влияние на решение, дедлайн/давление, обратная связь, неоднозначность.

Каждая история должна:

1. Быть про тебя (не «команда сделала»).
2. Содержать конкретное решение и trade-off.
3. Иметь измеримый результат.
4. Допускать рефлексию («сейчас я бы сделал иначе…»).

Хорошо, если 1–2 истории относятся к недавнему опыту (последний год) — это снимает подозрение, что ты живёшь прошлыми заслугами.

Формулировки: как звучит senior#

Сравни:

• ❌ «Мы переписали сервис, стало быстрее.»
• ✅ «Я заметил, что p99 в платёжном сервисе деградировал до 1.2s под нагрузкой. Снял профиль pprof, нашёл, что аллокации в горячем пути на сериализации съедали CPU. Я предложить заменить encoding/json на ручной маршалинг для двух критичных структур и ввести sync.Pool для буферов. До раскатки прогнал бенчмарки и нагрузочное в staging. p99 упал до 180ms, что позволило отложить горизонтальное масштабирование на квартал — сэкономили примерно $4k/мес на инфраструктуре.»

Второй ответ показывает: диагностику, владение инструментами Go, осознание trade-off (ручной маршалинг = поддержка vs скорость), измерение, бизнес-эффект.

Истории про факап (самое важное на senior)#

Senior без факапов не существует — отсутствие факапа в ответе читается как «не брал на себя ничего серьёзного» или «не признаёт ошибок».

Структура хорошего ответа про факап:

1. Признай ошибку прямо, без размывания вины на других.
2. Объясни механизм — почему так вышло (системно, не «я был невнимателен»).
3. Что сделал немедленно — митигация, коммуникация, ownership инцидента.
4. Что изменил системно, чтобы это не повторилось (постмортем, алерты, процесс).
5. Чему научился — желательно изменение в подходе, а не «стал внимательнее».

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

«Я раскатил миграцию, которая добавляла индекс на большую таблицу без CONCURRENTLY в Postgres. Она взяла блокировку и положила запись в прод на 4 минуты в пиковое время. Я сразу откатил, написал в инцидент-канал, что причина во мне, и взял координацию постмортема. Корневая причина была не только в моей невнимательности — у нас не было ревью миграций и не было линтера на опасные DDL. Я добавил в CI проверку (squawk) и чек-лист ревью для миграций. С тех пор таких инцидентов не было. Главный вывод: если ошибка возможна, виноват не человек, а процесс, который её допускает.»

Истории про конфликт#

Подробно в conflicts.md. Здесь главное: показывай, что конфликт ты решал через интересы и данные, а не через «продавил» или «уступил, чтобы не ссориться». Финал — disagree and commit или найденный третий вариант.

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

• «Мы» вместо «я». Невозможно оценить твой вклад. Чётко: «команда сделала X, моя часть — Y».
• Гипотетика. «Я бы поступил так…» — это не поведенческий ответ. Нужен реальный случай. Если случая нет — честно скажи и приведи ближайший аналог.
• Идеальные истории без трудностей. «Всё прошло гладко» = не было сложности = не senior-масштаб.
• Факап, где виноваты все, кроме тебя. Перекладывание вины — мгновенный red flag.
• Нет цифр. «Стало лучше» без метрик. Если точных цифр нет — дай порядок («примерно вдвое», «с минут до секунд»).
• Растекание по Situation. 5 минут контекста, 30 секунд действия.
• Заученность. Слишком гладкий, отрепетированный монолог без живых деталей вызывает недоверие. Знай канву, но говори естественно.
• Технический шум без сути. Перечисление технологий вместо объяснения решений и trade-off’ов.

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

В: Расскажи о самой технически сложной задаче, которую ты решал. О: Выбери задачу с реальной неоднозначностью (не «сложную» в смысле объёма). Структура: в чём была сложность (распределённость, неочевидный баг, конфликт требований), какие варианты рассматривал и почему отбросил, что выбрал, как валидировал, результат в цифрах. Senior-сигнал — рассказ про trade-off’ы и про то, как ты управлял неопределённостью, а не только финальное решение.

В: Расскажи о своём самом крупном профессиональном провале. О: Бери настоящий факап с последствиями. Признай вину прямо, покажи немедленную митигацию и системное исправление (постмортем, процесс), закончи конкретным выводом. Избегай «фейк-факапов» вроде «я слишком много работал».

В: Опиши ситуацию, когда тебе пришлось принять решение с неполной информацией. О: Покажи, как ты ограничивал риск при неопределённости: выделил, что известно/неизвестно, какие допущения сделал явными, как сделал решение обратимым (feature flag, canary), как договорился пересмотреть при новых данных. Это прямой сигнал на «dealing with ambiguity».

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

В: Расскажи, как ты получал жёсткую обратную связь. Что сделал? О: Сигнал — self-awareness. Опиши конкретный фидбэк (не размытый), первую эмоциональную реакцию честно, и как ты её переработал в действие. Покажи измеримое изменение поведения. Избегай «я не согласился, фидбэк был неправильный».

В: Приведи пример, когда ты вышел за рамки своей роли. О: Ownership-вопрос. Покажи, что увидел проблему вне своей зоны (флейки в CI, отсутствие алертов, выгорающий коллега) и взял её, не спрашивая разрешения, потому что это влияло на результат. Подчеркни, что согласовал, где надо, чтобы не выглядеть «героем-одиночкой».

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

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

• Где границы твоего вклада. Будут уточнять: «А что конкретно делал ты?», «Кто принял финальное решение?» — проверяют, не присваиваешь ли чужое.
• Глубина trade-off’ов. «Почему не выбрал альтернативу X? А какой минус у твоего решения?» Senior всегда видит обратную сторону своего выбора.
• Масштаб и долгосрочность. «Как это решение жило через год? Не пришлось ли переделывать?» Проверяют, мыслишь ли ты за горизонт спринта.
• Влияние на людей и процессы, а не только на код. История, где ты изменил подход команды, ценится выше, чем где ты написал классный алгоритм.
• Честность рефлексии. На факапе будут давить: «А что бы ты сделал иначе сейчас?» Заготовленный «идеальный» вывод хуже, чем живой и самокритичный.
• Консистентность. Сопоставляют твои истории между собой и с резюме. Противоречия (то «я лид», то «я только кодил») рушат доверие.