В команду нужен настоящий вайбкодер — человек, который держит LLM-агента на коротком поводке. Но классический тех-собес давно не показывает, кто реально умеет так работать. Попробуем подумать, как переделать интервью, чтобы выловить того самого мага вайбкодинга.
Зачем я вообще заморачиваюсь
Я сам пользуюсь всякими ИИ-примочками, как почти любой из нас сейчас. Не считая всяких копилотов и непосредственно LLM в виде обычного чата, в ходй уже довольно часто Cline. Cursor тоже пробовал, но с первого захода тот вышел из-под контроля и начал ломать куски проекта, которые я не просил трогать.
Почему я задумываюсь о реформах и думаю, что они неизбежно случаться? Да потому что идёт технологический хакинг системы сразу с двух сторон. Работодатели используют «топ нейросетей для рекрутинга», кандидаты — «нейросети для прохождения собеседования». Более того, у меня самого есть пет-проект помощника для онлайн-созвонов (в том числе собеседований) который хочу сделать бесплатным, но сейчас не об этом — кому интересно мотайте скроллом в подвал.
Все признают, что текущее тех-собеседование раздражает обе стороны: работодателя и кандидата. Для компании оно дорого, для соискателя — геморно и слабо коррелирует с реальными навыками (именно навыками, а не энциклопедическими знаниями).
Вообще есть послужной список в виде твоего резюме с подтверждением в трудовой книжке — если там длинные периоды стабильной работы и тебя не выносят поганой метлой каждые три месяца, то ты явно нормальный чувак. Есть ещё испытательный срок, куда он делся и почему сейчас не используется активно - загадка? Может, системы онбординга сломана? А может, весь этот скрамохаос с туманной иерархией не даёт нормально оценивать человека «в поле». Это отдельная тема для обсуждений.
Плюс большую часть карьерной жизни я сам собеседую людей. Арсенал собеседующего обязан расширяться, в соответствии с запросами времени, но я тоже в ловушке: отменить «допрос с пристрастием» не так просто когда это считай стандарт в крупных компаниях где обычно работаю.
Вайбкодинг: I love it, but I hate it
Сейчас много пишут о вайбкодинге, и мнения довольно полярные:
это продуктивно
это многократно умножает говнокод
я его спросил, а он выдал полную ахинею
не получается скормить бизнес требования и получить готовое приложение
от него спецы тупеют
помогает найти лучшие решения на незнакомом стеке
скопировал из LLM и оно взлетело с первого раза
легче самому поправить, чем заставить его сделать все правильно
Странно, но можно согласиться сразу со всем — решают детали.
Это продуктивно: пусть первый бросит в меня камень тот, кто считает, что «одна строка инструкции -> двадцать строк кода» — не круто.
Действительно порождает говнокод, если ты не в силах отличить плохой код от приличного и не умеешь рефакторить.
Конечно, ты будешь деградировать, если не понимаешь, как работает то, что написала модель, и не пытаешься разобраться.
Если ты изначально не знаешь, чего конкретно хочешь, никакой ИИ не спасёт.
Вайбкодинг силён, когда ты чётко ставишь задачи и умеешь держать агента под контролем.
Исходя из всего вышесказанного сформулируем требования к вайбкодеру:
Понимать бизнес-требования и уметь транслировать их в тех-формулировки для модели.
Формировать целевое видение архитектуры и дизайн кода приложения.
Декомпозировать задачи на связанные шаги.
Проводить качественное код-ревью и уметь в рефакторинг.
Звучит как сеньор или даже лид, правда? Значит, стартовый вайбкодер уже должен быть на уровне сеньора... Bad news для джунов. Встает вопрос как найти джунов/мидлов/сеньоров с такими видением мира?
Переформатируем тех собес
Главный вопрос: как превратить тех-собес из блиц-опроса про спецификации и массирования ЧСВ интервьюера в инструмент отбора людей, реально умеющих работать с ИИ-ассистентами?
Сразу оговорюсь, что это чистая теория которая нигде не проверялась, но очень хочется попробовать.
Подготовка
HR говорит кандидату «ок» и сразу скидывает список инструментов, с которыми предстоит работать (Cursor, Cline, whatever) чтобы он предварительно их опробовал, настроил у себя на машине.
За день до собеса кандидат получает задание, которое будет решать онлайн.
Вайбическое собеседование
Собираемся в моббинг на 1.5–2 часа и наблюдаем, как кандидат решает задачу с нуля(или с какой-то точки). Не обязательно за это время выжать готовое приложение. Где надо — подсказываем, где надо — молчим(может так спокойней работается). Записываем экран, код отправляем себе на потом. Финальные мысли кандидата после собеседования тоже собираем в телеграмку — хорошие идеи часто приходят «после звонка».
Что смотрим на выходе
Мы не охотимся за законченным приложением — смотрим, как человек организует процесс с ИИ-инструментами, как формулирует свои мысли, как ревьюит, куда рулят его архитектурные инстинкты. И решаем, импонирует нам такой стиль или нет.
Почему формат не работал раньше, а сейчас может взлететь? Раньше кучу кода приходилось писать вручную, даже простейшее приложение растягивалось на дни. С вайбкодингом думаю что-то ощутимое можно увидеть за часы в которе проходит собеседование.
Итог
Вайбкодинг совсем скоро перейдет и разряда "фишки" в новый базовый навык: быстро формулировать запрос, зафиксить халтуру модели и доносить результат до продакшена.
Классический тех-собес этот навык не вскрывает; вместо викторины по стандартизации нужен живой моббинг «кандидат + ИИ» прямо на созвоне.
Нужно тестировать новый формат на себе: два часа моббинга, реальная задача, открытые экраны, потом вместе смотрим код и делаем выводы.
PS: Развиваю пет проект помощника в онлайн созвонах, в том числе для прохождения собеседований который начал делать еще в 2023 когда это еще не стало мейнстримом. Пока что для себя понял, что фиговый из меня продажник так как не умею я продать, я умею кодить. [Реклама удалена модератором]. Запустил краудфандинговую кампанию на Boomstarter, чтобы были минимальные средства допилить и выпустить бесплатную локальную версию. Возможно отправиться в плавание с моей поддержкой, а если нет, то и фиг с ним — у меня был интересный хоть и довольно дорогой опыт.
Жду, что вы подпишитесь в телеграм бодро накидаете на вентилятор в комментариях, что такой формат собеседования не взлетит офигенен.
Комментарии (21)
gun_dose
08.07.2025 09:33«одна строка инструкции -> двадцать строк кода»
Это реально очень круто. Но пока гораздо чаще приходится писать 20 строк инструкций, чтобы получить одну строку кода.
lichnost Автор
08.07.2025 09:33А вот это как раз и навык распознать где нейронка даст профит, а где модхаться придется с ней.
Думаю, что легаси лапше не документированном даже пробовать не стоит.
gev
08.07.2025 09:33Для нейронки ее же код становится легаси лапшей через пару часов =)
lichnost Автор
08.07.2025 09:33А если явно нейронке говорить как организовать дизайн кода в проекте? Как с реальными джуном.
Указывать какие иниенфейсы будут, какие паттерны использовать, что сделать в реализациях и тд . У меня был хоть небольшой, но удачный опыт.
gev
08.07.2025 09:33Я так не упарывался, слишком дорого и по времени и по размеру контекста и по времени отклика (чем больше созданных ее артефактов, тем больше расход токенов, она же весь контекст гоняет туда сюда на каждый запрос). Меня больше чем на 8 часов так не хватало, потом все приходилось херить и начинать сначала. Все нейронки начинали ходить по кругу в попытках что-то создать, пофиксить, отрефакторить, придумать сами себе задач и немедленно их реализовать ))) угробив весь достигнутый прогресс на корню. И это не только про код.
lichnost Автор
08.07.2025 09:33Аналогичная ерунда с курсором была когда я одной строчкой хотел кучу кода получить.
Со стажерами кстати такое часто тоже бывает: на пальцах объясняешь, что нужно сделать, а через пару дней он уходит в цикл и занимается решением проблемы вообще к задаче не относящийся(например сборка сломалась из-за того, что новую версию рантайма себе поставил). Как распишешь в каком файле, что нужно править, какие зависимости использовать и где почитать документацию - все вроде работа нормализуется.
gun_dose
08.07.2025 09:33Дело не в легаси и не в структуре кода. Во-первых, не всегда возможно коротко объяснить нейросети свои намерения. 3-4 предложения на одну строчку кода - это прямо базовый сценарий. Во-вторых, довольно часто ИИ-инструменты начинают глючить - теряют контекст, как будто отказываются понимать, что ты им говоришь. Особенно этом грешит плагин Github Copilot в PHPStorm. AI Assistant от Jetbrains в этом плане значительно лучше, но у него на бесплатном плане очень маленькая квота, поэтому для совсем уж простых вещей я стараюсь использовать Copilot. А там где посложнее, там уже AI Assistant. В том числе иногда использую ассистант, чтобы поправить косяки после копайлота :D
lichnost Автор
08.07.2025 09:33Как раз такие случаи где точечно надо что-то поправить это пока не стоит нейросети закидывать. А вот там где кучу бойлерплейта написать или новый модуль который будет жонглировать уже существующими - там можно существенный профит получить.
Вообще нейросети очень подробные инструкции надо писать, что, как и в каком виде сделать. Если быть таким наставником не в вашем амплуа, то нейросеть по умолчанию будет фиговым работником.
gun_dose
08.07.2025 09:33С бойлерплейтом, а тем более новыми модулями надо тоже аккуратно. ИИ может запросто проигнорировать какие-то best practice, сослаться где-то на старые API, либо наоборот на слишком новые, до которых проект пока не обновили. Может проигнорировать уже имеющийся в проекте функционал и т.д. Зачастую нужно всё полностью расписывать, от какого класса отнаследоваться, какие зависимости внедрить и т.д. Для меня это вообще не проблема, написать 3-5 предложений и получить на выходе сразу пару сотен строк кода. Но я знаю, что просить, и как оно должно в итоге работать. А тот, кто не знает, по сути играет в лотерею.
Но не стоит забывать, что во многих фреймворках давным-давно придумали генераторы кода, которые могут сделать кучу бойлерплейта за считанные секунды. Причём это будет гарантированно работающий код, без всяких референсов на несуществующие библиотеки, и не надо лишней писанины в стиле "сделай нормально, а не как в прошлый раз". Так вот, делаешь рыбу генератором. Допустим "artisan make:controller". Потом открываешь сгенерированный класс и там уже объясняешь ИИ-помощнику, что хочешь в этом контроллере вывести. В таком случае у ИИ уже есть толковый контекст, задача упрощается, возрастает вероятность получить корректный вариант с первого раза. Ну и помимо времени экономятся ещё и токены.
lichnost Автор
08.07.2025 09:33+1
Как раз это здоровый подход - комбинировать разные методики, а не бездумно пологаться на ии.
Politura
08.07.2025 09:33Я как-то проходил собес, где надо было сделать тестовое за короткое время и утверждалось, что я могу использовать любые ИИ в работе. Попытался сделать без ИИ, сделал, но не за час, а за 3 часа, из-за чего мне отказали. Задание: дали гитхаб с проектом, надо было запилить новый функционал и в процессе тестирования всплывает ошибка в старом коде которую надо тоже пофиксить. Самому вовремя не успеть, если есть навык работы с курсором, то можно и успеть.
Только я не уверен, что хотел-бы туда попасть, подозреваю, что контора - потогонка на все задачи ставит нереальные сроки.
lichnost Автор
08.07.2025 09:33Интересно бы сравнить как раз с использованием ИИ.
Не аутсорсинг случайно был?
chernish2
08.07.2025 09:33Это же всё в шутку, правда? Это ведь просто ирония под видом статьи?
lichnost Автор
08.07.2025 09:33Это ведь ирония про иронию?
Я на самом деле прихожу к таким выводам. Можно сколько угодно противится и пытаться не замечать изменений, но похоже они все-таки будут. Возможно в каком-то другом виде, но будут.
AlexeyK77
Не забудьте классику:
-опыт вайбкодинга не менее пяти лет. ;)
lichnost Автор
Симбиоз не зрелого мозга HRов и корпоративных стандартов еще и не такое родить может.
LukaS0lncev
Интересная задумка. Опыт своим поделюсь вк. Самый жизнеспособный вариант, который я увидел, если у тебя достаточно ОЗУ, установить 3 виртуальные машины, общая папка с хостовой машиной, вирт машины на убунте, в нем стоит хромиум, докер, гит и настроены контейнеры с MCP серверами под ваши задачи. Claude code лучший выбор, если мы API используем. Почему 3 Вирт машины? Классика для работы SPA => API => TEST, т.е. одна делает бекенд в ней же MCP к БД, другая фронт у нее должен быть доступ к MCP браузера , третья пишет тесты , у нее должна быть доступна консоль и токен для работы с API и она же документацию пишет OpenAPI в общей папке, которую другие агенты видят. ну естественно у вас общая сеть настроена между машинами, чтобы запросы ходили. Так вы сможете полностью проверить работу человека, когда он сможет память и промпты настроить под каждого агента индивидуально. Из минусов, не работает с локальными моделями) Хотя на гите полно консольных утилит с оламой которые работают.
lichnost Автор
Интересная схема, но как мне видится разработка и настройка(память, эти вм, общие папки, консоли) инструментов это отдельная область в которую кандидат для и любой разработчик не должен укрываться. В конце концов область вайбкодинга полно к каким-то практикам и стандартам которые не нужно мучительно долго настраивать - поставило инсталляшку и сидит пиши поромты.
LukaS0lncev
Почему? Это как настройка IDE, я еще не упомянул тонкую настройку IDE для работы с этими LLM внутри VM через SSH туннели. Любой разработчик любит настраивать свою IDE под себя, тут аналогично.