В каком формате происходит общение с сервером

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

Вопрос обычно про ваш проект: какой протокол, формат данных и библиотеки стояли в сетевом слое и почему. Интервьюер смотрит, различаете ли вы транспорт (HTTP) и формат (JSON, Protobuf). Следом спрашивают про сериализацию, авторизацию и обработку ошибок.

Как отвечать

Разложите ответ по уровням и назовите, что было у вас:

• транспорт: HTTPS, клиент OkHttp с поддержкой HTTP/2 и пулом соединений. Поверх него Retrofit с suspend-функциями в интерфейсе API вместо Call<T>;
• формат: чаще всего JSON через REST. Сериализация через kotlinx.serialization или Moshi. Gson ещё встречается в старом коде, но он не знает про nullability Kotlin и значения по умолчанию: создаёт объект в обход конструктора, и в non-null поле может оказаться null;
• GraphQL: Apollo Kotlin с генерацией типов по схеме. Клиент сам выбирает поля, лишних данных меньше, но HTTP-кэширование сложнее;
• gRPC и Protobuf: бинарный формат, компактнее JSON, строгий контракт в .proto. Встречается в крупных компаниях;
• реальное время: WebSocket через OkHttp для чатов и котировок, SSE, пуши через FCM;
• обвязка: Bearer-токен в Interceptor, обновление токена в Authenticator при ответе 401, HttpLoggingInterceptor только в debug-сборке.

Для Kotlin Multiplatform вместо Retrofit часто берут Ktor Client с тем же kotlinx.serialization.

Закончите обработкой ошибок: сетевые сбои, HTTP-ошибки и ошибки парсинга разделяются, результат оборачивается в sealed-класс, исключения не долетают до UI.

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

Называют HTTP форматом данных. Это протокол, а формат это то, что лежит в теле: JSON, XML, Protobuf.

Отвечают теорией про XML и SOAP без привязки к проекту. В Android-разработке SOAP почти не встречается, а спрашивали про ваш опыт.

Не могут объяснить, почему выбрали конкретную библиотеку сериализации. Хотя бы одна причина нужна: поддержка Kotlin, скорость, генерация кода вместо рефлексии.