Был ли у вас опыт работы с JSON?

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

Умеете ли вы читать и проверять данные, которыми обмениваются сервисы, а не только нажимать кнопки в интерфейсе. Следом обычно дают кусок ответа API и просят найти проблему или спрашивают, как вы проверяете структуру ответа автоматически.

Как отвечать

Отвечайте на своём опыте, но с конкретикой: где встречали JSON, что в нём проверяли и чем.

• где: ответы REST API в Postman, Insomnia или Bruno, вкладка Network в DevTools, сообщения в очередях, тестовые данные и конфиги;
• что проверяли: обязательные поля, типы значений, формат дат (обычно ISO 8601), разницу между пустым массивом, null и отсутствующим ключом, кириллицу, граничные значения;
• чем автоматизировали: тесты в Postman с проверкой по JSON Schema, REST Assured или pytest с requests в автотестах, jq для быстрых выборок в консоли;
• что нашли: реальный баг. Например, id пришёл строкой вместо числа и сломал фильтр на клиенте, или большой long с бэкенда потерял точность в JavaScript, где целые безопасны только до 2^53.

Покажите, что знаете сам формат. Ключи только строки в двойных кавычках, нет комментариев, висячих запятых и undefined, отдельного типа для дат тоже нет. Типов значений шесть: строка, число, логическое значение, null, объект и массив.

Если опыта немного, скажите честно и опишите, что умеете уже сейчас: открыть ответ в DevTools, прочитать вложенную структуру, сверить её с документацией в Swagger. Если на учебном проекте разбирали JSON Schema, упомяните и это.

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

Проверяют только код 200 и не смотрят в тело. Сервис может вернуть 200 с {"error": "..."} или с пустым массивом там, где ждали данные.

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

Путают JSON с объектом JavaScript. Одинарные кавычки и комментарии в JS допустимы, а парсер JSON на них упадёт.