Предыдущие статьи серии:
1) Что спрашивают на собесах в 2025–2026: разбираем данные с 9 247 технических интервью
2) Реальные задачи с собеседований в Яндекс, VK, Ozon и Сбер — Go, Java, Python, React
И снова привет. Последняя статья из серии разбора данных моего пет-проекта. Поэтому сразу с места в карьер.
Восемнадцатая минута собеседования на позицию ведущего бэкенд-разработчика. Кандидат только что бодро рассказал про последний проект, про то, что делал руками, про рабочую неделю с понедельника по пятницу. И тут интервьюер спрашивает:
Расскажите, как вы ошиблись: как разработчик или как лидер - что произошло и что вы сделали после этого?
Пауза. Потом кандидат рассказывает историю про разработчика, которого сам привел в команду. Интервьюер не отпускает: "Что бы ты сделал по-другому в ситуации с тем разработчиком? Почему вообще возникла эта проблема - и что бы ты сейчас изменил?"
Это не сценка из книжки по менеджменту. Это кусок реального интервью из базы, я поменял только детали, по которым можно узнать участников. Я делаю сервис для помощи в собеседованиях, и у меня накопилось 12 952 расшифрованных сессии - 14 716 уникальных вопросов, которые живые интервьюеры задавали живым кандидатам в 2026 году. Не "топ-100 вопросов тимлиду" из статей, которые переписывают друг друга с 2015 года. Сырые стенограммы, со всеми перебиваниями, оговорками. Еще раз оговорюсь, что все данные обезличены и я не пишу транскрибацию пользователей - это даже технически не реализовано, захват идет только системного звука.
Мне стало интересно, чем собеседование руководителя отличается от собеседования инженера, если смотреть не на советы карьерных коучей, а на данные. Выгреб все, что звучало на интервью с "lead", "руководитель", "head", "тимлид", "ведущий", "главный", Engineering Manager, Project Manager и архитекторами в названии позиции. Вышло 217 уникальных вопросов, в сумме их задавали 354 раза. Для сравнения рядом держал всю базу: там 2 612 поведенческих вопросов и 129 чисто управленческих - про делегирование, конфликты, KPI и увольнения.
Часть данных лежит в открытом доступе - например, вопросы с реальных собеседований - так что мои выводы можно сверить с сырьем. И сразу честно: выборка кривовата. В ней люди, которые пользуются AI-ассистентом на интервью. Осторожный руководитель со стажем десять лет, который собеседуется раз в пять лет по звонку бывшего коллеги, в нее скорее всего не попал. Так что дальше - срез, а не истина. Но срез занятный, по крайней мере для меня.
Два собеседования
Прежде чем сыпать процентами, покажу, как реальное руководящее интервью выглядит целиком. Вот тайминг собеседования на Senior/Tech Lead Frontend (React + Next), 24 минуты:
0-я мин Какие позиции рассматриваешь, на что смотришь при выборе компании?
2-я мин На какую сумму ты хотел бы оффер, чтобы комфортно его принять?
4-я мин Про проект на Next.js: что делал руками, а что определял как тимлид?
7-я мин Какие архитектурные решения принимал лично?
11-я мин Как решал, что делать на клиенте, а что на сервере?
13-я мин Как измерял результаты своей работы? За какими метриками следил?
15-я мин Какой был твой вклад в стандарты команды?
17-я мин Какие инструменты качества внедрял?
19-я мин Какие проблемы производительности решал?
21-я мин Какие уровни кеширования есть во фронтенде Next.js-приложения?
Деньги на второй минуте. Не в конце, как учат методички, а сразу, до всякой технической части. И посмотрите, как движется интервью: ты и команда, ты и архитектура, ты и метрики, и только потом чистая техника. К двадцать первой минуте, когда дошло до кеширования, интервьюер уже знает про кандидата главное. Техвопрос в конце работает контрольным выстрелом: а не заврался ли ты за предыдущие двадцать минут.
Второе интервью - ведущий бэкенд-разработчик (Node.js, NestJS), 42 минуты. Оно началось с хода, которого я раньше не встречал (может просто потому что я мало собеседуюсь):
Вопрос тебе: в третьей части ты будешь задавать вопросы - какие вопросы ты бы задал в конце?
Нулевая минута. Кандидат еще не рассказал о себе, а его уже просят показать, что ему важно. Вопросы кандидата - это слепок его приоритетов: спросит про процессы, про людей, про деньги или вообще ни про что. Дальше по ходу: последний проект, "что ты делал руками", внезапное "по десятибалльной шкале, насколько это сложно?", рабочая неделя по дням, "занимались ли вы наймом и на что смотрите на собеседованиях". И только в конце немного техники про атомарность и балансы - финтех.
Сорок две минуты, пятнадцать вопросов, технических из них - два. Вот столько "техники" бывает на интервью ведущего разработчика. Если вы неделю готовились по списку вопросов про индексы - сочувствую.
Соотношение переворачивается
Теперь статистика. По всей базе так: 72% вопросов - теория, 18% - поведенческие, 7% - системный дизайн, остальное практика и лайвкодинг.
На руководящих и ведущих позициях наоборот: 50% поведенческих, 39% теории, 9% системного дизайна. А если оставить только "чистых" руководителей, без ведущих разработчиков и архитекторов, поведенческая доля дорастает до 54%.
Каждый второй вопрос - про вас, вашу команду и ваши решения. Но техника при этом никуда не девается, что видно и по таймлайнам выше. Руководителю группы сисадминов в нашей базе задают вопросы про FSMO-роли контроллеров домена, настройку VLAN в VMware и отличия TLS 1.2 от 1.3. Сказка "руководителя спрашивают только про людей" данными не подтверждается. Спрашивают и про людей, и про технологии. Просто теперь провалить можно и то и другое.
Вопрос номер один: конфликты
Самый частый управленческий вопрос базы, с большим отрывом: "Как вы подходите к разрешению конфликтов внутри команды?" Восемь раз, плюс варианты про конфликты с руководством и со смежными командами. А вот формулировка, которую я бы на месте кандидата опасался больше всего:
Расскажите о сложном техническом конфликте в команде, с которым вы сталкивались: что именно произошло, какую роль вы играли и как вы в итоге пришли к решению?
Интервьюер сам разложил вопрос по STAR, чтобы кандидат не отделался общими словами. На "как вы решаете конфликты" еще можно ответить заготовкой. Тут - нет. Тут нужна конкретная история, а она либо есть, либо ее нет. Придумать ее на ходу убедительно почти невозможно, я пробовал. Ну может я просто туповат, но все же.
Плохой ответ на мой взгляд выглядит так: "Я стараюсь выслушать обе стороны и найти компромисс. Главное - сохранить рабочую атмосферу". Это не ответ, это скринсейвер. Интервьюер слышал его сегодня уже дважды, а может и больше.
Хороший, опять таки на мой взгляд, примерно так: "Два сеньора месяц воевали из-за подхода к миграциям, ревью друг друга висели по три дня. Я собрал их на час и заставил каждого сформулировать, по каким критериям его вариант лучше. Оказалось, они спорят о разном: один про скорость наката, другой про откатываемость. Договорились: откатываемость обязательна, скорость по ситуации. Записали в конфлюенс. Ревью снова стали проходить за день". Что случилось, что сделал, чем кончилось, что осталось после. И заметьте, без слова "компромисс".
Совет банальный, но рабочий: до собеседования вспомните два-три реальных конфликта. Один технический, один человеческий. Не было ситуаций? Спросите более опытных коллег, выставьте их проблемы за свои. Прогоните каждый через "что случилось - что делал я - что вышло". И отдельно продумайте честный ответ на "что бы вы сделали иначе". Этот добивающий вопрос обязательно прилетит.
Скрытый текст
Как вы подходите к разрешению конфликтов внутри команды?
Какие метрики вы отслеживали в своих проектах?
Расскажите о сложном техническом конфликте в команде: что произошло, какую роль вы играли, как пришли к решению?
Как вы будете контролировать работу и выставлять цели, если команда работает удаленно?
Был ли у вас опыт управления командой?
Как вы измеряли результаты своей работы?
Какой вклад вы внесли в разработку стандартов команды?
Как оценивается ваш личный вклад в работу команды?
Какие архитектурные решения вы принимали лично?
Какие у вас были KPI на предыдущем месте и как вы их выполняли?
Расскажите про ваш проект: какие задачи выполняли самостоятельно, а какие делегировали как тимлид?
Как аргументировать бизнесу необходимость рефакторинга и работы с техническим долгом?
Как вы приоритизируете задачи при ограниченных ресурсах?
Как у вас устроен регулярный менеджмент с командой?
Расскажите, в каких проектах лучше использовать Kanban, а в каких Scrum?
Как рассчитать бюджет проекта?
Что такое PnL (Profit and Loss)?
Сколько времени нужно, чтобы понять, что сотрудник не справляется, и принять решение об увольнении?
Какой фреймворк вы используете для оценки эффективности сотрудников?
Какие будут ваши действия, если руководитель не хочет переносить созвон с пятницы на среду, потому что "так было всегда"?
В чем проявлялась токсичность в коллективе и как вы с этим работали?
Что вы можете сказать о бюджетировании?
Расскажите про свой опыт работы с дорожной картой (roadmap) проекта
Как вы контролировали работу и выставляли цели распределенной команде с 8-часовой разницей во времени?
Как вы принимаете решение при выборе между несколькими офферами?
Как эффективно взаимодействовать со смежными командами, если они игнорируют ваши запросы?
Как собрать мотивационные профили сотрудников?
Был ли у вас опыт увольнения сотрудников?
Занимались ли вы наймом? На что обращаете внимание на собеседованиях?
Расскажите, как вы ошиблись: как разработчик или как лидер?
"Почему проект закончился именно так"
Дальше идут вопросы про прошлый опыт, но не в формате "перечислите достижения". Пример, который мне просто нравится:
Расскажите о проекте с командой из 6 человек, в котором вы участвовали: почему он закончился именно так?
"Почему он закончился именно так" это вопрос не про проект. Это вопрос про то, как вы объясняете причины. Вешаете неудачу на обстоятельства и заказчика или видите свои ошибки. Приписываете успех себе одному или помните, что делала команда. Три слова в конце вопроса делают всю работу.
Начитавшись таких ответов в транскриптах, я заметил закономерность. Кандидаты, которые говорят "мы" про провалы и "я" про конкретные решения, звучат убедительно. У кого наоборот - "я вытянул проект", "команда не справилась" - тут будет подразумеваться, что не справились именно вы, а не команда. Интервьюеры считывают это мгновенно, даже не формулируя для себя.
Рядом обычные "резюмируйте ключевые результаты за время работы" и "почему ушли и что ищете". Ничего неожиданного, кроме одной детали: у руководителей эти вопросы звучат с упором на результат. Не "чем вы занимались", а "что удалось сделать".
Что делал руками, а что отдал
Вот пара вопросов, которые в реальном интервью шли почти подряд (таймлайн техлида, 4-я и 7-я минуты):
Расскажите про проект: что вы делали руками, а что определяли как тимлид?
Какие архитектурные решения ты принимал лично?
Тут ловят два противоположных перекоса, я оба видел вживую. Есть "играющий тренер, который не тренер" человек по-прежнему пишет весь сложный код сам, потому что "быстрее, чем объяснять", а команда тем временем тихо превращается в конвейер тикетов. И есть "чистый менеджер" делегировал все, включая понимание того, как устроена система, и на вопрос про архитектурные решения отвечает "ну, команда решила".
Хороший ответ показывает границу. "Схему данных я держал за собой, потому что цена ошибки - недели миграций. Реализацию фич отдавал целиком, включая выбор подхода, но дизайн-док ревьюил до начала кодинга". Так звучит человек, который думал о своей роли. Если такой границы у вас в голове нет проведите ее до собеседования. На собеседовании поздно.
Сюда же "какой вклад вы внесли в стандарты команды". Стандарты, код-ревью, онбординг - ровно то, что отличает тимлида от сеньора с амбициями. Если вспомнить нечего, это само по себе диагноз.
Удаленка и рабочая неделя
Блок, которого почти не бывает на инженерных собеседованиях
Как вы будете контролировать работу и выставлять цели, если команда работает удаленно?
Вопрос встретился трижды у одного работодателя. Похоже, у них это шрам, а не пункт чек-листа. Могу представить, как было дело: наняли лида, он не видел команду вживую, через полгода выяснилось, что половина людей ничего не делает. Теперь спрашивают всех подряд.
Отвечать "я доверяю людям" не стоит - звучит как отсутствие системы. "Ежедневные отчеты и трекер времени" еще хуже - это микроменеджмент, от которого сеньоры разбегаются за квартал. Рабочий ответ - про артефакты и ритм: цели на квартал, декомпозиция до задач с видимым результатом, регулярные встречи один на один, демо раз в две недели. И метрики результата, а не активности. В базе, кстати, есть версия этого вопроса на максималках: "Как вы выстраивали взаимодействие в распределенной команде с 8-часовой разницей во времени?" Был такой опыт - доставайте сами, не ждите вопроса.
Рядом: "как у вас устроен регулярный менеджмент", "как ставились и контролировались задачи", "в каких проектах лучше Kanban, а в каких Scrum". Последний - единственный теоретический управленческий вопрос, который встречается стабильно. Зубрить фреймворки не надо, но объяснить, почему поддержка живет на канбане, а продуктовая разработка на спринтах, придется.
И отдельно вопрос из интервью бэкендера, который выглядит невинно, а работает как рентген:
Расскажите, как у вас проходила рабочая неделя: с чего вы начинали в понедельник и чем заканчивали в пятницу?
Попробуйте ответить прямо сейчас, вслух. Если в рассказе не нашлось места ни планированию, ни встречам с людьми, ни ревью - интервьюер сделает вывод сам. Если неделя состоит из митингов целиком - тоже сделает, только другой.
Разговор с бизнесом
Мой любимый вопрос из всей выборки:
Как аргументировать бизнесу необходимость рефакторинга и работы с техническим долгом?
Каждый тимлид проходил этот разговор, и большинство его проиграло. "Нам нужно два спринта на рефакторинг" - "зачем?" - "код плохой" - "он работает? работает. делайте фичи". Занавес.
Слабый ответ - про чистоту кода, читаемость и красоту архитектуры. Бизнес слышит: инженеры хотят два спринта поиграть в конструктор.
Обсудите цифры. "Время выкатки фичи в этом модуле выросло с трех дней до двух недель. За квартал тут случилось 40% всех продакшн-инцидентов. Онбординг нового человека в эту подсистему занимает месяц. Вот план на два спринта, вот что станет с этими тремя цифрами". Техдолг продается бизнесу только в единицах, которые бизнес умеет считать: скорость, деньги, риск.
Рядом лежат "как вы приоритизируете при ограниченных ресурсах", "как рассчитать бюджет проекта", "что вы можете сказать о бюджетировании" (спросили у ведущего 1С-разработчика, если что) и внезапное "что такое PnL" у Engineering Manager. Выше тимлида про деньги говорят напрямую, без анестезии.
Деньги, мотивация, увольнения
Когда я писал первую версию этого текста, то написал "вопросов про увольнения в базе нет". Полез перепроверять, оказался неправ. Есть прямой "был ли у вас опыт увольнения сотрудников". И есть вот такой, он мне нравится гораздо больше:
Сколько времени обычно нужно, чтобы понять, что сотрудник не справляется с задачами, и принять решение о его увольнении?
Это вопрос не про увольнение, а про цену ожидания. Каждый месяц, пока вы "даете еще один шанс", команда тащит чужую работу, а сильные люди смотрят на это и обновляют резюме. Ответ "полгода" без деталей звучит как "тяну до последнего". Ответ "две недели" - как "рублю сплеча". Рабочий ответ - про процесс: как заметили, какой был план, какие сроки, что стало точкой невозврата.
И держите в уме: интервьюеры цепляются за оговорки. В базе есть буквально такой вопрос: "Что произошло и почему два человека ушли из команды, когда вы упомянули, что она сократилась?" Кандидат вскользь сказал "команда сократилась" и следующие десять минут объяснял, куда делись люди. Все, что вы говорите, может быть использовано.
Найм тоже спрашивают, реже, чем я ожидал: "Занимались ли вы наймом? На что вы обращаете внимание во время собеседования?" Стоит заранее сформулировать свои три критерия, иначе выйдет рекурсивный конфуз, вас спрашивают, как вы собеседуете, а вы не можете пройти собеседование.
С мотивацией картина неожиданная: спрашивают в основном не "как вы мотивируете команду", а про вашу собственную. "Что вас демотивирует в работе?", "Какая у вас основная мотивация?" и мое любимое, почти терапевтическое: "Вы сказали, что нет ресурса на работу - это выгорание, или вы переросли должность?" Про чужую мотивацию вопрос в базе один: "Как собрать мотивационные профили сотрудников?" Если ответа нет, посмотрите хотя бы, чем мотивационные факторы отличаются от гигиенических, на разговор хватит. Еще встретился неприятно-острый: "Почему вы не стремитесь к повышению грейда? Возможно, у вас нет четких целей?" Чистая провокация, отвечать спокойно и без оправданий.
Теперь деньги. Зарплатные ожидания - самый частый денежный вопрос, и, как видно из таймлайна, он может прозвучать на второй минуте. Перед ответом стоит свериться с рынком: мы отдельно собираем статистику, сколько зарабатывает Team Lead, и вилки там заметно шире, чем принято называть вслух. Но настоящий сюрприз в базе другой:
Как вы будете справляться с высокими расходами в Москве при переезде к нам?
Компания прямым текстом говорит кандидату, что ЗП от переезда из глубинки в столицу не вырастет, и проверяет, сбежит ли он через три месяца. Не знаю, восхищаться такой честностью или ужасаться. Если вам задали этот вопрос - это не вопрос, это предупреждение. Делайте выводы.
Остался блок, который у тимлида из сеньоров обычно слепая зона: KPI, премии, фонд оплаты труда. "Какие у вас были KPI и как вы их выполняли?", "По каким KPI оценивается ваша эффективность?", "Какой фреймворк вы используете для оценки эффективности сотрудников?", "Работали ли вы с фондом оплаты труда, планированием бюджета и бонусами?", "Была ли у вас система грейдов?". Сеньор про ФОТ не думает никогда. Руководитель отдела - каждый квартал. Если метите выше тимлида, подготовьте внятный рассказ, как у вас работало перформанс-ревью, кто решал вопрос премий и что вы в этой системе меняли. Даже если система была плохой. Особенно если плохой: "что бы я построил иначе" звучит сильнее, чем пересказ регламента.
Почему всех этих вопросов так мало - не знаю. Может, финальные этапы с CTO и HR-директором до нашей базы просто не доезжают, ассистентом на них не пользуются. Может, в российских компаниях увольнения и премии считаются территорией HR, и нанимающий менеджер туда не лезет. Проверить не могу. Но вывод для кандидата тот же: вопрос про увольнение прилетает без разминки и ровно один раз. Одна подготовленная история окупает себя целиком.
Отдельный жанр - ситуационные вопросы, где правильного ответа нет. Лучший экземпляр:
Какие будут ваши действия в ситуации, когда руководитель не хочет переносить созвон с пятницы на среду, аргументируя это тем, что так было всегда и команде удобно в пятницу?
Вопрос гениален своей мелочностью. Не "ваш CTO требует переписать все на Rust", а созвон. Крошечный конфликт, в котором видно все: пойдете ли на конфронтацию из-за ерунды, прогнетесь ли молча, догадаетесь ли спросить себя, почему вам вообще важна среда. Смотрят не на решение, а на ход мысли: выяснить интересы сторон, оценить цену вопроса, решить, стоит ли битва свеч.
На такие вопросы не надо искать правильный ответ. Надо думать вслух. Размышление вслух - половина того, за что руководителю платят. Вторая половина - знать, когда замолчать, но это на собеседовании не проверяют.
"Какие метрики вы отслеживали в своих проектах?" - четыре раза. "Как вы измеряли результаты своей работы?" - три. "Как оценивается ваш личный вклад?" - два.
Ловушка в том, что вопрос выглядит простым, а честного ответа у большинства нет. Типичный тимлид на этом месте начинает изобретать на ходу: "ну, velocity... количество закрытых задач...". Интервьюер слышал это сто раз и следующим вопросом спросит, что вы сделали, когда метрика просела. Тут импровизация и заканчивается, обычно с хрустом.
"Мы следили за velocity и burn-down чартами" - в переводе значит "я открывал Jira".
А вот что звучит убедительно: "Три вещи. Lead time от коммита до прода - упал с четырех дней до одного после переезда на trunk-based. Доля незапланированной работы в спринте - держали под 20%, когда выросло до 40%, я пошел разбираться и уперся во флаки-тесты. И текучка: за полтора года ушел один человек, и тот на повышение". Цифры, действия при отклонении, связь с решениями.
Если вы реально ничего не мерили - скажите прямо, но покажите, что понимаете, что стоило бы мерить и зачем. Это честнее и работает лучше, чем выдуманный velocity.
Сверка с методичками
Под конец я сделал то, с чего, наверное, стоило начать: взял классические списки вопросов для тимлидов - "20 вопросов для собеседования с тимлидом", разбор Яндекс Практикума, tlroadmap - и сверил с базой.
Совпадает многое: конфликты, делегирование, KPI, приоритизация, мотивация. Классика не врет, эти блоки реально спрашивают, вплоть до формулировок.
Кое-что из методичек у нас почти не встретилось: "расскажите о непопулярном решении, которое пришлось объяснять команде", "команда выгорела, а сроки поджимают - ваши действия?" (кейс из разбора Практикума, и он хорош), "как вы собираете обратную связь от команды". Готовить их все равно стоит. Такой вопрос если прилетит, то на финальном этапе, где ставки выше всего.
Зато в методичках нет того, что есть в реальных интервью. Денег на второй минуте. Цепляния за оговорки. Вопросов-предупреждений про низкую зарплату. "Опишите вашу рабочую неделю" вместо "как вы организуете процессы". Мелочных кейсов вроде пятничного созвона. И внезапного PnL. Методички готовят к экзамену. Реальное интервью больше похоже на разговор с очень внимательным человеком, который слушает не ответы, а то что между ними.
Скучная правда напоследок
Даже на руководящих собеседованиях полно вопросов уровня "расскажите о себе" (самый частый вопрос базы вообще, 18 раз) и "сколько человек было в вашей команде". Огромная часть любого интервью - это просто разговор по резюме, и хорошо отвечать на "расскажите о себе" важнее, чем блеснуть в хитром кейсе. Первые пять минут задают тон всему остальному, как бы обидно это ни звучало после недели подготовки к системному дизайну.
Если собеседование на следующей неделе
Короткий план из всего, что выше.
1) Готовьте истории, а не ответы. Два конфликта, один провальный проект с честным разбором причин, одна ошибка "как лидера", одно увольнение или почти-увольнение, один пример, где вы поменяли процесс. Каждую прогоните через "ситуация - что делал я - результат - что понял".
2) Проведите границу: что делаете руками, что отдаете, как контролируете. Этот вопрос был в обоих наших таймлайнах, будет и у вас.
3) Отрепетируйте ответ про деньги. Он может прозвучать на второй минуте, и мяться в этот момент - худшее, что можно сделать. Вилки посмотрите заранее.
4) Подготовьте один разговор с бизнесом: как продавали техдолг, выбивали людей или защищали сроки. С цифрами.
5) Вспомните, как у вас работали KPI, премии и грейды. Хотя бы на уровне "как было устроено и что я бы поменял". Выше тимлида без этого никак.
6) Опишите свою рабочую неделю. Серьезно, вслух, за две минуты. Если в ней не видно ни планирования, ни работы с людьми - у интервьюера возникнет тот же вопрос, что у вас сейчас.
7) Не забрасывайте техчасть: треть вопросов останется технической, и контрольный выстрел в конце - стандартный прием.
И вспомните, что вы мерили. Хоть что-нибудь. Вопрос про метрики - самый недооцененный в подготовке и один из самых частых в реальности.
Данные: Enigma AI 12 952 сессии, 14 716 канонических вопросов, из них 217 - с руководящих и ведущих позиций (задавались 354 раза), 2 612 поведенческих и 129 управленческих по всей базе. Январь-июль 2026. Вопросы кластеризованы автоматически: одному каноническому соответствует до дюжины формулировок, от "Что такое Docker?" до "Что такое тубер?". Таймлайны интервью - реальные сессии с измененными деталями. Сама база открыта: реальные вопросы с собеседований по 35 специальностям - можете покопаться в своей роли. Выборка смещена в сторону кандидатов, которые пользуются AI-ассистентами, держите это в голове, когда экстраполируете.
Спасибо за внимание.
