Реальный кейс по ИИ в собесах

После недавнего поста про ИИ на собесах, у меня случилось несколько интересных консультаций

Сейчас многие стоят перед вопросом "а как вообще менять собесы", так что делюсь кейсом с одной из них (с разрешения)

———

Света – лид системных аналитиков в крупном российском банке. Они молодцы – уже делают отдельный этап собесов на применение ИИ. Но проблема – слишком похоже на обычный этап системного дизайна – так же собрать требования, спроектировать контракты и модель данных. Только теперь с ИИ. Да еще и оказалось, что все, кто хорошо прошел первый этап без ИИ – хорошо проходят и с ИИ

Свете не нравится – второй этап не дает знаний про кандидата, зато дает ему негативный опыт – никто не любит решать похожие задачи. Как поменять – сходу не понятно

Я обычно пытаюсь выйти немного за рамки конкретной задачи. Так и тут, я забиваю на собесы и начинаю:

⦁ А как вообще в компании уже используется ИИ?
⦁ Как ты использовала на последней неделе?
⦁ Где использовала команда?
⦁ Про что говорили как про вау-момент?
⦁ Какие самые геморные задачи перестали быть такими?

Образовывается два кластера задач

1. Формирование и исследование архитектурных концепций – по сути масштабный диприсерч и куча итераций сверху – для собесов не подходит

2. Генерация драфтов API контрактов – то, что нужно

Дальше самый важный вопрос:

Какие паттерны отличают успешных сотрудников от остальных?

Именно задания на эти паттерны и нужны на собесе. А сами паттерны → чеклисты для интервьюера

Вот несколько примеров грин-флагов, которые выцепили:

⦁ Постановка задачи ИИ – сначала уточняет цель, ограничения, критерии качества; декомпозирует на подзадачи; задает контекст (домен, ограничения по API/данным)

⦁ Итеративность – работает циклами (черновик → проверка → правки → повтор); запрашивает альтернативы и сравнение; ведет лог допущений; просит обосновать решения и указать источники/риски

⦁ Работа с форматами и артефактами – требует строгие форматы (OpenAPI/JSON/YAML), валидирует схему; просит диаграммы/сиквенсы/модель данных, связывает их между собой

⦁ Управление ограничениями и рисками – явно задает ограничения (совместимость, версии, SLA, лимиты, idempotency, пагинация, фильтры, сортировки); тестирует негативные сценарии

⦁ Качество – редактирует запрос, пока не получит качественный результат, перед тем как перейти к следующему шагу (вместо кучи микро-исправлений)

———

Предлагаю Свете сделать только один этап: 40 минут систем дизайна + 20 минут генерация драфта одного контракта из системы, которую задизайнили. Кандидат уже в контексте – удобно

На этом в целом можно закончить – Света довольна

Но есть ощущение, что можно еще докрутить, так что предлагаю подумать над двумя интересными фактами:

1. LLMки очень стараются сделать то, о чем их просят (иногда в очень извращенном виде)
2. LLMки сильно цепляются за то, что уже сделано (код, текст поста, архитектура)

Там где опытный разработчик не станет делать фичу, а объяснит менеджеру, что у нас тут сначала месяц рефакторинга, ИИ смело идет плодить костыли

Это и приводит к "проклятью вайбкодеров" – когда проект разрастается до определенной сложности, новые фичи уже не помещаются в текущую архитектуру, и их уже невозможно добавить, не сломав существующие

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

"Хороший специалист – знает, как не косячить. Отличный – знает, как исправить, когда кто-то уже накосячил" ауф

———

tl;dr

⦁ Смотрите на то, где команда уже применяет ИИ в работе
⦁ Ищите, чем отличаются паттерны успешных коллег – стройте задания на этом
⦁ Не давайте делать с нуля, а дайте средненькое решение и попросите что-то добавить (не прося "исправить")
⦁ Часть гринфлагов выше – универсальны, можете забирать себе