Пример проектирования интеграции между фронтом и бэком для списка книг с таблицами базы данных
Что проверяют
Дойдёте ли вы от расплывчатой задачи до модели данных и контракта, по которому две команды смогут работать параллельно. Список книг тут условность: смотрят на порядок рассуждения, а не на знание конкретной базы.
Как отвечать
Начните с вопросов, а не со схемы. Сколько книг в каталоге, кто и как ищет, нужны ли фильтры и сортировки, кто заводит записи, есть ли обложка и где она хранится, нужна ли авторизация. Пока непонятно, как списком пользуются, проектировать нечего.
Затем модель. Книга, автор и жанр это отдельные сущности: автор связан с книгой отношением многие ко многим через связующую таблицу, жанр выносится в справочник. Автор строкой внутри книги ломает и фильтрацию, и переименование.
Дальше контракт. Один ресурс и понятный набор параметров:
GET /books?author_id=12&genre=fantasy&sort=year_desc&limit=20&cursor=...Оговорите ответ целиком: какие поля приходят в списке, а какие только в карточке GET /books/{id}, отдаётся ли общее количество, как выглядит пустая выборка, как передаются ошибки. Отдельно обсудите листание: смещение проще, курсор устойчив к вставкам во время просмотра.
Закончите нефункциональными требованиями: ожидаемый объём, время ответа, кэширование списка, права на изменение.
Где спотыкаются
Сразу рисуют таблицу и эндпоинты, пропустив вопросы о задаче. Интервьюер как раз проверяет, вытащите ли вы требования, и подсказку почти всегда держит наготове.
Второе: отдают весь каталог одним ответом. Без листания страница ляжет на первых тысячах записей, а сортировка по неуникальному полю без второго ключа даёт на границах страниц повторы и пропуски.
Третье: описывают только удачный сценарий. Нет кодов ответа, нет формата ошибки, не сказано, что пустая выборка это успешный ответ с пустым списком, а не ошибка. Ровно здесь фронтенд и бэкенд и расходятся при сборке.