Найм разработчика для исправления кода, сгенерированного ИИ: вопросы для собеседования

Что идёт не так с кодом, сгенерированным ИИ, в реальных проектах

Приложения, созданные с помощью ИИ, часто выглядят отлично в демо, потому что «счастливый путь» работает. Проблемы начинаются, когда реальные пользователи делают реальные вещи: регистрируются дважды, восстанавливают пароль, вставляют странный ввод, открывают приложение в медленной сети или заходят с другого устройства. Многие прототипы на основе ИИ собираются быстро, поэтому первый же крайний случай может сломать ключовой поток.

Частые ошибки легко заметить, если знать, куда смотреть. Аутентификация — частый виновник: вход работает локально, а после деплоя ломается, роли и сессии ведут себя непоследовательно. Ещё одна классика — открытые секреты, например ключи API в клиентском коде или в истории репозитория. Логика тоже часто хрупкая: сумма в корзине считается в двух местах, вебхук срабатывает дважды, или ошибки заглатываются, что ведёт не к видимому падению, а к тихому повреждению данных.

Симптомы, которые обычно означают, что код требует серьёзного ремонта (а не мелких правок):

• Аутентификация и права кажутся случайными (пользователи видят то, чего не должны)
• Секреты захардкожены или одинаковы в разных окружениях
• Изменения в одной части ломают несвязанные функции
• Обработка данных непоследовательна (дубликаты, пропущенные обновления, частичные записи)
• Приложение работает локально, но падает после деплоя

То, кого вы нанимаете, — не просто «тот, кто добавит фичи». Нужен человек, который быстро диагностирует проблему, объяснит, что происходит, и применит безопасные исправления, не создавая новых проблем. Это означает чтение чужого кода, трассировку запросов от начала до конца, написание нескольких целевых тестов или проверок и улучшение структуры, чтобы следующий фикс дался легче.

Скорость важна, но скорость без корректности превращает прототипы в нескончаемые доработки. Установите ожидания заранее: попросите сначала начальную диагностику, а затем план ремонта с приоритетами. Хороший разработчик разделяет «остановить кровотечение» (проблемы с безопасностью, сломанная аутентификация, потеря данных) и «сделать красиво» (рефакторинг, уборка). Если вам нужно быстро, будьте конкретны о том, где приемлемы шероховатости, а где нет (безопасность, платежи, пользовательские данные).

Перед собеседованием: определите, что вам действительно нужно

Если вы хотите нанять разработчика для исправления кода, сгенерированного ИИ, не начинайте с общего объявления о вакансии. Начните с описания того, что для проекта значит «готово». Без этого собеседования превратятся в спор мнений вместо чёткого решения да/нет.

Определяйте «готово» через результаты, а не ощущения. Для грязного репозитория «готово» обычно означает: основные потоки работают, базовые проверки безопасности на месте, и вы можете задеплоить без сюрпризов.

Простая цель — перечислить, что должно быть верно после завершения работы. Держитесь практично: ключевые пользовательские сценарии работают от начала до конца, у самых рискованных путей есть хотя бы небольшой тестовый запас, секреты не выставлены, шаги деплоя повторяемы (не «работает на моей машине»), и код достаточно читаем, чтобы другой разработчик мог продолжить.

Далее подтвердите, действительно ли задача — «починить», а не «переписать». Приложения от ИИ могут выглядеть завершёнными, но скрывать глубокие проблемы (запутанная структура, хрупкое состояние, сломанная аутентификация). Решите, что вы примете: патч, стабилизирующий текущий код, или частичный перепис самых рискованных частей.

Также решите, какого именно специалиста вы ищете: того, кто комфортно работает с кодом, который он не писал. Отсекать можно ещё до собеседования: попросите описать первые 48 часов в чужом, запутанном репозитории. Ищите план, который начинается с диагностики (запустить, воспроизвести баги, читать логи), затем добавляет безопасность (тесты, бэкапы, небольшие изменения), а не масштабные рефакторы в первый же день.

Наконец, установите ожидания по коммуникации рисков. Вы хотите человека, который может сказать: «Я пока не уверен. Вот что я проверю дальше и что может изменить оценку».

Вопросы на собеседовании, которые показывают их подход к отладке

Вы нанимаете не за находчивость. Вы нанимаете за повторимый способ найти реальную причину даже в грязном коде.

Попросите назвать первые пять шагов после сообщения о критической ошибке. Слушайте спокойный упорядоченный план (собрать факты, воспроизвести, сузить область), а не «я начну менять вещи». Сильные кандидаты упоминают подтверждение влияния, фиксацию точного вывода ошибки и проверку недавних изменений.

Подсказки, которые выявляют их стиль работы:

• «Пользователь пишет, что при оформлении заказа происходит ошибка. Какие ваши первые 5 шагов, в порядке?»
• «Как вы воспроизводите баг, когда отчёт расплывчат? Что вы спрашиваете?»
• «Как вы изолируете минимальный проваливающийся кейс и зачем это важно?»
• «Что вы используете первым: логи, точки останова, тесты, трассировку? Когда переключаетесь?»

После ответа попросите пройти через реальный пример. Например: приложение работает локально, а в продакшне пользователей выбрасывает из сессии рандомно. Хороший дебаггер сравнит окружения, проверит куки и сессии, посмотрит на таймауты и добавит целевую логгирование с чёткой гипотезой.

Самый показательный вопрос — что они делают, когда не могут воспроизвести баг. Ищите ответы вроде: улучшить наблюдаемость (лучшие логи, трассы), создать минимальный тест, снизить риск временной защитой или флагом фичи, и составить короткий список гипотез для проверки. Если они говорят «я бы просто продолжил экспериментировать», это тревожный знак для хрупких кодовых баз, где «маленькая правка» может сломать три других потока.

Для быстрой проверки попросите объяснить подход простым языком, как будто они отчитываются перед нетехническим основателем в конце дня. Понятные апдейты обычно соответствуют дисциплинарной отладке.

Вопросы, проверяющие, как они справляются с неопределённостью и ошибками

Код от ИИ умеет уверенно ошибаться. Нужен человек, который признает, что ошибся, быстро меняет направление и оставляет систему в более безопасном состоянии.

Эта часть собеседования не про идеальные ответы. Она про реакцию, когда реальность не подтверждает первую гипотезу.

Попросите реальную историю провала (и делайте её конкретной)

Требуйте деталей, а не отрепетированных историй успеха:

• «Расскажите про баг, который вы сначала неправильно диагностировали. Что вы думали, и что оказалось на самом деле?»
• «Какой сигнал заставил вас изменить мнение?»
• «Что вы сначала сделали, чтобы снизить риск, пока не были уверены?»
• «Как вы подтвердили фикс и как убедились, что не сломали рядом стоящие вещи?»

Если кандидат остаётся расплывчатым, спросите: «Какой был самый маленький эксперимент, который вы провели, чтобы подтвердить или опровергнуть гипотезу?»

Реалистичный пример: вход в систему «случайно» падает. Слабый кандидат винит «нестабильную auth» и начинает менять библиотеки. Сильный кандидат объяснит, как воспроизвёл баг, заметил истечение токена или рассинхрон часов и проверил это парой целевых проверок.

Как звучат хорошие ответы

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

Если кандидат не может рассказать о своей ошибке без обвинения других или утверждает, что «никогда не ошибался в диагнозе», это тревожный знак. Отладка грязного кода — это работа с неопределённостью, и лучшие остаются спокойными и методичными.

Привычки по безопасности: вопросы, которые вскроют реальные практики

Безопасность часто тот момент, где «работает у меня» превращается в реальный риск. Вам нужны повторяемые привычки, а не обещания.

Начните с аутентификации и сессий. Приложения от ИИ часто смешивают подходы (куки, JWT, localStorage) и оставляют дыры.

Вопросы, которые быстро показывают практику:

• «Когда вы открываете новый репозиторий, что первым делом проверяете в auth и работе с сессиями?» — слушайте конкретику: флаги cookie (HttpOnly, Secure, SameSite), время жизни сессии, логика refresh и где хранятся токены.
• «Как вы находите открытые секреты и небезопасную конфигурацию?» — хорошие ответы включают сканирование на .env и ключи в репозитории, план ротации и предотвращения повторного попадания секретов.
• «Как вы предотвращаете SQL-инъекции здесь?» — ожидайте параметризованные запросы, безопасные шаблоны ORM и валидацию входа. Если они говорят «я просто очищаю ввод», попросите уточнить, как именно.
• «Какой у вас рутина обновления зависимостей в запутанном проекте?» — сильные ответы покрывают lockfile, инструменты аудита и план тестирования после апдейта.

Полезный дополнительный вопрос: «Объясните компромисс между скоростью и безопасностью для этого фикса». Например, если прототип хранит JWT в localStorage, хороший инженер объяснит, почему переход на HttpOnly-куки снижает риск XSS и что это меняет во frontend.

Красные флаги: уверенные, но расплывчатые ответы; неспособность назвать конкретные проверки для сессий и хранения токенов; сведение защиты от SQL-инъекций к «очистке входа»; игнорирование риска зависимостей потому что «это прототип»; или избегание темы ротации секретов после утечки.

Как они объясняют компромиссы простым языком

Вам нужны не только навыки программирования. Вам нужна оценка. Лучшие кандидаты могут объяснить, что они делают, зачем и что вы получаете (и теряете) с каждым вариантом.

Простой тест: попросите объяснить одно и то же решение дважды — как разработчику и как занятому основателю, которому нужно знать риск и стоимость. Если они не умеют менять тон, вам будет трудно принимать совместные решения.

Быстрая заплатка vs правильный рефактор

Дайте реальную проблему (сломанная auth, случайные падения, ошибки платежей) и попросите сравнить быстрый патч и глубокий фикс. Слушайте, как они описывают риск и включают ли шаги для безопасности, например тесты, логирование или план отката.

Полезные подсказки:

• «Если мы выпустим быструю заплатку сегодня, что может сломаться на следующей неделе?»
• «Что заставит вас остановиться и сказать: нужно рефакторить, а не патчить?»
• «Как вы докажете, что фикc работает, не надеясь просто на удачу?»

Переписать или починить, и как документировать решения

Код от ИИ часто держится до нагрузки. Спросите, как они решают, переписывать модуль или чинить. Сильные кандидаты опираются на сигналы: нечёткие границы, запутанные зависимости, повторяющийся copy-paste или риск безопасности, который трудно изолировать.

Попросите конкретику: «Если модуль профиля пользователя — спагетти, что вы сделаете в первые 48 часов?» Хороший план: изолировать модуль, добавить несколько тестов, рефакторить небольшими шагами и отслеживать производительность, чтобы не ввести медленные страницы или проблемы с масштабированием.

Наконец, спросите, как они записывают решения для нетехнических людей. Ищите короткие заметки: что изменилось, что не изменилось (пока), риски и следующие шаги.

Реалистичный сценарий для разбора на собеседовании

Возьмите простой, конкретный кейс и попросите кандидата думать вслух.

Сценарий: после обновления инструмента ИИ пользователи не могут войти. Приложение показывает «Invalid session» даже при правильном пароле. Вчера работало. Сейчас тикеты поддержки растут.

Сначала слушайте вопросы, которые они задают до того, как трогать код. Сильные кандидаты хотят знать: что менялось (деплой, переменные окружения, обновление зависимостей), затронуты ли все пользователи или только часть, есть ли логи или трассы, какой метод аутентификации используется (куки, JWT, OAuth) и не ротировались ли секреты. Бонус, если они спрашивают про риск: «Пользователи просто заблокированы или сессии принимаются неверно?»

Потом попросите обозначить таймбокс подхода. План должен звучать как чеклист, а не как угадывание:

• Первый час: воспроизвести баг, захватить один неудачный запрос/ответ, просканировать недавние диффы, подтвердить конфиг (домен cookie, CORS, callback URL, хранилище сессий).
• Первый день: проследить полный поток входа, добавить временное логирование вокруг создания и проверки сессии, написать небольшой тест, доказывающий проблему.
• После стабилизации: рефакторить хрупкие части, убрать скрытую связанность, добавить мониторинг и задокументировать изменения, чтобы это не повторилось.

Далее спросите, как они подтвердят фикc. Хорошие ответы включают воспроизводимые шаги, тесты на успех и отказ и план отката. Они также должны упомянуть предотвращение повторений (фиксация версий, безопасные проверки конфига, базовые правила ревью).

Наконец, нажмите на компромиссы: что они выпустят сейчас, а что отложат? Вы хотите человека, который защитит пользователей сегодня и не похоронит вас в будущем долге.

Типичные ошибки при найме для ремонта грязного кода

Самые большие ошибки на собеседовании — когда разговор остаётся абстрактным. Вам нужны детали: куда они смотрят в первую очередь, что измеряют и что делают, если ошиблись.

Одна ловушка — задавать вопросы, которые поощряют уверенность, а не ясность. Если спросить «Можете это привести в порядок?», большинство ответит «да». Вместо этого настаивайте на конкретике: какие сигналы скажут, что баг в данных, auth или состоянии, и какие доказательства они соберут до изменения кода.

Ещё одно упущение — излишняя фокусировка на фреймворках. Кандидат, который говорит только о переписывании на новом стеке, может избегать реальной работы: чтения странного кода, трассировки запросов и снижения рисков.

Красные флаги:

• План отладки — «просто добавить console.log» без воспроизведения, сужения, логов и трассировки.
• Отказ от тестов как «потом», без обсуждения защитной сетки перед рефактором.
• Твёрдые сроки без просмотра репозитория, конфигов и настроек деплоя.
• Нежелание объяснять решения простыми словами или раздражение на вопрос «почему».

Тайминги — отдельная ловушка. Сильные инженеры дают диапазоны и план, а не обещания. «Первый день: воспроизвести и описать поток запросов. День второй: исправить основные причины и добавить тесты. Затем переоценить» — звучит реалистичнее, чем гарантия без обзора кода.

Короткий чеклист: признаки подходящего человека

После короткого просмотра сильный кандидат может сказать, куда он смотрит и почему это ломает систему. Ему не нужна абсолютная уверенность, но он должен суметь в простых словах описать кодовую базу: что делает приложение, где основные потоки (вход, платежи, загрузки, админ) и что выбивается из шаблона (отсутствующие env, запутанная модель данных, дублирование логики).

Они не полезут сразу в переписывание. Лучший подход: «Сначала быстрый аудит, затем приоритетный список исправлений». Этот список должен ранжироваться по влиянию и риску, а не по интересу калибратора.

Слушайте привычки продакшна, а не пустые обещания. Кандидат должен упоминать тесты для сломанных путей, стейджинг-окружение, план отката и базовый мониторинг (даже простые логи и алерты). Они должны объяснить, как докажут, что фикc сработал, а не только как его реализуют.

Безопасность — ещё один быстро выявляющий фактор. Хороший кандидат сам укажет на риски: открытые секреты, слабые проверки авторизации, небезопасную сборку SQL, отсутствие валидации входа или слишком открытые настройки CORS.

Спросите также, как он будет вести работу неделя за неделей. Вам нужны понятные чек-ины и результаты, например краткий список топ-проблем с серьёзностью, что было выпущено, что дальше и что блокирует работу.

Следующие шаги: проведите небольшой пробный проект и задайте ясный план ремонта

Не бросайтесь в большой переписанный. С грязным кодом, сгенерированным ИИ, вы больше узнаете из небольшого платного теста, чем из ещё одного часа разговоров. Цель — увидеть, как они думают, как общаются и оставят ли код в более безопасном состоянии.

Держите тест малым, но реальным: одна видимая пользователю ошибка, одна правка по безопасности и один простой тест, фиксирующий изменение. Например: «Вход иногда падает», «удалить открытый секрет из репозитория и ротировать ключ», «добавить базовый тест для потока входа». Узкая область позволяет оценить результат за день или два.

До старта согласуйте, что значит «готово» и что вы получите обратно. В отчёте должно быть короткое объяснение, что изменено и почему, заметки по конфигам или окружениям и простой план деплоя с инструкцией, как проверить и откатить.

Если у вас нет времени глубоко проверять кандидатов, подход «аудит сначала» всё ещё полезен. FixMyMess (fixmymess.ai) фокусируется на диагностике и ремонте приложений, созданных ИИ (Lovable, Bolt, v0, Cursor, Replit), и начинает с бесплатного аудита кода, чтобы вы увидели реальные проблемы и приоритеты до обязательств на переписывание.