Удавалось ли самостоятельно писать контроллеры в Spring

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

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

Как отвечать

Скажите «да» и сразу дайте конкретику из своего опыта. Достаточно одного эндпоинта, рассказанного до конца: что за ресурс, какие методы, что приходило и что возвращалось.

Опорные точки, по которым видно реальный опыт:

• @RestController против @Controller, и почему во втором случае нужен @ResponseBody;
• маппинг и разбор запроса: @GetMapping, @PostMapping, @PathVariable, @RequestParam, @RequestBody;
• отдельные классы запроса и ответа вместо сущности базы;
• валидация через @Valid и осмысленный ответ, когда она не прошла;
• централизованная обработка ошибок в @RestControllerAdvice вместо try в каждом методе;
• коды ответа и ResponseEntity там, где нужен не только успешный статус;
• тесты веб-слоя через @WebMvcTest и MockMvc.

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

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

Отдают наружу сущность JPA. На собеседовании это видно сразу по примеру кода, а в работе превращается в лишние поля в ответе, рекурсию по связям и обращение к закрытой сессии при ленивой загрузке.

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

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