AI-first собеседование на CTO: используйте один запутанный процесс

Почему широкие разговоры об AI дают слабые сигналы

Кандидат может звучать уверенно 20 минут и при этом почти ничего не рассказать о том, как он организует работу. Разговоры об AI делают это ещё хуже. Люди могут повторять знакомые идеи про agents, RAG, fine-tuning, Claude, GPT или open-source models и при этом не иметь привычки ставить ограничения, проверять результат или разбирать сбои.\n\nШирокие вопросы о мнениях провоцируют отполированные ответы. Спросите: «Что вы думаете об AI в инженерии?» — и часто услышите уверенную речь про скорость, инновации и будущее команд. Но такая речь не показывает, умеет ли человек защищать production, контролировать расходы или останавливать плохую автоматизацию, пока она не разнесла неверные данные дальше.\n\nCTO вызывает доверие через здравый операционный подход. Этот подход особенно заметен, когда задача запутанная. Дайте кандидату один процесс с недостающими деталями, противоречивыми целями и реальными потерями, если AI ошибётся. Тогда ему придётся принимать решения.\n\nНужно будет объяснить, где AI начинает работу, где человек её проверяет, что логируется, что повторяется автоматически и когда система должна остановиться и попросить помощи. Эти этапы проверки говорят о кандидате гораздо больше, чем список инструментов.\n\nСлабый кандидат часто остаётся на уровне модных слов:\n\n- «Я бы использовал здесь agents»\n- «Нам стоит добавить RAG»\n- «Помогла бы multi-model setup»\n\nСильный кандидат быстро переходит к конкретике. Он спрашивает, как выглядит вход, как часто бывают ошибки, сколько стоит сбой и кто отвечает за финальное одобрение. Он может сказать, что на первом этапе достаточно простого запроса и проверки человеком, а автоматизацию стоит добавлять только после измерения ошибок и затрат на tokens.\n\nВот это и есть настоящий сигнал. Хорошие CTO-кандидаты превращают туманную AI-энтузиазм в небольшой, управляемый процесс. Если в собеседовании они не могут этого сделать, то в условиях дедлайнов, затрат и рисков production, скорее всего, тоже не смогут.\n\n## Выберите один запутанный процесс\nВозьмите процесс, с которым ваша компания уже мучается. Лучший тест — не аккуратный демо-кейс. Это реальная цепочка работы с неудобными передачами между людьми, поздними согласованиями и недостающими деталями, которые все каждый день как-то обходят.\n\nХорошие варианты обычно проходят через несколько границ. Один человек начинает работу, другой её проверяет, третий утверждает, а два или три инструмента хранят разные куски правды. Именно этот беспорядок полезен: он показывает, способен ли CTO-кандидат улучшить ваш процесс, а не воображаемый идеальный.\n\nСильный рабочий процесс для собеседования обычно имеет такие признаки:\n\n- решения принимаются на нескольких этапах\n- данные приходят неполными или в неверном формате\n- работа проходит через несколько инструментов\n- возникают задержки, потому что за часть процесса никто явно не отвечает\n- кто-то должен одобрять расходы, риски или влияние на клиентов\n\nНе приводите процесс в идеальный вид перед собеседованием. Оставьте дублирующиеся поля, скопированные заметки, выгрузку в spreadsheet, сообщение в Slack, с которого всё начинается, или согласование, которое происходит только когда один менеджер в сети. Эти неровности и показывают, как кандидат думает.\n\nДля AI-first собеседования на CTO это важнее, чем общие мнения о моделях. Кандидат может звучать умно, рассуждая про agents, автоматизацию или выбор модели в общем. Но намного сложнее оставаться расплывчатым, когда нужно объяснить, как он обработал бы плохие входные данные, проверку человеком и сбои инструментов в одном реальном процессе.\n\nИзбегайте игрушечных задач вроде «напишите prompt для поддержки» или абстрактных вопросов вроде «как бы вы перестроили наши операции с помощью AI?». Такие вопросы вознаграждают уверенность, а не здравый смысл. Запутанный процесс заставляет выбирать между вариантами. Кандидат должен спросить, откуда берутся данные, какой этап действительно требует человека и где расходы могут тихо выйти из-под контроля.\n\nДержите масштаб достаточно маленьким, чтобы объяснить его за 10 минут. Если процесс слишком большой, собеседование превращается в рассказ. Если он слишком аккуратный, вы почти ничего не узнаете.\n\n## Что дать кандидату\n\nДайте ему небольшой пакет, а не расплывчатый запрос. Одной страницы часто достаточно. Если бриф занимает десять минут на чтение, значит, он, скорее всего, слишком отполирован и слишком прост.\n\nНачните с одного простого предложения, которое описывает задачу. «Сотрудники поддержки получают письма от клиентов, переносят данные в CRM, готовят ответ и передают случаи с возвратом на эскалацию» — этого достаточно. Простая цель помогает удержать разговор в реальности и не даёт кандидату уйти в общие рассуждения об AI.\n\nЗатем опишите процесс так, как он работает сейчас. Оставьте его живым и немного хаотичным. Укажите реальные передачи между людьми, копирование и вставку, инструменты, которые используют сотрудники, и где возникают задержки.\n\nЕсли одну и ту же задачу затрагивают три человека, так и скажите. Если команда всё ещё пользуется spreadsheet, потому что основная система медленная, это тоже стоит включить. Именно так AI-first собеседование на CTO начинает ощущаться настоящим.\n\nНе приводите каждую деталь в порядок. Оставьте несколько пробелов намеренно. Возможно, в брифе не сказано, кто проверяет результат AI перед отправкой возврата. Возможно, там не указано, где лежат исходные документы или как часто меняются поля в CRM.\n\nСильные кандидаты быстро замечают такие пробелы и задают вопросы. Слабые заполняют их догадками и ведут себя уверенно.\n\nДобавьте жёсткие ограничения, чтобы разговор был связан с бизнесом:\n\n- установите лимит бюджета, например $3,000 в месяц на новые инструменты и использование моделей\n- установите лимит времени, например 4 недели и один engineer\n- обозначьте бизнес-риск, например неправильные возвраты, утечка данных клиентов или пропущенные срочные случаи\n- задайте одно правило, которое нельзя игнорировать, например необходимость проверки человеком перед возвратами\n\nНебольшой пакет становится ещё полезнее, если добавить два или три сырых примера. Вставьте реальное письмо в поддержку, неаккуратную заметку в CRM и один случай, который пошёл не так в прошлом месяце. Тогда кандидат будет разбирать что-то конкретное, а не говорить общими словами.\n\nВам не нужен идеальный кейс. Более того, грубый кейс часто работает лучше. Задача оценки кандидата на CTO — не проверить, умеет ли он восхищаться AI. Задача в том, чтобы понять, может ли он превратить несовершенный процесс в более безопасный, дешёвый и быстрый, не делая вид, что проблемных частей не существует.\n\n## Как проводить собеседование\nДайте кандидату один запутанный процесс и держите разговор спокойным. Вы не проверяете, кто быстрее всех говорит об AI. Вы проверяете, способен ли человек превратить расплывчатый процесс в систему, которой можно доверять, которая не разорит компанию и которую можно запустить.\n\nНа AI-first собеседовании на CTO первые десять минут важнее, чем многие команды найма ожидают. Дайте кандидату время на уточняющие вопросы до того, как он предложит что-то своё. Сильные кандидаты спрашивают про входные данные, крайние случаи, правила согласования, текущие инструменты, кто владеет процессом и как выглядит сбой. Слабые сразу переходят к названиям моделей.\n\nЗатем идите по интервью в фиксированном порядке:\n\n1. Сначала спросите про этапы проверки, и только потом — про выбор модели. Серьёзный кандидат должен объяснить, где человек проверяет результат, что может утверждаться автоматически и какие действия требуют второй проверки.\n\n2. Только после этого спросите, что он бы построил первым. Лучшие ответы остаются маленькими. Они выбирают узкую версию, определяют метрику успеха и не превращают процесс в гигантский платформенный проект.\n\n3. Спросите, как бы он безопасно тестировал первую версию. Ищите staging data, промпты в стиле red team, случаи с плохими входными данными и понятный способ сравнить результат AI с текущим ручным процессом.\n\n4. Спросите, как он ограничит расходы и будет отслеживать использование. Хорошие ответы включают лимиты на запросы, уведомления о бюджете, логи по задачам, учёт token- или API-расходов и правила, когда достаточно более дешёвой модели.\n\n5. Завершите планом запуска на первый месяц. Кандидат должен объяснить настройку в первую неделю, пилот на маленькой группе, что он будет измерять каждую неделю и когда расширит запуск или остановит его.\n\nОбычно опытных операторов от любителей поговорить отличает одно: они заранее думают о сбоях. Если кандидат оставляет запасные сценарии, audit logs и правила отката на конец, это тревожный сигнал.\n\nПрактичный кандидат часто звучит менее эффектно. И это нормально. Если он умеет объяснить, кто проверяет результат, как он безопасно тестирует, где стоит потолок бюджета и что произойдёт на 12-й день, когда система ошибётся, вы получаете настоящий сигнал.\n\n## Что включает хороший ответ\nХороший ответ начинается с текущего процесса, а не со stack AI. Кандидат должен спросить, кто делает работу сейчас, какие входные данные приходят, где возникают задержки, где проскальзывают ошибки и как выглядит готовый результат. Если он сразу прыгает к названиям моделей или идеям про agents, он пропускает часть, которая вообще-то и решает, поможет ли автоматизация.\n\nЕму также стоит разделить процесс на три понятные группы: автоматизировать, помогать и оставить вручную. Это показывает здравый смысл. Повторяющиеся шаги с понятными правилами часто подходят для автоматизации. Черновики, краткие сводки и первичная классификация часто подходят для модели-помощника. Согласования, платежи, юридические изменения и необычные случаи должны оставаться у человека, если только у компании нет очень жёсткого контроля и реальных доказательств, что система справляется хорошо.\n\nНа AI-first собеседовании на CTO это один из лучших сигналов. Хорошие кандидаты воспринимают проверку человеком как часть дизайна, а не как мысль «на потом». Они понимают, что человек должен оставаться в контуре там, где ошибки стоят денег, создают проблемы с комплаенсом или бьют по доверию клиентов.\n\nОперационные детали тоже важны. Вдумчивый кандидат называет, что логируется на каждом этапе, что должно вызывать alert и кто отвечает за шаг. Например, он может захотеть логи для входящего запроса, извлечённых данных, результата модели, повторов, статуса одобрения и финального действия. Он может предложить alerts при росте очереди, резком скачке расходов, повторяющихся ошибках разбора или падении confidence score ниже заданного уровня. Не менее важно и то, что он назначает владельца — поддержку, operations или engineer — вместо расплывчатого «команда разберётся».\n\nХороший ответ также становится меньше, когда первая версия начинает расползаться. Обычно это хороший знак, а не слабость. Разумные кандидаты сужают объём до одного источника данных, одного пути через модель, одного правила одобрения и одной-двух метрик, которые действительно важны, например экономии времени или уровня ошибок.\n\nЛучшие ответы звучат практично. Они не обещают полную автоматизацию за первую неделю. Они показывают, где AI помогает, где люди всё ещё принимают решение и как компания может проверить идею, не превращая один запутанный процесс в три новые проблемы.\n\n## Простой пример для собеседования\nВозьмите процесс, который выглядит обычным, но ломается мелко и дорого. Хороший пример — sales-команда, которая переносит лиды из email в CRM, а затем использует AI для черновиков follow-up-писем и заметок о встречах.\n\nЭто удобно, потому что процесс легко понять и сложно приукрасить. Большинство CTO-кандидатов могут говорить об AI в общих чертах. Меньше тех, кто смотрит на запутанный процесс и может сказать, где появляется плохие данные, где теряются деньги и где неправильное сообщение подорвёт доверие.\n\nДайте им такой сценарий: в inbox sales приходят прямые письма, пересланные рекомендации и ответы от старых потенциальных клиентов. Сотрудник или простой parser переносит контактные данные в CRM. Затем шаг с AI готовит первый ответ, пишет краткое summary для записи клиента и подготавливает заметки после звонка.\n\nДобавьте несколько реалистичных проблем:\n\n- один и тот же лид приходит дважды с немного разными именами\n- в одном письме нет названия компании\n- в другом есть старая подпись с неправильным номером телефона\n- пересланное сообщение смешивает двух людей в одной переписке\n- в CRM уже есть запись из шести месяцев назад\n\nСильный кандидат должен сразу остановиться на дублях. Он должен спросить, как система сопоставляет записи, какие поля считаются надёжными и что происходит, когда данные из письма расходятся с данными в CRM. Если он этого не спрашивает, значит, он, вероятно, думает сначала про слой AI, а потом уже про процесс.\n\nЕму также стоит задать правила одобрения до отправки любого сообщения. Например, AI может делать черновик ответа, но команда должна запретить автоматическую отправку, если лид новый, confidence score низкий, в записи CRM есть противоречивые факты или черновик содержит детали, которых не было в исходном письме.\n\nЛучшая часть такого теста — это сбойный сценарий. Спросите, что происходит, когда черновик ошибается в фактах. Может быть, он укажет не ту компанию, выдумает время встречи или предположит интерес, которого у лида не было. Сильный ответ будет простым: не отправлять, показать исходный текст рядом с черновиком, пометить запись на проверку и зафиксировать ошибку, чтобы команда поняла, проблема была в разборе, поиске данных или в prompt.\n\nЭто говорит гораздо больше, чем общий вопрос на собеседовании CTO в духе «какова ваша стратегия с AI».\n\n## Какие вопросы задать про расходы\nКандидат, который сразу тянется к самой мощной модели, уже даёт слабый ответ. Хорошая работа с AI обычно начинается с более дешёвого варианта и переходит к дорогому только там, где точность действительно меняет результат.\n\nПопросите его разбить процесс на шаги и оценить стоимость каждого. Здравый план может использовать маленькую модель для сортировки входящих задач, более сильную модель только для сложных случаев и обычный код для правил, которым модель вообще не нужна. Так команды держат расходы под контролем, не замедляя работу.\n\nНа AI-first собеседовании на CTO несколько прямых вопросов скажут больше, чем общие мнения:\n\n- Какой шаг может работать на самой дешёвой модели без ущерба для результата?\n- Какой потолок расходов на двухнедельный тест и какой — после запуска?\n- Как вы будете отслеживать использование по процессу, по команде и по бизнес-результату, например по закрытым тикетам или обработанным счетам?\n- Какие низкорисковые задачи можно запускать пакетно каждый час или ночью, а не по одной?\n- Как часто вы будете пересматривать цифры и когда удалите шаг, который стоит денег, но почти ничего не даёт?\n\nСлушайте конкретные цифры. «Мы будем следить за расходами» — это расплывчато. «Мы ограничим пилот $1,500, а потом поставим паузу, если стоимость одного закрытого тикета превысит $0.80» — гораздо лучше. Точная цифра не так важна, как привычка её задавать.\n\nПакетная обработка — ещё одна простая проверка. Многие кандидаты о ней забывают. Если процесс включает summaries, tagging или черновики ответов, стоит спросить, нужны ли этим задачам мгновенные результаты. Если нет, запросы можно объединять и отправлять пачкой. Это часто сокращает расходы на API и сглаживает пики нагрузки.\n\nНедельный пересмотр важен, потому что лишние расходы прячутся в мелких шагах. Сначала добавляют один prompt, потом ещё одну проверку, потом вторую модель «на всякий случай». Сильный CTO-кандидат скажет, что хочет короткий еженедельный обзор расходов, качества и бизнес-результата, а затем уберёт всё, что не оправдывает своё место.\n\nТакой ответ показывает дисциплину. И ещё он показывает, что кандидат понимает: расходы на AI сами по себе вниз не поползут. Команда должна их подрезать.\n\n## Что они должны сказать про сбои\nСильный CTO-кандидат не говорит об AI так, будто он работает только в солнечные дни. Он должен начинать со сбоев. Если процесс зависит от писем, форм, тикетов, счетов или заметок звонков, спросите, что происходит, когда данные приходят с опозданием, дублируются или приходят с пропущенными полями.\n\nХорошие ответы быстро становятся конкретными. Слабый кандидат говорит: «мы будем валидировать входные данные». Более сильный скажет: «если не хватает суммы счета, система отправляет его в очередь проверки, записывает причину и останавливает все downstream-действия». Такая детализация важна, потому что большинство запутанных процессов ломается на краях, а не на happy path.\n\nОшибочные ответы, которые звучат правдоподобно, тоже нужно проверять отдельно. Если модель извлекает условия из контракта или пишет ответ клиенту, спросите, как команда поймает аккуратную, уверенно звучащую ошибку. Кандидат должен говорить о простых контролях: ссылка на источник, проверка правил по известным полям, выборочные ревизии и одобрение человеком для действий, связанных с деньгами, комплаенсом или обязательствами перед клиентом.\n\nЕщё вам нужен план запасного варианта:\n\n- что запускает остановку или переход на более простой режим\n- кто отвечает за инцидент, если модель или vendor ломается\n- какой ручной путь позволяет продолжать работу в тот же день\n- когда команда откатывает очередь действий\n- кто сообщает клиентам и что именно говорит\n\nВладелец важен. «Engineering посмотрит» — слишком расплывчато. Хороший ответ называет человека или роль, например дежурного engineer, руководителя ops или менеджера поддержки. Если основная модель падает, кандидат может переключиться на более простой rules-based путь, вторую модель или ручную очередь. Подойдёт любой вариант, если он помогает бизнесу продолжать работу.\n\nНебольшой пример помогает это легко оценить. Допустим, процесс сортирует входящие обращения в поддержку и готовит черновики ответов. Если vendor недоступен два часа, система должна перестать автоматически отправлять сообщения, направить новые тикеты в очередь для людей, предупредить команду и сохранить запись о том, что не было выполнено. Если плохие черновики уже ушли, кандидат должен объяснить, как он приостановит задачу, найдёт затронутых клиентов и отправит простое исправление.\n\nТакой ответ показывает операционное мышление, а не просто энтузиазм по поводу AI.\n\n## Ошибки, которые совершают интервьюеры\nПолированный ответ может быстро обмануть команду найма. Многие кандидаты звучат умно, когда говорят об AI в общих выражениях, но это почти ничего не говорит о том, как они будут управлять командой, контролировать расходы или разбираться со сбоями в реальном проекте.\n\nОдна распространённая ошибка — награждать уверенность вместо операционной конкретики. Если кандидат говорит, что он бы «использовал agents», «автоматизировал проверки» или «добавил слой модели», спросите, что произойдёт, когда модель даст плохой ответ, кто проверяет результат, что логируется и сколько процесс стоит в неделю. Сильные кандидаты отвечают конкретно. Слабые остаются на уровне абстракций.\n\nЕщё одна ошибка — превращать собеседование в спор об AI-трендах. Обычно это помогает людям с громкими мнениями, а не тем, кто может построить процесс, который реально работает в понедельник утром. Более качественная оценка кандидата на CTO использует один запутанный процесс и просит решения, компромиссы и запасные варианты.\n\nИнтервьюеры слишком часто пропускают вопросы о privacy, security и audit. Это проблема. Кандидат, который игнорирует границы данных клиентов, правила доступа, логирование prompt или историю изменений, уже показывает, как он будет работать потом. Если в вашем процессе есть счета, тикеты в поддержку, медицинские заметки, контракты или внутренний код, такие детали важны сразу.\n\nТакже часто забывают про принятие решения командой. План неполный, если после запуска никто им не владеет. Спросите, кто обучает команду, кто утверждает изменения prompt, кто рассматривает сбои и кто может остановить плохую автоматизацию, пока она не начала распространять неверные результаты по компании.\n\nЧасто повторяются несколько тревожных признаков:\n\n- человек говорит общими фразами и избегает цифр\n- он пропускает этапы проверки человеком\n- он считает безопасность задачей на потом\n- он предполагает, что команда «сама разберётся» после запуска\n\nСама процедура сравнения тоже может быть ошибочной. Если одному кандидату дали расплывчатый сценарий, а другому — подробный, результат будет шумом. Дайте всем один и тот же процесс, одни и те же бюджетные ограничения и одни и те же follow-up-вопросы. В AI-first собеседовании на CTO последовательность важна не меньше, чем сам ответ.\n\n## Быстрые проверки и следующие шаги\nХорошее AI-first собеседование на CTO должно оставить вас с чем-то конкретным. Вы ищете не человека с самыми сильными мнениями об AI. Вы ищете того, кто может взять запутанный процесс, ясно его объяснить, снизить риски и довести до production без лишних расходов.\n\nНачните с простой scorecard. Если два кандидата звучат одинаково умно, так будет легче увидеть разницу.\n\n- Спросите себя, может ли он объяснить процесс простыми словами. Если он прячется за жаргоном, ему может быть трудно работать с реальными командами.\n- Посмотрите, спросил ли он в начале разговора о расходах, путях сбоя и о том, кто отвечает за каждый этап. Сильные кандидаты делают это почти сразу.\n- Ищите небольшой пилот, а не гигантский план. У пилота должна быть одна понятная метрика успеха, например сократить время ручной проверки на 30% или уменьшить backlog поддержки на заданное число часов в неделю.\n- Попросите каждого кандидата отправить короткий письменный план после собеседования. Одной страницы достаточно, если человек понимает, что делает.\n\nЭтот письменный план важнее, чем большая часть разговоров на интервью. Он показывает, умеет ли кандидат мыслить по порядку: что тестировать первым, какие данные нужны, где модель может ошибиться, сколько это может стоить в месяц и когда должен вмешаться человек.\n\nЕсли вы сравниваете кандидатов, используйте одно и то же упражнение и один и тот же follow-up-запрос для всех. Так процесс остаётся честным. И так уверенные ораторы не выигрывают только потому, что умеют красиво говорить.\n\nЕсли роль важная или ответы получились очень близкими, поможет второй просмотр. Oleg Sotnikov может разобрать упражнение как Fractional CTO и помочь сравнить кандидатов по delivery, cost и risk. Это полезно, когда один человек звучит амбициозно, а другой — осторожно, и вам нужно понять, кто действительно запустит рабочую систему.\n\nОдин запутанный процесс, одно собеседование, один короткий письменный план. Обычно этого достаточно, чтобы принять следующий шаг.