Расскажите про опыт работы с нативными технологиями для мобильной разработки

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

Что вы понимаете под словом «нативная»: язык и набор библиотек или ещё и жизненный цикл системы, ограничения фоновой работы и поведение при нехватке памяти. Ответ уровня выше джуна начинается там, где появляются процесс и состояние.

Как отвечать

Соберите рассказ вокруг стека, который реально использовали:

• Kotlin, корутины и Flow для асинхронности, структурная конкурентность привязывает работу к жизненному циклу экрана;
• Jetpack: ViewModel, Navigation, Room для локальной базы, DataStore вместо SharedPreferences, WorkManager для отложенной и гарантированной работы;
• интерфейс: Compose или разметка на View. Скажите, с чем работали, и чем отличается подход к состоянию;
• сеть: Retrofit с OkHttp или Ktor, свои перехватчики, повторы, кэш;
• внедрение зависимостей через Hilt или Koin, тесты на вьюмоделях, инструментальные тесты на Espresso.

Архитектуру называйте не аббревиатурой, а правилом: состояние экрана одно и приходит сверху, события идут снизу, вьюмодель ничего не знает про View.

Дальше то, что отличает практика: пересоздание Activity при повороте и убийство процесса системой это разные вещи, и второе лечится SavedStateHandle, а не полем во вьюмодели. Про сборку упомяните R8 и профили запуска, если трогали их сами.

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

Называют архитектуру, но описывают код, где логика живёт во фрагменте, а вьюмодель хранит ссылку на View или на Activity. Это сразу и утечка, и невозможность написать тест, и первый же уточняющий вопрос это вскрывает.

Второе: не различают смену конфигурации и смерть процесса. Приложение, восстановленное системой через сутки, приходит с пустой вьюмоделью, и экран открывается в сломанном состоянии.

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