AndroidHire

Android Hilt Interview Questions

Dependency injection fundamentals, scopes, and modules.

50 questions in this topic · 8 sample questions below

Practice Hilt in the quiz engine

Sample questions

  1. What is the fundamental difference between Dependency Injection and the Service Locator pattern?

    • DI passes dependencies to an object from outside, while a service locator has the object request dependencies from a central registry — correct
    • DI works only at runtime while a service locator works only at compile time
    • They are identical patterns with different names used by different frameworks
    • A service locator injects via constructors while DI injects via fields

    Why: With DI, dependencies are supplied externally so the class does not know where they come from; with a service locator the class actively pulls from a registry, hiding its dependencies. They are not the same pattern, and the constructor-versus-field distinction is orthogonal to both.

  2. Why must Hilt use field injection for Activities and Fragments rather than constructor injection?

    • Because field injection is faster than constructor injection on Android
    • Because the Android framework instantiates these components itself, so Hilt cannot supply constructor arguments — correct
    • Because Activities and Fragments are singletons and singletons cannot use constructors
    • Because constructor injection is not supported by Dagger at all

    Why: The OS constructs Activities and Fragments through their no-arg constructors, so Hilt has no chance to pass dependencies in and must inject into fields after creation. Constructor injection is fully supported by Dagger elsewhere; the limitation is purely that the framework owns instantiation.

  3. A key advantage of Hilt and Dagger over Koin is that they:

    • Resolve the dependency graph lazily at runtime, reducing startup cost
    • Require no annotations anywhere in the codebase
    • Validate the dependency graph at compile time, so missing or duplicate bindings fail the build — correct
    • Automatically generate ViewModels without any annotations

    Why: Hilt and Dagger build and verify the object graph during compilation, turning missing bindings into build errors rather than crashes. Koin resolves at runtime, so those same problems surface as exceptions when the code path executes, not at compile time.

  4. When does a missing dependency typically surface in Koin versus Hilt?

    • Koin fails at compile time; Hilt fails at runtime
    • Both fail at compile time identically
    • Both fail only at app install time
    • Koin fails at runtime when the dependency is resolved; Hilt fails at compile time during the build — correct

    Why: Koin uses runtime resolution, so an unresolved definition throws a NoBeanDefFoundException only when that code runs. Hilt's annotation processor detects the same gap during the build, failing compilation before the app ever launches.

  5. What is the primary difference between @Binds and @Provides in a Hilt module?

    • @Binds tells Hilt which implementation to use for an interface and generates less code, while @Provides supplies an instance via a method body you write — correct
    • @Binds only works in the SingletonComponent while @Provides works anywhere
    • @Binds is for singletons and @Provides is for factories
    • They are completely interchangeable with no difference in generated code

    Why: @Binds is an abstract method that simply maps an interface to an implementation Hilt already knows how to construct, so no factory implementation is generated. @Provides requires a concrete method body and produces additional generated code, and the two are not interchangeable in behavior or efficiency.

  6. Why can a @Binds method be abstract while a @Provides method cannot?

    • @Binds methods run on a background thread and cannot have a body
    • @Binds only records a type-to-implementation mapping, so Hilt needs no method body to execute — correct
    • Abstract methods are always faster, so Hilt forces @Binds to be abstract
    • @Provides is deprecated and only kept for backward compatibility

    Why: @Binds merely declares that requests for the supertype should be satisfied by an already-injectable subtype, information Hilt encodes without invoking any code. @Provides must actually construct or obtain the instance, which requires a concrete body; it is not deprecated.

  7. You depend on a Retrofit interface from a third-party library and cannot annotate its constructor. How do you make it injectable in Hilt?

    • Add @Inject to the library class using reflection at runtime
    • Use @Binds to map it since Hilt can construct any class
    • Write a @Provides method in a module that builds and returns the instance — correct
    • Mark the module class with @Singleton and Hilt will auto-create it

    Why: For types you do not own and cannot add @Inject to, @Provides lets you supply a constructed instance through a method you control. @Binds cannot be used because Hilt still would not know how to construct the underlying implementation, and there is no reflection-based @Inject injection.

  8. By default, how many instances does Hilt provide when an unscoped binding is requested multiple times?

    • One shared instance for the whole application
    • It throws an error because every binding must be scoped
    • One instance per Activity automatically
    • A new instance every time the binding is requested — correct

    Why: Unscoped bindings are not cached, so Hilt creates a fresh instance for each injection request. Sharing a single instance requires an explicit scope annotation such as @Singleton; unscoped is the default and is perfectly valid.

Practice all 50 Hilt questions

These 8 are a sample. The full Hilt bank is scored, tracks your progress, and explains every answer.

Open the quiz

More Android interview topics