---
title: Методичка к этапу 4 — секция про управленческий опыт (финал с руководителем, Тимур)
source: подготовлено 2026-10-07, TASK-50; по официальной странице Яндекса yandex.ru/jobs/interview/mdd (materials/01), видео Рубина (product-interview/materials/02), банкам вопросов (materials/02) и канону (materials/03)
---

# Методичка: интервью с будущим руководителем

## §1. Формат и кто напротив

- **Длительность до 60 минут**, онлайн, камера обязательно (официально).
- Ведёт **будущий руководитель** — Тимур. Это не проверка знаний, а **оценка совместимости и уровня**: он прикидывает, «как этот человек будет работать со мной, с командой и на этом масштабе».
- Предмет: **опыт руководства командами за последние ~3 года**, кейсы найма и увольнений, процессы, коммуникации со смежниками, конфликты + целеполагание (анонс рекрутера).
- Официально ждут **STAR**, внимание к работе с людьми и **рефлексию об удачных и неудачных решениях**. Неудачные решения — не риск, а обязательный элемент.
- Оценивают AI-транскриптом (как и прочие секции) → структура и чёткие формулировки имеют цену.

**Чем эта секция отличается от продуктовой.** Там оценивали структуру мышления на кейсе, тут — **твою реальную практику**. Разница в подготовке: не «выучить фреймворк», а **освежить и упаковать свои истории**. Плюс здесь проверяется аутентичность: придуманное не выдержит 2–3 уточнений.

## §2. Вероятная конструкция часа

1. **5–10 мин — разогрев и контекст**: «расскажи, чем управлял, какие команды, зона ответственности».
2. **30–35 мин — кейсы STAR** по темам: найм → развитие/повышения → 1:1/обратная связь → конфликт → сложное решение по людям (увольнение) → целеполагание/планы → коммуникации с бизнесом/смежниками → провал/рефлексия.
3. **10–15 мин — ситуационные вопросы** («а что бы вы сделали, если…») — проверка принципов, а не памяти.
4. **5–10 мин — твои вопросы** о команде, ожиданиях, процессах.

Тайминг ответа на историю: **2–3 минуты**, дальше — по уточняющим. Не выпаливать 7 минут — Тимуру нужно место для вопросов.

## §3. Скелет ответа на любой people-вопрос (STAR+)

**Пропорции времени (по практике интервью):** S — 15% · T — 15% · **A — 50%** · R — 20%. Половина ответа — что сделал **лично я**.

**Железное правило: «я» — про решения, «мы» — про провалы.** Убедительно звучат те, кто говорит «мы не успели» (не вешает вину на команду) и «я принял решение / я договорился / я делегировал» (берёт вклад на себя). Наоборот («я вытянул проект», «команда не справилась») читается против кандидата.

1. **Контекст** (1 фраза): команда, масштаб, период, моя роль. Например: «Райф, юнит из трёх команд, 20+ разработчиков и аналитиков, я технический лидер».
2. **Задача/проблема**: что было не так и почему это было важно для бизнеса/команды.
3. **Действия**: шаги, критерии решения, кого вовлёк, как договорились. **Здесь ценность** — показать процесс и его обоснование.
4. **Результат**: цифры и эффект **через людей** («пятеро выросли до повышения, включая преемника», «готовность миграции 80%», «единый роудмап трёх команд»).
5. **Рефлексия** (обязательно): что понял, что бы сделал иначе. Если история про провал — честно сказать, что не вышло и чему научился.

Речевые паттерны, которые работают: «Сначала я…», «Критерием было…», «Я договорился с X, потому что…», «В итоге…», «Сейчас бы я сделал иначе, потому что…».

## §4. Скелеты по блокам

### A. Целеполагание
Уточнить жанр: цели команде на квартал/роудмап, декомпозиция бизнес-цели, техстратегия.
Дополнительно ждут: **оценку сроков на неопределённых проектах** (как считаете, где буферы, что делаете с неизвестными), **регулярный менеджмент** (ритм: цели квартала → декомпозиция → 1:1 → демо раз в две недели; метрики результата, а не активности), **распределённую команду** (артефакты и ритм; «доверяю людям» = нет системы, «отчёты и трекер» = микроменеджмент), **Kanban vs Scrum** (единственный стабильный теоретический управленческий вопрос: почему поддержка живёт на канбане, а продукт — на спринтах).
Скелет: бизнес-цель → как я перевёл её в цели команды (квартал, измеримость) → как декомпозировал и распределил → каденция проверки → что делал при отклонении → результат + рефлексия.
Твоя фактура: единый техроудмап для трёх команд (Райф), PBR (Баланс), планирование запусков (Самокат), техдолг как отдельное направление цели (Райф, Самокат).
Фразы: «цель без метрики и владельца — пожелание», «цель команды должна быть видна в бизнес-результате», «раз в две недели сверяем: если горит — либо цель, либо ресурсы меняем».

### B. Найм
Скелет: профиль (skills + culture add) → этапы и критерии → структурное интервью → участие команды → решение и обратная связь → онбординг → как понял, что найм был удачным.
Фактура: комплексная система оценки кандидатов (Баланс), найм в Самокате при формировании команд с нуля, DevContainers/скрипты для быстрого старта (Дикси — онбординг).
Фраза: «ошиблись в найме — дороже, чем в архитектуре: переделывать человека нельзя, только расставаться».

### C. Развитие, мотивация, повышения
Скелет: как узнавал, чего хочет человек (1:1, карьерные треки) → план развития → что делал я (делегирование, зона роста, наставничество) → результат (повышение/переход) → рефлексия.
Фактура: матрица компетенций Ruby-разработчиков и 10+ семинаров (Баланс), 5 повышений и преемник (Самокат), 3 разработчика → тимлиды (Телематика), 1:1 как процесс (Райф), инициированное повышение (Райф), ~20 выросших инженеров за 9 лет.
Фразы: «растил не за счёт своих задач, а раздавая зоны ответственности», «все три преемника — это ответ на вопрос, умею ли я делегировать», «повышение инициировал я, обосновав перед руководством».

### D. Конфликты
Скелет: сигнал конфликта → вышел ли сам или ждал → разговор по отдельности → свёл к критериям/данным, а не к личностям → решение и владелец → как сохранил отношения → урок.
**Кейс-ядро: токсичный Senior** — быстрее всех, но пишет в ревью «что за бред», демотивирует джунов, спорит на синках. Ответ: факты (что и когда конкретно), прямой разговор с границами и последствиями, время на изменение, рецидив → расставание; позиция — здоровье команды важнее личной производительности. Плюс **выгорание**: как заметил (ранние сигналы), честный разговор, пересмотр нагрузки, границы времени. И **нейтральная формулировка конфликта через KPI**: «недопонимание в приоритетах: продакту важен T2M, мне — стабильность платформы» вместо «продакт был неадекватным».
Инструменты: Томас-Килманн (выбрать стиль под важность цели vs отношений), разделять людей и проблему, «disagree and commit», эскалация — инструмент, а не провал.
Твоя фактура: споры об архитектурных решениях в технических командах (DDD, миграции БД, ClickHouse↔PostgreSQL) — описывать через критерии и POC, а не «сказал как надо»; конфликт сроки-vs-качество с бизнесом.

### E. Сложные решения по людям (увольнения, несоответствие)
Скелет: признаки → что делал до решения (явные ожидания, план, точки контроля, честная обратная связь) → решение → как провёл расставание → эффект на команду → рефлексия.
Частый реальный вопрос: **«сколько времени нужно, чтобы понять, что сотрудник не справляется, и принять решение об увольнении?»** — отвечать процессом, а не сроком: зависит от прозрачности ожиданий и точек контроля; в среднем 1–3 месяца при честной обратной связи с первой недели.
Фразы: «дали все шансы, зафиксировали ожидания — расставание не должно быть сюрпризом», «здоровье команды важнее производительности одного».
⚠️ **Обязательно иметь эту историю**: «у нас такого не было» — прямой красный флаг (по официальному банку). Если опыта увольнения нет — честно: «сам увольнений не проводил, но был в роли, где подход формировался» ИЛИ заменить на другую «тяжёлую» историю (разговор о несоответствии грейду, отказ в повышении) — но правдиво.

### F. Коммуникации и влияние
Скелет: кто стейкхолдер → что нужно было от него → как аргументировал (данные, цена вариантов) → что получилось → отношение сохранил/укрепил.
**Кейс-ядро: блокирующая смежная команда** (у них свои приоритеты, ваша задача — в бэклоге на следующий квартал, эскалация директору нежелательна). Ответ: понять их KPI и ограничения, найти общую ценность (что для них ускорится/снимется риска), предложить обмен или частичное решение, договориться с владельцем, эскалацию оставить последним инструментом и не «через голову». Сюда же: **руководитель не хочет менять пятничный созвон «потому что так было всегда»** — аргументы ценой и данными, а не спором о привычке.
Фактура: защита техдолга/миграции перед бизнесом; синхронизация трёх команд в один юнит (Райф); инициированное повышение сотрудника перед руководством (Райф).
Фраза: «пришёл не с проблемой, а с двумя вариантами и ценой каждого».

### G. Провалы и рефлексия
Скелет: что планировал → что пошло не так → как заметил → что сделал → результат → вывод, который изменил практику.
Ждут культуру **Blameless Postmortem**: разбор без поиска виновных. Реальный вопрос — «**расскажите, как вы ошиблись: как разработчик или как лидер**» с дожимом «что бы сделали по-другому и почему вообще возникла проблема» (рефлексия проверяется вглубь). Плюс «почему проект закончился именно так?» — проверяют, как объясняете причины (обстоятельства или свои ошибки).
Кандидаты (правдиво): миграция на новую инфраструктуру не завершена в период (80% готовности) — почему, что делал; затянувшиеся оценки; процесс, который внедрил и откатил.
Фраза: «после этого я изменил подход: сначала пилот на одном модуле, потом масштаб».

### H. Технические вопросы лида (баланс код/менеджмент, код-ревью, техдолг)
Их задают почти всегда (банк вопросов): иметь чёткую позицию — «основной вклад через команду, руки сохраняю на сложных задачах, архитектуре и ревью; чем больше команда, тем меньше кода — и это осознанный выбор». Фактура: критерии код-ревью (Дикси), управление техдолгом как процесс (Райф), DDD (Самокат), CI (Дикси).
**Ловят два перекоса:** «играющий тренер, который не тренер» (весь сложный код сам, команда = конвейер тикетов) и «чистый менеджер» (делегировал всё, включая понимание системы; на архитектурный вопрос — «ну, команда решила»). Ответ должен **называть границу**: «схему данных держал за собой — цена ошибки недели миграций; реализацию фич отдавал целиком, дизайн-док ревьюил до старта». Плюс **техдолг на языке бизнеса**: не «код плохой», а «выкатка фичи в модуле выросла с 3 дней до 2 недель; 40% прод-инцидентов здесь; онбординг — месяц; вот план и что станет с цифрами». И вопрос-рентген: «как проходила ваша рабочая неделя — с чего в понедельник, чем в пятницу?» (нет планирования/людей/ревью в рассказе — вывод сделан).

## §5. Ситуационные вопросы — принципы (не заучивать)

Тимур проверяет принципы: как принимаешь решения по людям, как действуешь при неопределённости, где границы твоей ответственности. Работают 6 принципов (первые четыре — универсальные, 5–6 — из практики интервью):
1. **Сначала факты** — прежде чем действовать: наблюдение, данные, разговор.
2. **Прозрачность и своевременность** — люди не должны узнавать о решениях по себе в последний момент.
3. **Баланс интересов** — человек / команда / бизнес; назвать явно, чем пожертвовал и почему.
4. **Рефлексия** — «а что потом?» и «чему меня это научило».
5. **Системность, а не микроменеджмент** — лечить причину, а не симптом: не «исправил код за джуна», а внедрил автотесты/изменил процесс ревью.
6. **Delivery и бизнес-язык** — мыслить T2M, метриками продукта, стоимостью разработки; техдолг и риски переводить в единицы бизнеса (скорость, деньги, риск).
Плюс заготовка: отвечая на «что бы вы сделали», сначала уточнить контекст («а какая цель бизнеса? состав команды? есть ли история?») — так же, как на продуктовой секции.

## §6. Твоя модель тимлидства (вопрос №1, подготовить заранее)

Готовая формула (30–40 секунд): «Я инженерный лидер: 20 лет разработки, 9 лет руководства. Приношу ценность через команду, но остаюсь hands-on — беру сложные технические задачи, архитектуру, ревью, потому что без этого теряю почву и авторитет у команды. Время распределяю: люди — приоритет, процессы — по остаточному принципу (их я строю и делегирую), код — сложные задачи и ревью. Масштаб: три команды, юнит 20+ человек — учился именно этому переходу: от "сделай сам хорошо" к "сделай, чтобы другие могли"».

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

## §7. Вопросы Тимуру (подготовить 3–5)

1. Как выглядит успех в этой роли через 6 месяцев — по каким признакам вы поймёте, что всё идёт правильно?
2. Какая сейчас структура команды/команд и как устроены зоны ответственности? Где, по-вашему, узкое место?
3. Как у вас принимаются приоритеты между продуктовыми задачами и техническими инвестициями?
4. Как устроены ритуалы: 1:1, ретро, планирование, обратная связь по грейдам?
5. Какой уровень автономии ожидается от лида и как принимается решение «поднять вопрос выше»?

## §8. Красные флаги (по официальным материалам и банку)

0. **«Мыканье»** — ответ без личного вклада («мы собрались и переделали»). Интервьюер помечает: кандидат был пассажиром. Только «я инициировал / я принял решение / я делегировал». И зеркально — «я вытянул проект, команда не справилась»: провалы — «мы», решения — «я».
1. «У нас такого не было» — про конфликты, выгорание, увольнения. Выглядит нечестно.
2. Только технические достижения; результаты через людей не звучат.
3. «Я бы сделал сам» / нежелание делегировать.
4. Критика бывших подчинённых или руководства.
5. Уклончивая позиция про баланс код/менеджмент.
6. Идеальная история без ошибок и рефлексии; популярная ошибка — «мы всё сделали правильно».
7. Нет вопросов в конце — выглядит как незаинтересованность.
8. Пересказ теории без своего опыта (ОКР, SBI, Томас-Килманн уместны как названия подхода, но ответ строится на истории). «Менеджеры Яндекса не любят ответы в стиле "открываем Agile Guide и действуем по Scrum"» — нужен живой опыт; нет идеального кейса — честно «прямо такого не было, но был похожий».
9. **Перекос в «чистого администратора»** — красит графики в Jira, не знает, что под капотом; для Яндекса лид остаётся сильным инженером (Tech Lead).
10. **Скрытая идеализация**: «факапов не было, всегда всё сдаём вовремя» = низкая рефлексия или ложь. Плюс токсичность к бывшим коллегам/руководству — моментальный No Hire.

## §9. План подготовки до пятницы (2 дня) и перед секцией

**День 1 (сегодня, ~2 часа):** прочитать README + methodology §1–§6 (40 мин) → пройти experience-map.md и выбрать 6–8 историй (30 мин) → проговорить вслух под таймер 3 ключевые: найм, конфликт, сложное решение по людям (45 мин).
**День 2 (~2 часа):** проговорить остальные истории (развитие, целеполагание, коммуникации, провал) → мок-прогон со мной (Тимур) 60 мин → фикс слабых мест.
**Перед секцией (10 мин):** карточка — модель тимлидства (§6), 5 вопросов Тимуру (§7), 3 принципа (§5), красные флаги (§8).

**Карточка перед секцией (выучить):**
```
— Модель: hands-on лидер, ценность через команду; люди → процессы → сложный код.
— Звезда опыта: 3 команды / 20+ юнит (Райф); 5 повышений + преемник (Самокат);
  3 → тимлиды (Телематика); преемник (Баланс); ~20 выросших за 9 лет.
— Истории: найм (система оценки, Баланс), конфликт (архитектурный спор → критерии, POC),
  люди (ожидания → план → решение), целеполагание (техроудмап 3 команд), провал (миграция 80%).
— Рефлексия в каждой истории. Неудачу не прятать.
— Вопросы Тимуру: успех через 6 мес; структура и узкое место; приоритеты фича/техдолг;
  ритуалы; автономия лида.
```

## §10. Что показывают реальные интервью (эмпирика, 12 952 транскрипта)

1. **Порядок: деньги на 2-й минуте.** Реальный тайминг Tech Lead (24 мин): позиции → ожидания по деньгам → «что делали руками, а что определяли как тимлид» → «как измеряли результаты, за какими метриками» → технический вопрос в конце как контрольный выстрел. Быть готовым назвать ожидания сразу и по делу.
2. **Вопросы кандидата могут спросить в начале** («какие вопросы ты задашь в конце?») — это слепок приоритетов. Держать 3–5 вопросов наготове с первых минут.
3. **Граница «руками vs как тимлид»** — центральный вопрос лид-интервью; сформулировать её заранее (см. §6 и блок H).
4. **«Как вы ошиблись: как разработчик или как лидер»** + дожим «что бы сделали иначе» — готовить не один факап, а его разбор вглубь.
5. **Стандарты, код-ревью, онбординг** — «что вы сделали для стандартов команды»: это отличает тимлида от сеньора с амбициями.
6. **Техдолг — только в единицах бизнеса** (скорость, деньги, риск), иначе «код работает — делайте фичи».
7. **Рабочая неделя по дням** — рентген-вопрос: в рассказе должны быть люди, планирование и ревью, а не только митинги.
8. **«Почему проект закончился именно так?»** — проверяют, как объясняете причины: «мы» про провал, «я» про свои решения.

Подробнее — [`materials/05-habr-12952-interviews.md`](materials/05-habr-12952-interviews.md).

## Связанные документы
- [`README.md`](README.md) — индекс, что известно про этап
- [`knowledge-base.md`](knowledge-base.md) — канон (целеполагание, 1:1, фидбек, конфликты, найм, развитие, увольнения)
- [`experience-map.md`](experience-map.md) — 10+ STAR-историй из подтверждённого опыта
- [`training/cases.md`](training/cases.md) — банк вопросов и протокол мока
- [`materials/01-yandex-official-management-section.md`](materials/01-yandex-official-management-section.md) — официальная страница секции