Какие ошибки могут приходить с бэкенда

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

Понимаете ли вы, что ошибка бэкенда это не только код ответа, и умеете ли её локализовать и воспроизвести. Следом обычно спрашивают: «как проверите поведение интерфейса на 500, если бэкенд работает стабильно?»

Как отвечать

Группируйте по уровням, а не перечисляйте коды подряд:

• 4xx, проблема в запросе: 400 кривые данные, 401 нет токена или он истёк, 403 не хватает прав, 404 нет ресурса, 409 конфликт (дубль, устаревшая версия записи), 422 данные синтаксически верны, но нарушают правила, 429 превышен лимит запросов, часто с заголовком Retry-After;
• 5xx, проблема на сервере: 500 необработанное исключение, 502 и 504 шлюз или прокси не получил нормального ответа от сервиса за ним, 503 сервис перегружен или на обслуживании;
• сетевые: таймаут, отказ в соединении, DNS, просроченный TLS-сертификат. В браузере сюда же CORS: запрос мог дойти до сервера, но скрипт ответ не увидит;
• ошибки контракта: статус 200, но в теле нет поля, null вместо массива, число пришло строкой. В GraphQL ошибки вообще приходят в массиве errors при статусе 200;
• бизнес-ошибки: корректный ответ с кодом вроде «недостаточно средств», который интерфейс обязан показать понятным текстом.

Потом скажите, как вы это тестируете. Запрос и ответ смотрите в DevTools, дальше логи сервиса и трейс по идентификатору запроса. Чтобы получить 500 или таймаут по требованию, подменяете ответ через Charles, Proxyman или Fiddler (Map Local, Rewrite, Breakpoints) или поднимаете мок на WireMock. Проверяете, что пользователь видит понятное сообщение, спиннер не крутится вечно, введённые в форму данные не пропали, а повторное нажатие не создаёт дубль.

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

Перечисляют коды по справочнику и не могут сказать, как проверить реакцию интерфейса. Интервьюеру важнее второе.

Путают 401 и 403. Первый про то, кто вы, второй про то, что вам разрешено.

Считают статус 200 признаком успеха. Ошибка в теле ответа или нарушенный контракт проходят мимо, если проверять только статус.