Где искать проблему, если API возвращает 200, но данные не отображаются на фронте

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

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

Как отвечать

Идите по цепочке от запроса к экрану, в DevTools браузера:

• тот ли запрос: во вкладке Network сверьте URL, окружение, параметры фильтра и пагинации, заголовок авторизации. Нередко фронт ходит на стенд, где данных просто нет;
• что в теле: код 200 ещё не успех. Пустой массив, "data": null или ошибка внутри тела (GraphQL отвечает статусом 200 с полем errors) для фронта выглядят как «нечего показать»;
• совпадает ли контракт: имена полей (userName против user_name), типы (число пришло строкой), вложенность, формат дат. Сверьте с OpenAPI-описанием;
• не кэш ли это: статус 304, пометка (disk cache) или ответ из Service Worker;
• что в консоли: TypeError: Cannot read properties of undefined или ошибка CORS. При CORS сервер честно отдаёт 200, но браузер не пускает ответ в код страницы, а в Postman всё работает;
• слой отображения: в React DevTools или Vue DevTools видно, дошли ли данные до состояния компонента. Дальше условия рендера, клиентские фильтры, фича-флаги и CSS, скрывающий блок.

Чтобы разделить зоны, подмените ответ через Charles, Proxyman или Overrides в Chrome DevTools: если с эталонным ответом всё отображается, проблема в данных, если нет, во фронте. К баг-репорту приложите HAR-файл, запрос, ответ и шаги.

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

Повторяют запрос в Postman без тех же параметров и токена и делают вывод «API в порядке». Сравнивать нужно ровно тот запрос, что отправил браузер: удобнее всего через Copy as cURL.

Смотрят только на код ответа и не открывают тело. Большая часть таких дефектов видна именно там.

Сразу несут вопрос разработчику без локализации. Сильный ответ показывает, что вы приходите с гипотезой и доказательствами.