После недавнего поста про ИИ на собесах, у меня случилось несколько интересных консультаций
Сейчас многие стоят перед вопросом "а как вообще менять собесы", так что делюсь кейсом с одной из них (с разрешения)
———
Света – лид системных аналитиков в крупном российском банке. Они молодцы – уже делают отдельный этап собесов на применение ИИ. Но проблема – слишком похоже на обычный этап системного дизайна – так же собрать требования, спроектировать контракты и модель данных. Только теперь с ИИ. Да еще и оказалось, что все, кто хорошо прошел первый этап без ИИ – хорошо проходят и с ИИ
Свете не нравится – второй этап не дает знаний про кандидата, зато дает ему негативный опыт – никто не любит решать похожие задачи. Как поменять – сходу не понятно
Я обычно пытаюсь выйти немного за рамки конкретной задачи. Так и тут, я забиваю на собесы и начинаю:
⦁ А как вообще в компании уже используется ИИ?
⦁ Как ты использовала на последней неделе?
⦁ Где использовала команда?
⦁ Про что говорили как про вау-момент?
⦁ Какие самые геморные задачи перестали быть такими?
Образовывается два кластера задач
1. Формирование и исследование архитектурных концепций – по сути масштабный диприсерч и куча итераций сверху – для собесов не подходит
2. Генерация драфтов API контрактов – то, что нужно
Дальше самый важный вопрос:
Какие паттерны отличают успешных сотрудников от остальных?
Именно задания на эти паттерны и нужны на собесе. А сами паттерны → чеклисты для интервьюера
Вот несколько примеров грин-флагов, которые выцепили:
⦁ Постановка задачи ИИ – сначала уточняет цель, ограничения, критерии качества; декомпозирует на подзадачи; задает контекст (домен, ограничения по API/данным)
⦁ Итеративность – работает циклами (черновик → проверка → правки → повтор); запрашивает альтернативы и сравнение; ведет лог допущений; просит обосновать решения и указать источники/риски
⦁ Работа с форматами и артефактами – требует строгие форматы (OpenAPI/JSON/YAML), валидирует схему; просит диаграммы/сиквенсы/модель данных, связывает их между собой
⦁ Управление ограничениями и рисками – явно задает ограничения (совместимость, версии, SLA, лимиты, idempotency, пагинация, фильтры, сортировки); тестирует негативные сценарии
⦁ Качество – редактирует запрос, пока не получит качественный результат, перед тем как перейти к следующему шагу (вместо кучи микро-исправлений)
———
Предлагаю Свете сделать только один этап: 40 минут систем дизайна + 20 минут генерация драфта одного контракта из системы, которую задизайнили. Кандидат уже в контексте – удобно
На этом в целом можно закончить – Света довольна
Но есть ощущение, что можно еще докрутить, так что предлагаю подумать над двумя интересными фактами:
1. LLMки очень стараются сделать то, о чем их просят (иногда в очень извращенном виде)
2. LLMки сильно цепляются за то, что уже сделано (код, текст поста, архитектура)
Там где опытный разработчик не станет делать фичу, а объяснит менеджеру, что у нас тут сначала месяц рефакторинга, ИИ смело идет плодить костыли
Это и приводит к "проклятью вайбкодеров" – когда проект разрастается до определенной сложности, новые фичи уже не помещаются в текущую архитектуру, и их уже невозможно добавить, не сломав существующие
Поэтому предлагаю Свете не делать на собесе драфт контракта с нуля, а, наоборот, дать уже готовый, но плохо спроектированный + попросить к нему добавить что-то (что просто так не влезет). И посмотреть, как человек будет решать проблему – все будет понятно
"Хороший специалист – знает, как не косячить. Отличный – знает, как исправить, когда кто-то уже накосячил" ауф
———
tl;dr
⦁ Смотрите на то, где команда уже применяет ИИ в работе
⦁ Ищите, чем отличаются паттерны успешных коллег – стройте задания на этом
⦁ Не давайте делать с нуля, а дайте средненькое решение и попросите что-то добавить (не прося "исправить")
⦁ Часть гринфлагов выше – универсальны, можете забирать себе