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

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

Умеете ли вы принимать архитектурные решения и объяснять их, а не только работать в готовом каркасе. Интервьюеру важны причины выбора и то, что вы сделали бы иначе сейчас. Следом почти всегда звучит: «Почему именно эта библиотека, а не альтернатива?»

Как отвечать

Отвечайте на своём примере, со своими цифрами. Удобный каркас:

• контекст: что за приложение, размер команды, сроки, minSdk, были ли готовы бэкенд и дизайн-система;
• архитектура: например, слои по руководству Google (UI, опциональный domain, data), MVVM или MVI, одна Activity и Navigation Compose, модули по фичам и общий core;
• зависимости с причинами: Jetpack Compose или View, Hilt или Koin, Retrofit с OkHttp или Ktor, kotlinx.serialization, Room, корутины и StateFlow, Coil. К каждому пункту одна фраза, почему он;
• инфраструктура: version catalog libs.versions.toml, convention-плагины Gradle, CI, линтеры, сбор крэшей;
• результат и ретроспектива: время сборки, crash-free, скорость выпуска новых фич и что бы вы поменяли сейчас.

Критерии выбора библиотеки назовите явно: жива ли она, лицензия, влияние на размер APK и время сборки, совместимость с Kotlin Multiplatform, если он в планах, знакома ли команде.

Если с нуля вы не начинали, так и скажите, а потом покажите близкий опыт: спроектировали новый модуль, перевели экраны на Compose, собрали пет-проект. Добавьте, как подошли бы к выбору в их условиях. Честный ответ с разбором решений ценится выше выдуманного проекта.

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

Перечисляют библиотеки без причин. «Взял Retrofit, Room, Hilt» звучит как шаблон проекта, а не как решение.

Приписывают себе всё. Если архитектуру выбирал лид, скажите, какую часть решали вы и где спорили.

Описывают избыточную архитектуру для MVP: двадцать модулей и use case на каждый вызов API при трёх экранах. Интервьюер это заметит и спросит, окупилось ли.