11.5 Поведенческое интервью и рассказ о своём опыте

Зачем это аналитику

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

Готовность к модулю

Модуль опирается на темы ниже. Если какая-то из них незнакома или её вопросы для самопроверки даются с трудом, начните с неё.

11.1 Стейкхолдеры

Что понять

Что проверяют поведенческие вопросы: ответственность, влияние, работа с неопределённостью, конфликты, рост, масштаб решений.
Метод STAR (ситуация, задача, действия, результат) и расширение STAR-L с выводом.
Фокус на «я», а не «мы»: что сделали именно вы; результат в цифрах, где возможно.
Банк историй: 10–12 историй, каждая закрывает несколько типовых вопросов.
Типовые вопросы: самое сложное решение, конфликт, ошибка и её последствия, несогласие с руководителем, влияние без полномочий, провальный проект, чем гордитесь.
Рассказ о проекте: контекст, ваша роль, архитектура на одной схеме, ключевые решения и компромиссы, результаты, что бы сделали иначе.
Вопросы работодателю: о команде, архитектурных процессах, ожиданиях от роли.
Как говорить о фрилансе и нескольких параллельных проектах как о преимуществе.

Урок

Что на самом деле проверяют поведенческие вопросы

Поведенческое интервью (behavioral interview) опирается на простую идею: лучший предсказатель того, как человек поведёт себя в будущем, — то, как он вёл себя в похожих ситуациях в прошлом. Поэтому вопросы звучат как «расскажите о случае, когда…», а не «что бы вы сделали, если…». Гипотетический ответ показывает, что кандидат знает, как правильно; история показывает, что он так делал.

За типовыми вопросами стоит ограниченный набор качеств, которые интервьюер отмечает в своей форме оценки:

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

Полезно смотреть на каждый вопрос через этот список: не «что спросили», а «какое качество проверяют». Вопрос «расскажите о провальном проекте» проверяет не то, был ли у вас провал, а рефлексию и ответственность. История, в которой виноваты все, кроме рассказчика, проваливает вопрос независимо от сюжета.

STAR и STAR-L

STAR — структура ответа из четырёх частей:

S — ситуация (situation): контекст, достаточный для понимания. Домен, масштаб, что было не так. Две-три фразы.
T — задача (task): что именно требовалось от вас и почему это было трудно. Здесь важна ваша роль и ограничения.
A — действия (actions): что сделали вы лично, в каком порядке и почему именно так. Это основная часть — около половины времени ответа.
R — результат (result): чем закончилось, в измеримых терминах, если возможно.

Расширение STAR-L добавляет L — вывод (learning): что вы вынесли, что сделали бы иначе, как это повлияло на вашу дальнейшую практику. Для senior-уровня вывод почти обязателен: он показывает рефлексию и отличает опыт от стажа.

Оптимальная длина истории — две-три минуты. Короче — не хватает деталей для оценки; длиннее — интервьюер теряет нить и не успевает задать уточняющие вопросы, а именно на них проверяется правдивость и глубина.

Частая ошибка пропорций: минута на ситуацию, тридцать секунд на действия, «ну и в итоге всё заработало». Интервьюеру ситуация интересна только как фон; оценивает он действия и мышление за ними.

«Я», а не «мы»

Командная культура приучает говорить «мы». На поведенческом интервью это вредит: интервьюер не может отделить ваш вклад от вклада команды и оценивает вас по минимуму. Если в истории звучит «мы решили», следующий вопрос будет «а что сделали лично вы?» — и хорошо, если он прозвучит; иногда интервьюер просто ставит низкую оценку.

Правило: «мы» — для контекста и общего результата, «я» — для действий и решений. «Команда из пяти разработчиков делала интеграцию. Я предложил…», «Я настоял на…», «Я подготовил сравнение трёх вариантов».

Это не значит присваивать чужое. Честная формулировка: «Идею предложил ведущий разработчик; моя часть была в том, чтобы проверить её на реальных данных и убедить владельца продукта». Такая точность звучит сильнее, чем размытое «мы всё сделали».

Результат в цифрах — там, где он есть: сократилось время закрытия дня с шести часов до сорока минут, доля ручных корректировок заказов упала с трети до десятой части, количество обращений в поддержку по теме уменьшилось вдвое. Если точных цифр нет, допустимы порядки и качественные результаты с источником: «по оценке операционного блока, ручная сверка перестала быть нужна». Выдуманные цифры опасны: на уточняющем вопросе «как вы это измеряли» они разваливаются.

Полностью разобранный пример истории

Ниже — образец формы, а не история читателя. Сюжет и цифры условные; он показывает, как выглядит история по STAR-L, с какой детальностью и пропорциями. Свою историю нужно строить на своём опыте и своих фактах.

Вопрос: «Расскажите о сложном архитектурном решении, которое вы принимали».

Ситуация. Интернет-магазин среднего размера, несколько складов. Сервис заказов при оформлении синхронно вызывал складскую систему, чтобы зарезервировать товар. Во время распродаж складская система отвечала медленно, заказы падали по тайм-ауту, часть резервов при этом всё-таки создавалась, и остатки расходились. После каждой крупной акции операционисты неделю вручную сверяли резервы.

Задача. Я был ведущим аналитиком и отвечал за интеграционную архитектуру между заказами и складом. До следующей крупной распродажи оставалось около трёх месяцев. Нужно было, чтобы оформление заказа не зависело от доступности склада и чтобы резервы не расходились. Сложность была в том, что команда склада не могла менять свою систему в этот срок, а ведущий разработчик сервиса заказов предлагал просто увеличить тайм-ауты и добавить повторы.

Действия.

Я разобрал логи двух последних распродаж и показал, что повторы без идемпотентности как раз и создают двойные резервы: запрос доходил до склада, ответ терялся, повтор создавал второй резерв. Увеличение тайм-аутов уменьшало падения, но не расхождения.
Я подготовил сравнение трёх вариантов: повторы с ключом идемпотентности на стороне склада; асинхронная резервация через очередь с подтверждением; резервирование в собственном кэше остатков сервиса заказов с последующей синхронизацией. Для каждого расписал, какие изменения нужны у склада, как ведёт себя система при недоступности, какой опыт получает покупатель.
Выяснилось, что складская система уже умеет принимать внешний идентификатор операции, хотя эта возможность не использовалась. Это делало возможным асинхронный вариант без доработки склада. Я проверил это на тестовом стенде вместе с разработчиком складской команды.
Предложил решение: заказ создаётся в статусе «ожидает резерва», событие пишется в таблицу исходящих сообщений (outbox) в той же транзакции, отдельный обработчик отправляет запрос на склад с идентификатором заказа как ключом идемпотентности. Покупатель видит подтверждение сразу, а при невозможности резерва получает уведомление в течение нескольких минут.
Ведущий разработчик был против: больше движущихся частей, новый статус влияет на интерфейс и поддержку. Я не стал продавливать решение через руководителя. Предложил встречу с владельцем продукта и руководителем поддержки, где показал, сколько заказов в час в пике реально не получат резерв — по данным прошлых акций это была доля процента. Владелец продукта согласился на модель «подтверждаем сразу, в редком случае извиняемся».
Написал ADR с рассмотренными вариантами и описал сценарии для тестирования, включая недоступность склада на 30 минут в пике.

Результат. Решение внедрили за шесть недель. На следующей распродаже заказы не падали из-за склада; расхождения резервов, по данным сверки, были единичными и объяснялись ручными операциями на складе, а не интеграцией. Ручная сверка после акции сократилась с недели до одного дня.

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

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

Банк историй

Готовить ответ на каждый возможный вопрос невозможно. Работает банк из 10–12 историй, каждая из которых покрывает несколько типовых вопросов. На интервью задача — не придумать историю, а выбрать подходящую из банка и подать её с нужного ракурса.

Критерии отбора историй:

Разнообразие качеств: решения, конфликты, ошибки, влияние, работа с неопределённостью.
Разнообразие доменов и масштабов: не все истории из одного проекта; есть истории уровня системы и уровня нескольких команд.
Свежесть: большая часть — за последние три-пять лет. Истории десятилетней давности вызывают вопрос, что вы делали с тех пор.
Ваша роль значима: вы принимали решение или существенно на него влияли.
Хотя бы две истории о неудаче — настоящей, с последствиями.

Для каждой истории стоит записать: одну фразу-заголовок, STAR-L тезисами, цифры и откуда они, какие качества она показывает, какие уточняющие вопросы вероятны и ответы на них. Заучивать текст не нужно — нужно помнить опорные точки.

Таблица соответствия вопросов и историй

Ниже — пример того, как устроить карту банка. Названия историй условные: вместо них подставляются ваши. Отметка показывает, какой вопрос история может закрыть.

Типовой вопрос	Проверяет	Спорное архитектурное решение	Конфликт со смежной командой	Собственная ошибка в постановке	Проект, который пошёл не по плану	Влияние на заказчика без полномочий	Работа в полной неопределённости
Самое сложное решение	Масштаб, компромиссы	да					да
Конфликт в команде	Сотрудничество		да			да
Ошибка и её последствия	Рефлексия, ответственность			да	да
Несогласие с руководителем	Смелость, аргументация	да				да
Влияние без полномочий	Влияние	да	да			да
Провальный проект	Ответственность				да		да
Чем гордитесь	Масштаб, результат	да					да
Решение при неполных данных	Неопределённость						да

Если какой-то вопрос закрыт только одной историей, это слабое место: на интервью могут спросить два вопроса одного типа подряд. Если история закрывает пять вопросов — это ваша основная история, её стоит отработать особенно тщательно.

Банк удобно раскладывать по доменам, в которых есть опыт: например, отдельные истории из проектов прогнозирования и автопополнения, из ДБО, из модернизации легаси. Разные домены показывают широту и дают интервьюеру выбор, что копать глубже.

Типовые вопросы и на что обратить внимание

Самое сложное решение. Сложность должна быть в компромиссе, а не в объёме работы. Назовите альтернативы и почему отказались от них.
Конфликт. Покажите, что поняли интересы другой стороны. Хороший конец — решение и сохранённые рабочие отношения, а не «я оказался прав».
Ошибка. Настоящая ошибка, ваша, с последствиями. Не «я слишком много работаю». Структура: что сделал не так, как обнаружилось, как исправил, что изменил в своей практике.
Несогласие с руководителем. Ценится несогласие, высказанное аргументированно и вовремя, и готовность исполнить решение, если оно принято иначе — «не согласен, но делаю» (disagree and commit).
Влияние без полномочий. Данные, прототип, союзники, правильный момент, формулировка в терминах интересов собеседника.
Провальный проект. Ваша доля ответственности и что было в вашей зоне влияния, без перекладывания вины.
Чем гордитесь. Результат, важный для бизнеса, и ваша роль в нём. Хорошо, если гордость связана с решением, а не с количеством переработок.

Рассказ о проекте

Отдельный жанр — «расскажите о проекте, которым занимаетесь». Для архитектора это центральная часть интервью, и её стоит отрепетировать на пять минут с одной схемой.

Структура:

Контекст: бизнес-задача, масштаб в понятных единицах (магазины, позиции, платежи в день, пользователи), почему проект важен. Полминуты.
Ваша роль: за что отвечали лично, с кем работали, кому подчинялись.
Архитектура на одной схеме: основные компоненты, внешние системы, потоки данных. Схема уровня контекста или контейнеров, не больше десяти блоков.
Ключевые решения и компромиссы: два-три решения, альтернативы, почему выбрали именно это. Здесь проверяется архитектурное мышление.
Результаты: что изменилось для бизнеса, с цифрами.
Что сделали бы иначе: честно, с пониманием причин.

Последний пункт многие опускают, а он один из самых информативных. Ответ «ничего» воспринимается как отсутствие рефлексии.

Схему лучше иметь готовой: картинка на экране при удалённом интервью или быстрый набросок на доске. Нарисованная заранее схема экономит время и показывает умение объяснять систему.

Фриланс и параллельные проекты

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

Этот опыт можно подать как преимущество, если говорить о конкретных навыках:

Широта: разные домены и стеки, сравнение подходов разных компаний, перенос удачных решений между проектами.
Быстрый вход: умение за недели разобраться в чужом домене и легаси, выстроить отношения со стейкхолдерами.
Самоорганизация и приоритизация: работа на нескольких проектах требует жёсткого планирования и прозрачной коммуникации о загрузке.
Ответственность за результат: контрактора оценивают по результату, а не по присутствию.

Ответ на вопрос о переходе в штат должен быть искренним и ориентированным вперёд: хочется глубины в одном продукте, длинного цикла, чтобы видеть последствия своих решений, роста в сторону архитектуры в конкретной организации. Звучит плохо ответ, построенный только на бегстве от минусов фриланса. Если вы рассматриваете и контрактный формат — это тоже можно сказать прямо, объяснив, какой формат работы вам нужен.

Опасения стоит снимать заранее: упомянуть длинные проекты в своей практике, случаи, когда вы оставались на проекте на годы, работу в составе постоянной команды заказчика.

Вопросы работодателю

В конце интервью вопросы кандидата — тоже часть оценки. Они показывают, что вам важно и насколько вы понимаете роль. Кроме того, это ваш единственный шанс узнать, куда вы идёте.

Хорошие вопросы для роли senior-аналитика или архитектора:

О роли: какую проблему должен решить человек на этой позиции в первые полгода? Как будет выглядеть успех через год?
Об архитектурных процессах: как принимаются архитектурные решения, кто их утверждает, ведутся ли ADR? Есть ли архитектурный комитет и насколько он влиятелен?
О команде: с кем аналитик работает каждый день, сколько команд на одного архитектора, как распределены роли между аналитиком, архитектором и техлидом?
О состоянии системы: какая часть работы — развитие, какая — поддержка и легаси? Где сейчас главные технические боли?
О процессе: как устроена постановка задач, как требования доходят до разработки, кто владеет документацией?

Плохие вопросы — те, ответ на которые есть на сайте компании, и вопросы только о бонусах на техническом этапе.

Типичные ошибки

Рассказывать «мы» вместо «я» — интервьюер не может оценить ваш вклад.
Тратить большую часть времени на ситуацию и почти не говорить о действиях и решениях.
Выбирать для вопроса об ошибке фальшивую ошибку или историю, где виноваты другие.
Приходить без подготовленного банка историй и импровизировать — даже сильный опыт звучит расплывчато.
Называть цифры, которые не можете объяснить на уточняющем вопросе.
Рассказывать о проекте без схемы и без компромиссов — получается пересказ ТЗ, а не архитектурное мышление.
Оправдываться за фриланс вместо того, чтобы показать, какие навыки он дал.

Как говорить об этом на собеседовании

Уровень senior в поведенческой части виден по трём признакам: масштаб историй (решения, влияющие на несколько систем или команд), зрелость в конфликтах (понимание интересов другой стороны, готовность исполнить решение, с которым не согласен) и рефлексия (конкретные выводы, изменившие вашу практику). Каждая история должна заканчиваться выводом, а не только результатом.

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

Коротко

Поведенческие вопросы проверяют ответственность, влияние, работу с неопределённостью, конфликты, рефлексию и масштаб.
STAR-L: ситуация, задача, действия, результат, вывод; половина времени — на действия.
Говорите «я» о своих решениях и действиях; результат — в цифрах, которые можете объяснить.
Банк из 10–12 историй с картой «вопрос — история» заменяет импровизацию.
Рассказ о проекте: контекст, роль, схема, решения с компромиссами, результаты, что сделали бы иначе.
Фриланс и параллельные проекты подаются через навыки: широта, быстрый вход, самоорганизация, ответственность за результат.
Вопросы работодателю — о роли, архитектурных процессах, команде и состоянии системы.

Читать дальше

Gayle Laakmann McDowell, Cracking the PM Interview — главы о поведенческих вопросах (подход применим к архитекторам).
Руководства крупных компаний по поведенческим интервью (например, принципы лидерства Amazon) как источник типовых вопросов.

На system-design.space:

Практика

Составить банк из 12 историй по STAR из своего опыта (ДБО, автопополнение, модернизация легаси, прогнозирование спроса и другие) с таблицей: какие вопросы закрывает каждая история.
Подготовить рассказ о двух ключевых проектах на 5 минут каждый со схемой на одном слайде.
Провести два пробных поведенческих интервью: с коллегой или с Claude в роли интервьюера, который задаёт уточняющие вопросы «а что сделали именно вы?».

Вопросы для самопроверки

Расскажите о самом сложном архитектурном решении, которое вы принимали.
Расскажите о конфликте в команде и о том, как вы его разрешили.
Расскажите об ошибке, которую вы совершили, и что вы из неё вынесли.
Как вы повлияли на решение, над которым у вас не было полномочий?
Почему вы хотите перейти из фриланса в штат (или остаться на контракте)?
Какие вопросы вы зададите работодателю в конце интервью?