Собеседование на проджект-менеджера: реальные вопросы и разбор интервью с оффером 250 000 ₽

Вячеслав Степанов — проджект-менеджер, ментор · 4 сентября 2026

Это не теория из учебника. Ниже — разбор моего собственного технического собеседования на позицию IT project manager, которое закончилось оффером на 250 000 ₽. Запись целиком — сразу под этим абзацем, а дальше разбор: какие вопросы задавали, как я отвечал и почему это сработало.

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Контекст: что за собеседование

Компания с портфелем проектов «от браузерных игр до онлайн-банков» искала технического проджект-менеджера, который всё это консолидирует. На звонке — HR и IT-директор. Формат: техническое интервью, но, как вы увидите, почти все вопросы были не про технологии, а про управление. Это типично для роли PM: технику спрашивают на уровне кругозора, управление — на уровне мышления.

«Расскажите о себе» — как я строю самопрезентацию

Первое, что я сказал: «Не хочу душнить — не буду рассказывать, как я закончил университет и увлекался Паскалем». И сразу перешёл к делу:

• Опыт по проектам, а не по годам. Заказная веб-разработка → продуктовая EdTech-компания, больше трёх лет: сначала веб-версия, потом мобильное приложение.
• Состав команды цифрами. Девять человек: проджект, продакт, системный аналитик, по два iOS- и Android-разработчика, два тестировщика — плюс кроссфункциональные ML- и бэкенд-команды.
• Зона ответственности глаголами. Наполнение и приоритизация бэклога, релизный процесс, маркетинговые активности с командой. Конкретная фича — социальная сеть для учеников внутри продукта.
• Честная причина ухода. Компанию перевели с удалёнки на гибрид, меня это не устроило — без драмы и без негатива о работодателе.
• Что ищу. Проект, где виден конечный результат и влияние на метрики бизнеса.

Реальные вопросы и суть сильных ответов

«Инхаус-команда или аутсорс: плюсы, минусы, когда что?»

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

«Приходилось ли выбирать стек или технологию?»

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

«Кем вы управляли напрямую?»

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

«Кто ваши стейкхолдеры? Откуда приходили задачи?»

Руководитель направления, продукт-менеджер (груминги, обратная связь по фичам) и CTO. Плюс главный управленческий навык: за ресурсы приходится бороться языком цифр — объяснять, почему ML-команда должна потратить свой ресурс именно на твою фичу и именно сейчас.

«Как работали с техдолгом?»

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

Кейс-вопросы: четыре ситуации

Кейс 1. Пришёл новый разработчик, а документации нет

Каркас ответа: вводная встреча и логика проекта устно → доступы, команда, рабочие чаты → закрепить «бади»-ментора → кормить небольшими задачами и собирать обратную связь с двух сторон. А дальше — уровень выше: раз документации нет, это проблема процесса. Строим бизнес-процесс регулярного пополнения документации с контрольными точками и ответственными, чтобы знания не были завязаны на конкретных людях.

Кейс 2. Проблема, которую никто в компании не может решить

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

Кейс 3. Два разработчика спорят о технологии, задача стоит

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

Кейс 4. Уходит единственный носитель знаний о сложной системе

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

Что сработало: выводы

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

Частые вопросы