Почему используете Dagger или Hilt для DI
Что проверяют
Понимаете ли вы, зачем нужен DI сам по себе, и почему на Android победила генерация графа на этапе компиляции, а не рефлексия. Отдельно проверяют, отличаете ли вы Hilt как надстройку с готовыми привязками к жизненному циклу от Dagger как универсального генератора.
Как отвечать
Начните с сути: класс получает зависимости снаружи и не знает, как они созданы. Это даёт подмену реализации в тестах и границу между слоями. Дальше объясните, почему именно Dagger: граф зависимостей собирается кодогенерацией при сборке, поэтому пропущенная привязка ломает компиляцию, а не падает у пользователя, и в рантайме нет затрат на рефлексию.
Hilt поверх Dagger снимает основную боль Android: компоненты уже определены и привязаны к жизненным циклам, от SingletonComponent на уровне Application до ViewModelComponent. Экраны создаёт система, поэтому им нужна точка входа: @AndroidEntryPoint на Activity и Fragment, @HiltViewModel на ViewModel, конструкторная инъекция везде, где объект создаём мы сами. Интерфейсы связываются через @Binds, он дешевле @Provides, потому что не порождает тело метода.
Полезно добавить границу применимости: на маленьком проекте ручной DI через фабрику решает ту же задачу, а Koin переносит проверки в рантайм, обменивая скорость сборки на позднее обнаружение ошибок.
Где спотыкаются
Называют главным преимуществом производительность приложения. DI не ускоряет бизнес-логику, он убирает рефлексию и ручную сборку объектов. Выигрыш в предсказуемости и в том, что ошибка графа видна при сборке.
Путают DI с сервис-локатором. Если класс сам достаёт зависимость из глобального объекта, внешне похоже, но подменить её в тесте так же трудно, как и раньше. Инъекция через конструктор делает зависимости видимыми в сигнатуре.
Раздают @Singleton всему подряд и держат в долгоживущем объекте ссылку на Activity или её контекст. Такой объект живёт до конца процесса и не даёт освободить экран, для контекста есть отдельная квалификация @ApplicationContext. Рядом лежит вопрос про сборку: связка с kapt заметно замедляет билд, и переход на KSP снимает значительную часть накладных расходов.