Приходилось ли писать код с нуля

Что проверяют

Есть ли у вас опыт принятия решений, а не только правки задач в готовом каркасе. В зрелом проекте стек, структура и правила уже заданы, и по ответу видно, сможете ли вы стартовать сервис, когда ничего этого нет.

Как отвечать

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

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

На каждое решение держите наготове компромисс. Не «взял Spring Boot», а почему он, а не вариант полегче, и чем за это платите: время старта, размер образа, магия автоконфигурации. Не «сделал микросервисы», а почему не один модуль, который вдвоём проще сопровождать.

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

Где спотыкаются

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

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

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