Как подготовиться к собеседованию по кодингу, где разрешён ИИ: план репетиции на 60 минут

Разрешение пользоваться ИИ на техническом собеседовании не отменяет экзамен. Оно меняет предмет оценки: смотрят не на скорость набора, а на решения — что спросить у ассистента, что принять, а что отклонить.

В марте 2026 года DoorDash в официальном анонсе описала замену классических coding-раундов на 60-минутную сессию с ИИ. Кандидат работает в собственной среде разработки, пользуется встроенными ассистентами и вносит изменения в готовый проект. В критериях оценки: ориентация в незнакомом коде, проверка выдачи ИИ, отладка, контроль объёма работы и объяснение компромиссов. Сделать все задания до конца менее важно, чем показать здравый смысл, — но время всё равно давит.

Дальше — мой план репетиции, а не официальный регламент компании и не реальные задачи с интервью. Права на инструменты уточняйте у рекрутера заранее: разрешение на одном этапе не переносится на остальные.

Почему это отдельный навык

Раньше интервьюер видел, как вы думаете, по коду: медленный набор, пауза, вторая попытка — всё это было видно. Теперь код может появиться быстрее, чем вы успеваете его понять. И если на сороковой минуте проект красиво переорганизован, а объяснить, почему заявка на возврат улетела не в ту очередь, вы не можете — это провал, хотя дифф выглядит прилично.

Тренировать надо именно этот момент: одну правку, её последствия и следы, по которым другой инженер восстановит ход мысли.

Учебный проект, который помещается в голову

Нужен крошечный API на тему поддержки: эндпоинт принимает текст сообщения, классификатор выбирает очередь, хранилище записывает тикет. Хватит хранилища в памяти. Валидация уже отбивает пустые сообщения и пробелы. Все три части должны запускаться локально до старта таймера — фичу добавляете уже под счётчик.

Классификатор пусть будет нарочно простым — пять строк на Python: def classify(text): message = text.casefold(); if 'order' in message: return 'delivery'; if 'payment' in message: return 'billing'; return 'general'

Новое требование: сообщения со словом refund уходят в очередь refunds, и это правило главнее проверок на order и payment. Всё остальное ведёт себя как раньше. Правило примитивное. Интересное начинается там, где оно живёт в коде и где сталкивается с соседними условиями.

План на час

0–8: один запрос целиком

Запустите приложение и отправьте сообщение, которое уже работает: «Where is my order?» должно попасть в delivery. Пройдите путь от эндпоинта до классификатора, потом до записи в хранилище, читая сами функции и валидацию вокруг них. Держите рядом бумажку со схемой — она пригодится, когда ассистент предложит поменять ещё шесть файлов.

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

8–15: договориться, что считается готовым

До запроса кода выпишите примеры. Один из них — с двумя ключевыми словами сразу — делает всю работу: без него два человека реализуют разный порядок правил и оба будут уверены, что поняли задачу.

Заодно очертите границы: никакой новой панели, никакого движения денег, никаких миграций — если только схема действительно не требует добавить новое значение очереди. Одна фраза, к которой можно возвращаться: «Мы добавляем правило маршрутизации и сохраняем поведение вокруг».

15–35: патч, который можно отревьюить

Теперь отдайте ассистенту контекст и жёстко очерченную просьбу. Шаблон, который стоит держать под рукой: «Посмотри маршрут тикета, классификатор, вызов хранилища и существующие проверки. Добавь очередь refunds для любого сообщения со словом refund без учёта регистра и сделай это правило приоритетнее order и payment. Сохрани валидацию и остальную маршрутизацию. Сначала объясни, какие файлы нужно менять, потом правь. Патч держи компактным, отдельно скажи, если схема не даст сохранить новую очередь».

Дифф читайте по мере появления. Изменилась форма ответа, исчезла валидация, появилась новая абстракция — спросите, какое требование это вызвало. Иногда причина есть. Иногда ваша задача про одну строку обзавелась фреймворком.

Порядок веток — самая частая ловушка

Пусть ассистент вставил условие про refund прямо перед финальным return: if 'payment' in message: return 'billing'; if 'refund' in message: return 'refunds'. На слове «refund» в одиночку всё сходится. А «payment refund» попадает в billing и до новой ветки не доходит никогда.

Правильное объяснение звучит так: первая совпавшая ветка возвращает результат сразу, поэтому сообщению с двумя ключевыми словами нужен явный приоритет. Поставьте проверку refund выше обеих существующих. Заодно поищите места, где зашито ровно три очереди: классификатор вернёт строку, а enum или проверка в хранилище её отвергнут. Путь, который вы прошли в первые восемь минут, как раз показывает, где искать эту границу.

35–50: проверка отдельно от ассистента

Прогоните существующие тесты и добавьте свои примеры, привязанные к требованию, — даже если ассистент предлагает поправить ожидания под фактический вывод. Для классификатора хватит трёх строк: assert classify('payment refund') == 'refunds'; assert classify('REFUND my order') == 'refunds'; assert classify('payment failed') == 'billing'.

Дальше шаг в сторону: отправьте сообщение про возврат через эндпоинт и посмотрите, что легло в хранилище. Ответ и сохранённая очередь должны совпадать. Юнит-тест классификатора не доказывает, что эндпоинт его вызывает. Пустое сообщение гоняйте через тот же эндпоинт — валидация живёт на маршруте, и проверка в обход него проверяет другую границу.

Держите в кармане одно неудобное сообщение

«I do not want a refund» по правилу подстроки уйдёт в refunds, хотя человек имел в виду обратное. Это хороший момент показать суждение, не превращая сессию в проект по NLP. Реализация соответствует правилу — само правило имеет продуктовое ограничение. Скажите это вслух и спросите, надо ли менять требование. Решите менять — сначала договоритесь о новом поведении, потом правьте. Не решаете — зафиксируйте ограничение и не расширяйте объём.

50–60: передача

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

Если что-то не готово, назовите конкретно: классификатор проходит, а хранилище всё ещё отвергает значение refunds. Это полезное состояние работы. Фраза «в целом всё сделано» скрывает ровно ту проблему, которую от вас хотят услышать.

Как усложнить следующий прогон

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

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

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