Расскажите про опыт работы со Swagger и настройку генерации и пагинации

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

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

Как отвечать

Про генерацию: пакет Swashbuckle.AspNetCore или NSwag, регистрация генератора и страницы в Program.cs. Дальше то, что отличает полезную схему от пустой:

• подключены XML-комментарии, у методов проставлены коды ответов через ProducesResponseType, ошибки описаны единым форматом ProblemDetails;
• версии API разведены по отдельным документам, служебные эндпоинты скрыты;
• страница генератора в продакшене либо выключена, либо отдаётся только по авторизации;
• спецификация используется дальше: из неё собирают клиента и проверяют обратную совместимость.

Про пагинацию скажите главное: страница берётся из базы, а не из памяти.

var items = await query.OrderBy(u => u.Id)
    .Skip((page - 1) * pageSize).Take(pageSize).ToListAsync();

Параметры принимайте отдельной моделью через FromQuery, ограничивайте максимальный размер страницы, возвращайте рядом с данными общее число или признак наличия следующей. Для больших и живых таблиц объясните курсорную пагинацию: условие по последнему ключу вместо Skip, стабильно и не деградирует на глубоких страницах.

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

Вытаскивают всю таблицу и режут её в памяти. Такой код проходит ревью на тестовой базе с сотней строк и ложится на боевой, потому что Skip и Take применяются уже к загруженному списку, а не превращаются в SQL.

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

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