Приходилось ли проектировать прокси или заниматься проксированием запросов?
Что проверяют
Умеете ли вы встать между клиентом и сервером, чтобы воспроизвести то, что через интерфейс не воспроизводится: ошибку сервера, обрезанный ответ, медленную сеть, истёкший токен. Плюс понимание, как устроен HTTPS, потому что перехват зашифрованного трафика требует отдельных действий и получается не всегда.
Как отвечать
Опишите схему: прокси встаёт между приложением и бэкендом, видит запрос и ответ целиком и может подменить любой из них. Отсюда задачи, которые вы решали: посмотреть, что уходит на сервер на самом деле, подменить ответ на ошибку или пустой список, добавить задержку, снять трафик мобильного приложения, проверить заголовки авторизации и то, что уходит в аналитику.
Назовите инструменты, с которыми работали: mitmproxy, Charles, Fiddler, Proxyman, а на уровне автотестов перехват средствами самого фреймворка, например page.route в Playwright, либо заглушка вроде WireMock.
Отдельно про сертификаты. Чтобы видеть содержимое HTTPS, клиент должен доверять корневому сертификату прокси: его ставят в систему, причём в современных версиях Android приложение пользовательским сертификатам по умолчанию не доверяет, и нужна отдельная настройка сетевой политики в отладочной сборке. Если включён пиннинг сертификата, перехват не заработает вовсе, и это не дефект.
Где спотыкаются
Говорят, что прокси «взламывает HTTPS». Ничего он не взламывает: всё держится на том, что вы сами добавили его сертификат в доверенные, и на чужом устройстве без этого шага трафик останется нечитаемым.
Второе: подменили ответ и забыли вернуть как было. Дальше вся сессия проходит на подложных данных, а найденные дефекты оказываются последствиями собственной заглушки.
Третье: замокав весь бэкенд, называют это интеграционной проверкой. Так проверен только клиент, контракт с сервером остаётся непроверенным, и расхождение всплывает уже на релизе.