CTO и Unit Lead: как подготовиться к собеседованию

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

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

Разведите мандат CTO и Unit Lead

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

На интервью уточните размер организации, зрелость продукта, горизонт планирования и участников управленческой команды. Затем обозначьте границу: например, CTO задаёт принципы архитектуры, общие платформенные инвестиции и технологические риски, а Unit Lead отвечает за выпуск ценности и устойчивость своего направления. Граница не отменяет совместной работы. Если проблема одной команды создаёт риск всему бизнесу, её нельзя оставить внутри подразделения только ради формальной автономии.

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

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

Свяжите стратегию с портфелем инвестиций

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

Покажите портфель как набор конкурирующих ставок. У каждой должны быть ожидаемый результат, полная стоимость владения, риск, контрольная точка и правило остановки. Это позволяет сравнить платформу, улучшение надёжности и продуктовую инициативу на одном уровне, не сводя решение к громкости заказчика.

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

Для решения «создавать самим или покупать готовое решение» (build/buy) сравнивайте не только цену договора и разработчиков. Учитывайте интеграцию, данные, безопасность, зависимость от поставщика, темп изменений и стоимость выхода. Покупка оправданна, если способность не отличает продукт и рынок зрел; собственная разработка — если именно она создаёт защищаемое преимущество или требования нельзя безопасно передать наружу.

Задайте архитектурное управление без комитета на всё

Архитектурное управление должно ускорять обратимые решения и тщательно проверять дорогие необратимые. Для этого нужны понятные права принятия решений, несколько принципов, записи архитектурных решений и порядок исключений. Центральный совет, рассматривающий каждую библиотеку, создаёт очередь. Полная автономия без границ приводит к несовместимым данным, протоколам и моделям безопасности.

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

При технической проверке сделки (due diligence) тот же принцип помогает отделить опасный риск от непривычного стека. Смотрите на права на код и данные, безопасность, способность выпускать изменения, ключевые зависимости, стоимость эксплуатации и концентрацию знаний. Итогом должен быть не список дефектов, а влияние на цену, план интеграции и условия закрытия сделки.

Управляйте надёжностью и инженерной экономикой

Надёжность обсуждают через пользовательский путь, целевой уровень сервиса (SLO) и бюджет ошибок. Если сервис укладывается в бюджет, команда может выпускать изменения в согласованном темпе. Если бюджет исчерпан, приоритет смещается на причины сбоев и снижение риска. Это не автоматический запрет релизов: руководитель учитывает критичность функции, сезонность, качество измерения и последствия задержки.

Хороший кейс связывает техническую метрику с потерями пользователей. Не «уменьшили p95», а «снизили 95-й перцентиль времени ответа оформления заказа с 1,8 до 0,7 секунды, после чего доля прерванных оплат сократилась». Отдельно назовите защитные метрики, чтобы локальная оптимизация не ухудшила стоимость или корректность.

Инженерная экономика также требует единицы результата. Общий счёт облака почти ничего не объясняет; полезнее стоимость заказа, активного клиента, расчёта или гигабайта обработанных данных. Рост удельной стоимости раскладывают на цену ресурсов, архитектурную эффективность, профиль нагрузки и изменение продукта. Снижение расходов без проверки задержек, доступности и темпа разработки легко переносит издержки на клиентов и команды. Сверьте масштаб роли и рынка с зарплатными ориентирами, но не подменяйте ими оценку мандата.

Сильный экономический ответ содержит базовый уровень, единицу результата, диапазон эффекта и побочные последствия. Фраза «сократил облачные расходы на 20%» неполна, пока неизвестно, что произошло с нагрузкой и качеством сервиса.

Спроектируйте операционную модель и преемственность

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

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

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

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

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

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