На собеседовании CTO легко уйти в комфортную для всех сторону: обсуждать архитектуру, облака, языки программирования и последние технологии. Разговор получается умным, но не обязательно полезным.
CTO нанимают не для того, чтобы он лучше всех отвечал на технические вопросы. Его нанимают принимать решения, у которых есть цена, риск, люди и последствия для бизнеса.
Поэтому хорошее интервью CTO я бы строил вокруг реальных ситуаций, где нет идеального ответа.
Сначала договоритесь, что именно вы проверяете
До интервью полезно зафиксировать несколько критериев. Иначе один интервьюер оценивает техническую глубину, другой харизму, третий совпадение по стилю общения, а потом команда пытается сложить это в одно решение.
Для CTO обычно важны хотя бы пять вещей:
- качество решений в условиях неполной информации;
- умение связывать технологию с бизнесом;
- работа с рисками и техническим долгом;
- способность строить сильную инженерную организацию;
- готовность менять мнение и признавать ошибки.
Техническую глубину тоже нужно проверять. Но она не должна съесть всё интервью.
«Расскажите о техническом решении, которое вы изменили после разговора с бизнесом»
Хороший ответ показывает, способен ли человек менять мнение, когда появляется новый контекст.
Если кандидат всегда оказывается технически прав, а бизнес в его историях только мешает, это повод насторожиться. CTO не должен побеждать бизнес в споре. Он должен помогать компании принимать лучшее решение.
Полезный уточняющий вопрос: что именно изменилось в исходных предположениях и как кандидат понял, что прежнее решение стало хуже?
«Расскажите о решении, которое оказалось ошибочным»
У CTO почти невозможно построить карьеру без неудачных решений. Если кандидат не может вспомнить ни одного, обычно это говорит не об идеальной карьере, а о способе рассказывать о ней.
Смотрите, берёт ли человек ответственность, понимает ли, почему решение казалось разумным в тот момент, и что изменил после ошибки.
Фраза «все сделали неправильно, хотя я предупреждал» иногда бывает правдой. Но если так заканчивается каждая история, это уже паттерн.
«Что вы делали с системой, которую не стали бы строить сами?»
Большая часть работы руководителя происходит не на чистом листе. Есть наследие, старые решения, ограничения и люди, которые принимали их в другом контексте.
Здесь интересно услышать, пытается ли кандидат сначала понять причины или сразу начинает «правильно переписывать» всё вокруг.
Сильный CTO умеет жить с неидеальной архитектурой, если цена исправления сейчас выше реальной пользы.
«Когда вы сознательно решили не разрабатывать что-то внутри компании?»
Технологическому руководителю легко влюбиться в собственную разработку. Поэтому полезно проверить, умеет ли он выбрать покупку, готовый сервис или более простое решение, если бизнесу это выгоднее.
Build or Buy — это не вопрос инженерной гордости. Это вопрос фокуса, стоимости владения, зависимости от поставщика и того, где компания действительно хочет иметь собственную экспертизу.
«Как вы понимаете, какой технический долг нужно погашать?»
Ответ «весь» обычно бесполезен. Технический долг всегда конкурирует за ресурсы с развитием продукта, надёжностью и другими задачами.
Ищите логику приоритизации: как кандидат связывает техническую проблему со скоростью изменений, риском, стоимостью поддержки или бизнес-ограничениями.
Хороший ответ обычно содержит не только список проблем, но и способ объяснить бизнесу, почему конкретный долг стоит денег именно сейчас.
«Что вы делаете, когда сильный инженер с вами не согласен?»
Этот вопрос хорошо показывает стиль управления. CTO, которому необходимо всегда оставаться самым сильным техническим авторитетом, может быстро построить команду, которая перестанет спорить.
А отсутствие споров в сильной инженерной организации — не обязательно хороший знак.
Спросите, был ли случай, когда инженер убедил кандидата изменить решение. Это часто полезнее абстрактного рассказа про «открытость к обратной связи».
«Как вы объясняете CEO технический риск?»
Попросите привести реальный пример или прямо на интервью объяснить сложную проблему без технической терминологии.
Хороший ответ содержит не страх, а выбор: что может произойти, насколько это критично, какие есть варианты, сколько стоит снижение риска и что рекомендует сам CTO.
Executive-роль начинается там, где человек может перевести техническое решение в понятные последствия для бизнеса.
«Что вы будете смотреть в компании в первую очередь?»
Здесь интересен не конкретный список, а способ мышления. Кто-то начнёт с архитектуры, кто-то — с команды, процессов принятия решений, отношений с продуктом, метрик или обязательств перед бизнесом.
Полезно спросить: почему именно это и какие выводы кандидат рассчитывает получить?
Если первые недели уже заполнены заранее подготовленными реорганизациями и переписыванием архитектуры, стоит понять, на каких данных основана такая уверенность.
«Какой результат вы считаете хорошим для CTO через год?»
Этот вопрос показывает, считает ли кандидат своей работой личный героизм или создание системы.
Сильный ответ обычно говорит не только про релизы и технологии, но и про качество решений, предсказуемость, снижение ключевых рисков, развитие команды и способность организации работать без постоянного участия CTO в каждой детали.
Красные флаги на интервью CTO
- в каждой неудаче виноваты другие;
- на сложные вопросы есть слишком простые универсальные ответы;
- кандидат говорит о бизнесе как о помехе правильной инженерии;
- любой legacy нужно переписать;
- сильные инженеры описываются как люди, которых надо «поставить на место»;
- непонятно, какие решения кандидат готов делегировать;
- роль CTO описывается в основном через личную техническую экспертизу.
Один такой сигнал ещё ничего не доказывает. Но несколько похожих историй уже дают повод копать глубже.
Не превращайте интервью в набор правильных ответов
У многих вопросов выше нет единственно правильной позиции. Ценность именно в том, как кандидат раскладывает проблему, какие факторы считает важными, где просит дополнительный контекст и что готов поставить под сомнение.
Если компания ещё не определилась, нужен ли ей вообще CTO, сначала полезнее сравнить CTO и Tech Lead и понять масштаб роли. А если роль уже определена, профиль кандидата должен следовать из того, какую бизнес-задачу должен решить новый CTO.
В итоге
Я бы строил интервью CTO вокруг ситуаций, где приходится выбирать: скорость или устойчивость, build или buy, техническая чистота или бизнес-приоритет, личное решение или сильная команда.
Именно в таких ситуациях CTO будет работать после выхода в компанию.