Поведенческое интервью

Интервьюер проверяет, умеете ли вы коротко и по делу рассказать о себе и почему подходите на эту роль. Уложитесь в одну-две минуты: настоящее (роль, стек, чем заняты сейчас), прошлое (как к этому пришли, один результат), будущее (почему следующим шагом должна стать именно эта вакансия). Подстройтесь под вакансию: начните с того, что нужно по описанию; учёбу, хобби и пересказ резюме пропустите Один результат с цифрой: ускоренный холодный старт, снижение доли крашей Красные флаги: пересказ резюме по местам работы, монолог на пять минут, ни слова о том, чего вы хотите дальше Пример Настоящее: «Я бэкенд-разработчик, три года на Go. Работаю в команде платежей: gRPC-сервисы, PostgreSQL, Kafka и дежурства.» Прошлое: «Пришёл из PHP и переписал наш сервис вебхуков на Go, его p99 упал с 400 мс до 80 мс.» Будущее: «Хочу работать с системами под большей нагрузкой, а у вашей платформы как раз такой трафик.»

Интервьюер проверяет мотивацию и то, не уйдёте ли вы от них по той же причине. Назовите одну честную причину как движение к чему-то (задачи сложнее, продукт крупнее, команда сильнее), а затем две конкретные вещи, которые привлекают вас в этой компании. К чему-то, а не от чего-то: «я перерос свои задачи» или «хочу больше масштаба», но никогда «у меня бесполезный руководитель» Конкретно про них: их продукт, стек, статья в блоге или доклад; «отличная компания» не говорит ничего Сокращение или короткий срок работы: скажите прямо одной фразой и переходите дальше Красные флаги: критика своего работодателя, «только ради денег», незнание компании Пример «Наш сервис обрабатывает несколько сотен запросов в секунду, а я хочу узнать, что ломается при нагрузке в сто раз больше. Ваша платформа работает на Go именно в таком масштабе, и откликнулся я после ваших статей о Kafka-консьюмерах.»

Интервьюер проверяет масштаб того, что вы делали, и ваш личный вклад в работу команды. Отвечайте по STAR: ситуация и проблема, ваша задача, ваши действия и их причины, измеримый результат. «Я» для своей части: «мы» только о работе команды; оценивают то, что сделали вы Одно решение подробно: ждите вопроса «почему так, а не X?» Результат в цифрах: crash-free users, время загрузки, конверсия, обращения Красные флаги: технологии без проблемы за ними, архитектура, которую вы не можете объяснить, успех команды, выданный за свой Пример Ситуация: экспорт PDF выполнялся прямо в HTTP-запросе и падал по таймауту у крупных клиентов Задача: я его перепроектировал Действия: хендлер ставит задачу в очередь, воркеры собирают файл, клиент опрашивает статус; задачи идемпотентны, поэтому повтор никогда не создаёт второй отчёт Результат: таймаутов экспорта стало ноль вместо примерно 5%

Интервьюер проверяет, насколько трезво и честно вы себя оцениваете. Назовите две-три сильные стороны, важные для этой роли, каждую с фактом, и одну настоящую слабую сторону, которая не мешает работе, вместе с тем, что вы с ней уже делаете. Сильные стороны с доказательством: факт из работы, а не прилагательные вроде «ответственный» Настоящая слабость: трудно высказываться на больших встречах, привычка поздно просить о помощи, мало опыта в области, которая для роли не главная Что вы с ней делаете: привычка, которая уже работает, чтобы ответ заканчивался прогрессом Красные флаги: «слабых сторон нет», скрытое хвастовство («я перфекционист») Пример Сильная сторона: «Профилирование. Когда что-то тормозит, я начинаю с pprof и трейсов.» Слабая сторона: «Мои первые дизайн-документы были слишком длинными, их не дочитывали. Теперь пишу одну страницу с решением в начале.»

Рекрутер проверяет, вписываетесь ли вы в бюджет и знаете ли свою цену на рынке. Назовите изученную вилку для вашего уровня и рынка, поясните, до или после налогов и в месяц или в год, и добавьте, что итог зависит от задач и всего предложения. Сначала исследование: обзоры зарплат, похожие вакансии, знакомые, которые недавно меняли работу Честная нижняя граница: офферы приходят близко к ней, так что назовите число, которое вас устроит Знайте принятую форму: за рубежом обычно сумма до налогов (gross) в год, в русскоязычных компаниях часто на руки в месяц Спросите их вилку первыми: на этом этапе это нормально, и всё чаще работодатели обязаны называть её заранее Красные флаги: «сколько предложите», цифра с потолка, текущая зарплата, которую вы назвали без вопроса Пример Зарубежная компания: «Для middle Go-разработчика я ориентируюсь на X–Y gross в год. А какая у вас вилка?» Русскоязычный рынок: «Я ориентируюсь на X–Y в месяц на руки. А какая у вас вилка?»

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

Интервьюер проверяет, как вы отлаживаете: как сужаете проблему, какими инструментами пользуетесь и исправляете ли причину, а не симптом. Рассказывайте по STAR и больше всего времени отдайте действиям: гипотезам, тому, как вы их проверяли, и тому, что не даст багу вернуться. Почему было сложно: только на некоторых устройствах, только под нагрузкой, нет стектрейса; скажите это сразу Поиск по шагам: краш-репорты и логи, профайлер, минимальное воспроизведение, git bisect, ложные следы, которые вы отбросили Корневая причина одной фразой: чтобы интервьюер мог уследить за мыслью Профилактика: тест, алерт или правило линтера, добавленные после Красные флаги: банальная опечатка, «не помню», баг, который нашёл коллега, исправление, которое вы не можете объяснить Пример Ситуация: память сервиса росла три дня, пока Kubernetes не убивал его с OOMKilled, и всё повторялось Задача: найти утечку Действия: профиль кучи выглядел нормально, но профиль горутин из pprof показал 200 000 горутин, заблокированных на отправке в канал. Когда запрос падал по таймауту, хендлер возвращался, и результат воркера никто не читал. Я дал каналу буфер на одно значение, чтобы воркер всегда мог завершиться Результат: число горутин перестало расти, а в тестах теперь работает проверка goleak

Интервьюер проверяет ответственность: признаёте ли вы ошибку, быстро ли ограничиваете ущерб и меняете ли процесс, чтобы она не повторилась. Выберите настоящую ошибку с ограниченными последствиями, расскажите по STAR, а последнюю часть отдайте тому, что изменили. Признайте прямо: «я выкатил», а не «так получилось»; не вините QA или ревьюера, который пропустил Сначала ограничьте ущерб: кому и как быстро вы сообщили, откат или хотфикс, сколько пользователей задело Исправьте систему: тест, проверка в CI, правило ревью или алерт; «буду внимательнее» исправлением не считается Красные флаги: «я не ошибаюсь», история, где виноват кто-то другой, катастрофа без выводов, мелкая опечатка, выбранная, чтобы не рисковать Пример «Я запустил CREATE INDEX на таблице заказов в 40 миллионов строк посреди дня. В PostgreSQL это блокирует запись до конца построения, и оформление заказа около шести минут падало с ошибками. Я отменил запрос, написал в канал инцидента и ночью перестроил индекс через CREATE INDEX CONCURRENTLY. После этого мы добавили в CI линтер миграций (squawk), и он не пропускает создание индекса без CONCURRENTLY.»

Интервьюер проверяет, как вы действуете, когда горит продакшен: сначала снизить ущерб, сообщить, найти причину и затем извлечь урок без поиска виноватых. Расскажите по порядку: алерт, первое действие, которое уменьшило ущерб, кому вы сообщили, корневая причина и задачи по итогам постмортема. Снизить ущерб до диагностики: откатить, выключить флаг, добавить реплик, поставить задачу на паузу; корневая причина подождёт час Сообщать по расписанию: канал инцидента и статус каждые 15–30 минут; звать на помощь рано Факты вместо догадок: дашборды, трейсы и логи вокруг времени начала, недавние деплои и изменения конфигурации Постмортем без виноватых: хронология, ущерб, почему случилось, почему не поймали, три-пять задач с ответственными Красные флаги: «я всё починил сам и никому не сказал», постмортем, который называет виноватого, задачи, которые никто не сделал Пример «В 3 часа ночи меня разбудил алерт по p99 у API заказов: рост со 120 мс до 4 с. Дашборды показали, что пул соединений к базе исчерпан, а всплеск совпал с ночной задачей экспорта. Я поставил задачу на паузу, и задержка вернулась в норму за несколько минут. Задача делила пул соединений с API и выполняла запросы без ограничений. По итогам постмортема мы выделили ей отдельный небольшой пул, добавили алерт на время ожидания соединения и перенесли экспорт на реплику для чтения.»

Интервьюер проверяет, умеете ли вы не соглашаться, не портя рабочие отношения. Возьмите настоящее рабочее разногласие, часто техническое или на код-ревью, и покажите, как вы перевели его от мнений к общим критериям, что решили и как работали вместе после. Говорите рано и напрямую: длинную ветку комментариев переведите в короткий созвон или разговор один на один Сначала поймите их позицию: честно перескажите её, прежде чем доказывать свою Сначала критерии, потом решение: цифры, договорённости команды, быстрый прототип; если согласия всё равно нет, решает владелец решения, а вы его принимаете Проиграть нормально: история, где вы приняли чужой подход, показывает зрелость Красные флаги: «у меня не было конфликтов», коллега в роли злодея, сразу к руководителю, победа ценой отношений Пример «Коллега оставлял по тридцать замечаний о стиле в каждом моём PR и держал их по нескольку дней. В разговоре один на один я узнал, что раньше он сильно обжёгся на разнобойном коде. Мы договорились перенести правила стиля в golangci-lint, оставшиеся мелочи помечать как неблокирующие и укладываться с ревью в один рабочий день. После этого его ревью были про дизайн, а не про форматирование.»

Интервьюер проверяет, реалистично ли вы планируете и поднимаете ли риск сразу, как только его видите, а не в день дедлайна. Расскажите, как вы декомпозируете и оцениваете работу, а затем историю, где вы заметили срыв срока заранее, вовремя предупредили и предложили варианты. Декомпозиция: куски от половины дня до двух дней, включая тесты, ревью, QA и релиз, о которых часто забывают Неизвестное отдельно: ограниченный по времени спайк на всё, что вы ещё не делали; называйте диапазон, а не одно число Сравнение с прошлым: сколько на самом деле заняли похожие задачи Если срок срывается: скажите тимлиду или продакту в тот же день, с вариантами: урезать объём, сдвинуть дату, добавить людей; никогда не сидите молча по ночам в надежде успеть Красные флаги: «я всегда успеваю», оценка без декомпозиции, сообщение о срыве в день релиза Пример «Интеграцию с платёжным провайдером я оценил в пять дней. На второй день выяснилось, что их песочница присылает вебхуки без подписи, хотя в документации написано иначе. В тот же день я сказал тимлиду, написал в поддержку провайдера и предложил выпустить за флагом с опросом статуса как запасным вариантом. Мы выпустились в плановую дату на опросе, а через неделю перешли на вебхуки.»

Интервьюер проверяет, думаете ли вы о продукте и умеете ли возражать аргументами, а не молча делать или отказываться. Покажите, что вы спросили о цели, принесли доказательства цены, предложили альтернативу, которая ведёт к той же цели, и приняли итоговое решение. Сначала спросите о цели: требование часто лишь один из путей к ней, и есть путь дешевле Принесите доказательства: запись экрана на реальном устройстве, замер, гайдлайн платформы, оценку каждого варианта Предложите альтернативу: «X к пятнице не успеем, но Y даст большую часть результата» Уважайте решение: когда владелец продукта решил, видя все компромиссы, вы делаете это хорошо Красные флаги: «я делаю, что скажут», отказ без альтернативы, решать вопрос через голову продакта Пример «Продакт попросил дашборд, который при каждой загрузке страницы считает все заказы с момента запуска. На наших данных такой запрос шёл около 8 секунд и нагружал бы основную базу. Я спросил, для какого решения нужны эти цифры: оказалось, на них смотрят раз в час. Мы сделали сводную таблицу, которая каждую минуту обновляется по событиям заказов, и страница теперь грузится быстрее 100 мс.»

Интервьюер проверяет, умеете ли вы слышать критику, не защищаясь, и сказать коллеге о проблеме, не задев его. Расскажите, как вы делаете и то и другое, и подкрепите историей, где обратная связь изменила вашу работу. Принимать: дослушать, попросить конкретный пример, поблагодарить и позже вернуться с тем, что вы изменили Давать: наедине, вскоре после события, о поведении и его последствиях, а не о человеке («в этом PR не было тестов, и баг дошёл до QA»), с предложением На код-ревью: объяснять почему, отделять блокирующие замечания от мелочей, отмечать хорошее Красные флаги: «негативной обратной связи у меня не бывает», спор с каждым пунктом, обратная связь только через руководителя, резкие публичные комментарии Пример «После моего первого дизайн-ревью старший коллега сказал, что документ описывает код, но не варианты, которые я отбросил. Теперь в каждом моём документе есть раздел „Рассмотренные варианты“, и ревью стали короче, потому что на очевидные вопросы ответ уже есть.»

Интервьюер проверяет, умножаете ли вы результат команды, а не только свой. Расскажите конкретную историю: в чём был затык у человека или команды, что вы делали регулярно (парное программирование, ревью, задачи с растущей сложностью, общие практики) и какой результат можно показать. Начните с его пробела: спросите и понаблюдайте, что на самом деле мешает; общая лекция не помогает Учите на реальной работе: сделайте задачу вместе, затем дайте похожую сделать самому; на ревью объясняйте и давайте ссылки, а не переписывайте код Растите самостоятельность: задачи чуть выше уровня и место для мелких ошибок там, где они дёшевы Масштабируйте на команду: чеклист, правило линтера, шаблон PR, короткий внутренний доклад, записанные решения Результат: человек сам выпустил фичу, раундов ревью стало меньше, онбординг сократился Красные флаги: «я просто сам исправляю их код», менторство как раздача указаний, нет примера Пример «Джуниор запускал горутины, которые нечем было остановить, и передавал context.Background() глубоко в код. Мы вместе разбирали жизненный цикл запроса на его PR, и я написал короткий чеклист для ревью: ctx первым параметром, ошибки оборачиваются через %w, у каждой горутины есть владелец. Ещё мы включили -race в CI. Через три месяца он сам сделал следующий небольшой сервис.»

Интервьюер проверяет, говорите ли вы на языке бизнеса и умеете ли расставлять приоритеты, вместо того чтобы просить всё переписать. Переведите долг в цену, которую бизнес уже ощущает (медленные фичи, инциденты, потерянные пользователи), предложите небольшой измеримый план и отчитайтесь о результате. Измерьте боль: время на типичную фичу, баги за релиз в этой части, инциденты, время сборки, умноженное на команду Приоритет по цене: важен долг в коде, который часто меняется; старый стабильный код может оставаться некрасивым Понемногу и постоянно: фиксированная доля каждого спринта или чистка вместе со следующей фичей в этой части, а не заморозка на три месяца Покажите эффект: цифры до и после облегчают следующую просьбу Красные флаги: «код некрасивый» как аргумент, просьба переписать всё, работа, спрятанная в оценки фич Пример «У сервиса биллинга не было тестов и был общий пакет utils, который трогали все. Четыре из шести последних инцидентов начались там. Я предложил правило: никаких изменений в биллинге без тестов на затронутый код, плюс один день в спринт на разделение пакета. Через квартал в биллинге не было инцидентов, и изменениям там больше не требовались два ревьюера.»

Интервьюер проверяет, принимаете ли вы архитектурные решения по критериям и фиксируете ли их, а не по вкусу или по самому громкому голосу. Покажите варианты, ограничения, о которых договорились, как приняли и записали решение и что было потом. Назовите настоящие ограничения: размер команды, согласованность (нужна ли общая транзакция с заказами?), нагрузка, стоимость эксплуатации, кто будет это дежурить Запишите: короткий дизайн-документ или ADR с вариантами, компромиссами и решением; комментарии приходят письменно до встречи Предпочитайте обратимые шаги: модуль с чётким интерфейсом внутри монолита можно потом вынести в сервис, а разделение отменить трудно Не согласен, но делаю: когда решение принято, вы делаете его хорошо и называете сигнал, по которому к нему стоит вернуться Красные флаги: «микросервисы, потому что они у всех», новая база, потому что хотелось попробовать, отказ принять решение после проигрыша Пример «Команда хотела вынести уведомления в новый сервис на MongoDB. Я выступал за модуль в нашем монолите на Go и PostgreSQL: нас было четверо, а уведомления нужно было записывать в одной транзакции с заказами. Я написал одностраничный ADR с обоими вариантами; мы выбрали модуль с outbox-таблицей и договорились вернуться к вопросу при объёме в десять раз больше. Через год он всё ещё работает внутри монолита без единого бага согласованности.»

Интервьюер проверяет, относитесь ли вы к надёжности как к проекту: измеряете ли перед изменениями, находите ли настоящее узкое место, защищаете ли сервис от перегрузки и договариваетесь ли с другими командами. Расскажите по STAR, с цифрами до и после. Знайте цель: ожидаемый пик в запросах в секунду, задержка и доля ошибок, которые нужно удержать Сначала нагрузочный тест: k6 или повтор продакшен-трафика на копии в стейджинге, с профилями pprof и метриками базы Исправьте найденное узкое место: чаще всего им оказывается база (индексы, размер пула, кэширование), а не сам Go Защитите сервис: таймаут на каждый вызов, rate limiting, circuit breaker на медленных зависимостях, деградированный режим Договоритесь: владельцы зависимых сервисов и базы получают те же цифры заранее Красные флаги: «добавили подов» как вся история, оптимизация без замеров, непонимание, что откажет первым Пример «Перед распродажей мы ожидали в пять раз больше обычных 800 запросов в секунду. Тест в k6 показал p99 выше 2 с уже на 2000 rps: каждый запрос выполнял один и тот же запрос товаров к базе. Мы закэшировали данные товаров в Redis на 30 секунд, поставили таймауты и circuit breaker на медленный сервис рекомендаций и при его отказе отдавали страницу без рекомендаций. В сам день пик был 3600 rps при p99 меньше 250 мс.»