С какими библиотеками для работы с зависимостями (Dagger) работал

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

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

Как отвечать

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

Назовите то, чем реально пользовались: @Inject на конструкторе, @Module с @Provides для чужих классов, @Binds для привязки реализации к интерфейсу, компоненты и области видимости, мультибиндинг для наборов обработчиков, отложенные и фабричные поставщики для объектов с параметрами времени выполнения.

Дальше про Hilt: это надстройка с готовыми компонентами под жизненный цикл Android, от уровня приложения до экрана и модели представления. Она снимает ручную сборку компонентов и задаёт единые имена, а точка входа позволяет достать зависимость там, куда внедрение не дотягивается.

Полезно сравнить с Koin: там граф собирается во время выполнения, писать проще, но отсутствие зависимости всплывает уже при запуске приложения.

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

Вешают одну область видимости на всё подряд. Объект со ссылкой на экран живёт столько же, сколько приложение, и получается утечка, которую потом ищут профилировщиком памяти.

Вторая ошибка: не различают поставщика и привязку. Интерфейс без указанной реализации даёт длинную ошибку сборки про отсутствующий способ создания, и кандидат, не прочитавший её внимательно, начинает наугад добавлять модули.

Третья: путают внедрение зависимостей с локатором служб. Когда класс сам достаёт нужное из общего хранилища, подменить его в тесте уже нельзя, а именно ради тестируемости всё и затевалось.