Стоит ли сначала делать прототип перед написанием продакшн кода
Что проверяют
Умеете ли вы отделять разведку от разработки и договариваться о том, что прототип будет выброшен. Проверяют, стоит ли за ответом реальный случай или пересказ определения из книги.
Как отвечать
Ответ не «всегда», а «когда есть неопределённость». Прототип окупается, если неизвестно, потянет ли выбранная библиотека нагрузку, как поведёт себя чужой протокол, какой из двух вариантов модели данных проще в работе. Если задача понятна и похожа на сделанное десяток раз, прототип это просто отложенный релиз.
Опишите, как вы это делаете. У разведки заранее есть вопрос и срок: например, укладывается ли обработка пачки в отведённое окно, и на выяснение отводится пара дней. Код пишется грязно и намеренно: без обработки ошибок, с зашитыми значениями, в отдельной ветке. На выходе остаётся не код, а решение и короткая заметка, почему выбрано так.
Отдельно назовите промежуточный вариант, который в Java применяется чаще прототипа: тонкий сквозной каркас. Один простейший сценарий проводится через все слои, до базы и до развёртывания, и дальше на этот скелет наращивается остальное. Так рано вскрываются проблемы сборки, конфигурации и окружения, а код при этом продакшн с первого дня.
Закончить хорошо честной границей: прототип не отменяет тестов и ревью в боевой ветке, и смешивать эти два режима работы нельзя.
Где спотыкаются
Прототип уезжает в прод. Показали работающую демонстрацию, заказчик услышал «готово», и грязный код обрастает фичами. Защита простая: разведочный код физически не в рабочей ветке и не попадает в сборочный артефакт.
Второе: разведка без вопроса и без срока превращается в переписывание проекта. Если за отведённое время ответа нет, это тоже ответ: выбранный путь слишком дорог, и решение принимается по этому факту.
Третье: рассказывают про прототип общими словами, про снижение рисков и улучшение коммуникации. Интервьюер ждёт конкретику: что было неизвестно, что вы проверили, какое решение приняли и что после этого выбросили.