Как пройти собеседование на TPM: разбор вопросов и того, что за ними стоит

Собеседование на технического программного менеджера (TPM) устроено так, что за один день вас проверяют в двух ролях сразу. Amazon на своей странице подготовки к TPM-интервью разводит их прямым текстом: «техническая» половина требует находить зависимости и технические риски, влияющие на команды, «менеджерская» — расписание, спринты, вехи и отчётность. Там же TPM называют «клеем», который держит команды вместе.

Формат, который приводит Amazon: часовой телефонный скрин с senior-лидером, письменное задание за два дня до луп-интервью, затем пять интервью по 55 минут и решение в течение пяти рабочих дней. Цифры полезны как калибровка. Это не разговор «расскажите о себе», это пять часов разговора по существу.

Что на самом деле проверяют

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

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

Из каких раундов состоит луп

• скрин у рекрутера или нанимающего менеджера про масштаб программ, которые вы вели;
• кейс по управлению программой;
• системный дизайн;
• глубокое погружение в одну программу из резюме;
• поведенческий раунд про влияние без формальной власти.

В тренировочном треке Four-Leaf кейс и облегчённый системный дизайн идут отдельными раундами. Смысл в том, что сильный ответ в одном не прикрывает провал в другом — а часть кандидатов готовится ровно к чему-то одному.

Кейсы: диагноз раньше решения

Кейс по управлению программой — это сценарий с заблокированной зависимостью в середине. Два стоит отрепетировать вслух.

Команда отстаёт

Вы ведёте программу с тремя инженерными командами. Одна отстала на две недели и блокирует остальные. Что делаете?

Интервьюер ждёт диагноз до лечения. Почему отстали? Неясные требования, незапланированная зависимость и нехватка людей — причины разные, и ответ на каждую свой. Дальше радиус поражения для двух нижестоящих команд, и только потом варианты: урезать объём, переставить последовательность, добавить ресурс или сдвинуть дату.

«Наверное, всё будет нормально»

Инженерный лид говорит, что позднюю интеграцию зависимости «скорее всего, переживём». Ваши действия?

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

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

Во всех случаях работает одно правило: не эскалировать до анализа. Эскалация — инструмент. Приходить к ней стоит с вариантами и рекомендацией.

Системный дизайн на уровне TPM

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

Промпт нарочно широкий: спроектируйте сервис, куда пользователи загружают фотографии и делятся ими. Внятный ответ начинается с уточнения масштаба, потом набрасывает основные части — API загрузки, объектное хранилище, базу метаданных, CDN для чтения, асинхронную обработку превью — и называет компромиссы на этом уровне.

Слой TPM начинается там, где заканчивается схема. Где команды зависят друг от друга? Какой компонент самый рискованный и не должен ли он идти первым? Что попадёт в чек-лист готовности к запуску? Ответ, который заканчивается диаграммой без последовательности работ, закрывает половину раунда.

В код уходить не надо: в описании TPM-интервью у Amazon раунда по программированию нет вообще. Десять минут про индекс в базе, после которых до рисков программы дело не дошло, читаются как кандидат, который хотел бы быть инженером.

Техническое ретро

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

Проигрывают этот раунд двумя способами. Первый — рассказывать про процесс (стендапы, трекер, каденс) и ни слова про систему и результат. Второй — приписывать себе инженерные решения: интервьюер, который сам делал эту работу, вскроет это одним уточняющим вопросом.

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

Поведенческие вопросы

Здесь проверяют влияние без власти: инженерами, которые решают судьбу даты, TPM обычно не управляет. Amazon пишет, что каждый интервьюер задаст два-три поведенческих вопроса вокруг своих Leadership Principles, и советует структуру STAR.

• Расскажите про программу, где два старших стейкхолдера принципиально не соглашались друг с другом.
• Расскажите про программу, которая не попала в дату. Что вы увидели слишком поздно?
• Опишите случай, когда вы эскалировали риск. Что вы рекомендовали?
• Почему TPM, а не продукт или инженерный менеджмент?

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

В последнем вопросе важна точность формулировок. TPM отвечает за то, как идёт кросс-командное исполнение; продакт — за то, что и зачем строят; инженерный менеджер — за людей.

Что проверяет каждый раунд

Что переоценено

Заучивание фреймворков. Назвать методологию — не ответить на вопрос про зависимость. Кандидат, который на «что вы сделаете» отвечает «возьму матрицу RACI», так и не сказал, что именно он решит. Любой ответ привязывайте к критическому пути и цене вопроса.

Бесконечные задачи по программированию — сомнительное вложение. В описании TPM-интервью у Amazon про код нет ни слова, хотя в некоторых компаниях TPM просят писать код. Спросите рекрутера заранее; если не просят, часы лучше уходят на ширину по системному дизайну и на ту самую программу, которую попросят защищать.

План подготовки

1. Выберите программу для ретро. Нарисуйте её архитектуру по памяти, назовите самое трудное техническое решение и сформулируйте одной фразой, что бы вы изменили.
2. Проговорите кейсы вслух. Отстающая команда, «наверное, нормально», вынужденное урезание. Диагноз, варианты, рекомендация, план коммуникации.
3. Спроектируйте одну систему на уровне TPM. Шеринг фото, сервис уведомлений или миграция платежей. Половина времени — архитектура, половина — зависимости, последовательность и критерии запуска.
4. Соберите четыре поведенческие истории. Конфликт стейкхолдеров, сорванная дата, эскалация, жёсткое урезание. Каждая — до двух минут в STAR.
5. Прорепетируйте с уточняющими вопросами. Ответ в пустоту не тренирует главное — держать линию под давлением. Нужен кто-то в роли интервьюера, который переспрашивает.

Одна вещь, скорее всего, не изменится: статус-отчёт дешевеет. Чем больше инженерной работы проходит через AI-инструменты, тем меньше весит аккуратно собранный апдейт и тем дороже человек, который смотрит на план, находит зависимость без владельца и доводит двух старших инженеров до согласия, что делать дальше. На интервью это выглядит буднично: сначала риск, потом процесс.