Какой алгоритм кэширования применялся

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

Вопрос про ваш проект: где был кэш, по какому принципу он вытеснял данные и почему именно так. Интервьюер проверяет, понимаете ли вы, что происходит внутри подключённых библиотек. Следом обычно спрашивают, как кэш инвалидировался и что будет при нехватке памяти.

Как отвечать

Почти в любом Android-приложении ответ сводится к LRU (вытесняется то, к чему дольше всего не обращались), но на разных уровнях:

• память: LruCache из android.util или androidx.collection. Размер задаётся в своих единицах через sizeOf(), для картинок в байтах от доли Runtime.getRuntime().maxMemory(). Внутри это LinkedHashMap с порядком доступа;
• картинки: Glide и Coil держат кэш в памяти и на диске, оба уровня с LRU-вытеснением;
• сеть: Cache в OkHttp хранит ответы на диске и решает, отдавать ли их, по Cache-Control, ETag и Last-Modified. Вытеснение по размеру тоже LRU;
• данные: Room как единый источник правды, экран читает Flow из базы, а сеть только обновляет её. Здесь вопрос не в вытеснении, а в свежести: TTL, обновление по pull-to-refresh.

Каркас ответа: что кэшировали, где (память, диск, база), какой алгоритм и лимит, как сбрасывали устаревшее, что изменилось после внедрения. Цифры нужны свои: время открытия экрана, число запросов, трафик. Если сами кэш не проектировали, так и скажите: использовали кэш Glide или OkHttp из коробки, и объясните, как он устроен.

LFU и FIFO стоит упомянуть как альтернативы: LFU лучше держит часто нужные данные, но сложнее, FIFO проще, но вытесняет и то, что ещё нужно.

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

Называют Room или Retrofit алгоритмом кэширования. Retrofit сам ничего не кэширует, это делает OkHttp под ним, а Room это хранилище, а не политика вытеснения.

Ограничивают LruCache для картинок числом элементов. Несколько больших Bitmap легко доведут приложение до OutOfMemoryError.

Не могут ответить про инвалидацию. Кэш, который не умеет устаревать, показывает пользователю вчерашние цены.