Какие навыки по работе с данными и REST сервисами у вас есть

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

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

Как отвечать

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

• база: Spring Data JPA и Hibernate, плюс где вы спускались до SQL. Упомяните N+1 и чем лечили (JOIN FETCH, @EntityGraph, батч-загрузка), границы @Transactional и почему ленивые связи падают вне транзакции;
• миграции: Flyway или Liquibase, схема меняется только через них, а не руками на стенде;
• свой API: @RestController, осмысленные коды (201 на создание, 404, 409 на конфликт), пагинация через Pageable вместо выдачи всей таблицы, @Valid и единая обработка ошибок в @RestControllerAdvice. Начиная со Spring 6 для тела ошибки есть стандартный ProblemDetail;
• чужие сервисы: RestClient или WebClient, OpenFeign. RestTemplate давно в режиме поддержки, для нового кода его не берут. Обязательно таймауты, а ретраи только для идемпотентных запросов;
• сериализация: Jackson, DTO отдельно от сущностей;
• тесты: @WebMvcTest с MockMvc для контроллеров, Testcontainers для репозиториев на настоящем PostgreSQL, OpenAPI через springdoc.

Закончите случаем из своей практики: что тормозило, как нашли (лог SQL, EXPLAIN), что поменяли и что получилось в цифрах. Цифры нужны ваши, а не придуманные. Если какого-то слоя в опыте не было, скажите прямо и объясните, как подошли бы к задаче.

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

Перечисляют HTTP-методы и аннотации, как в учебнике. О вашем уровне это ничего не говорит.

Отдают JPA-сущности прямо из контроллера. Итог: рекурсия в JSON, LazyInitializationException и внутренняя модель, намертво вшитая в контракт.

Не могут объяснить идемпотентность: почему PUT и DELETE можно безопасно повторить, а POST без ключа идемпотентности нельзя.