По каким протоколам взаимодействовали с бэкендом

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

Что вы реально делали в сети, а не какие слова знаете. Ответ задаёт направление всей секции: назовёте gRPC, спросят про protobuf и стриминг, назовёте WebSocket, спросят про переподключение и работу в фоне.

Как отвечать

Идите от задач, а не от списка протоколов.

Основа это HTTP поверх TLS с REST, клиент обычно OkHttp плюс Retrofit, разбор ответа через kotlinx.serialization или Moshi. Здесь проговорите то, что видно только на практике: пул соединений и keep-alive, отдельные таймауты на подключение и чтение, интерцептор для авторизации и обновления токена, повторы только для идемпотентных запросов.

Для событий со стороны сервера перечислите варианты и объясните свой выбор: опрос по таймеру, долгий опрос, SSE, WebSocket. Сокет оправдан, когда поток двусторонний и частый, например чат или живой статус заказа. Для редких событий дешевле push через систему доставки сообщений: соединение в фоне всё равно разорвут.

gRPC поверх HTTP/2 уместен, если на нём уже живёт бэкенд: бинарный protobuf, клиент генерируется из схемы, есть стриминг.

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

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

Говорят, что HTTP тратит время на установку соединения при каждом запросе. С keep-alive соединение переиспользуется, а HTTP/2 ещё и мультиплексирует запросы в одном соединении.

Второе: описывают WebSocket и умалчивают про жизненный цикл в Android. Система усыпляет процесс, сеть переключается с сотовой на Wi-Fi, сокет тихо умирает. Без heartbeat, переподключения с растущей паузой и привязки к жизненному циклу экрана это не работает.

Третье: путают протокол и способ организации обмена. REST, GraphQL и JSON-RPC живут поверх HTTP и отдельными протоколами не являются. Такая путаница сразу выдаёт знание сети по статьям, а не по отладке.