Retrofit & REST Interview Questions
DATA › Networking
Walk me through how you'd design the return type of your data-source methods that call Retrofit: do you let HttpException and IOException propagate, return Response<T>, or something else? What do you actually do and why?
What a strong answer covers: A strong answer wraps the call in a try/catch at the data-source boundary, catching IOException for connectivity failures and HttpException for non-2xx responses, and translates both into a sealed Result type with typed error cases the ViewModel can render directly, rather than leaking Retrofit-specific exception types up into the ViewModel or UI. The trap is returning a raw Response<T> everywhere or letting exceptions propagate uncaught and calling that 'error handling,' which couples UI-adjacent code to a specific networking library and makes it harder to test.
How do you test a class that calls a Retrofit service, without hitting a real network or fully mocking the Retrofit interface with Mockito?
What a strong answer covers: You spin up OkHttp's MockWebServer, enqueue canned responses including error codes, malformed JSON, and slow responses, and point a real Retrofit instance's baseUrl at it, so the actual converter and OkHttpClient pipeline run end-to-end against your code. This catches real serialization and error-handling bugs that mocking the Retrofit-generated interface directly would hide, since a Mockito mock only verifies your code's reaction to a hand-crafted return value rather than the real wire format and converter behavior.
Walk me through the trade-offs between Moshi and kotlinx.serialization as your Retrofit converter for a Kotlin-first app. When would you actually pick one over the other?
What a strong answer covers: kotlinx.serialization is compile-time and reflection-free via KSP, integrates natively if the data layer needs to be shared across Kotlin Multiplatform, and enforces strict serializable classes at compile time. Moshi, used with its codegen rather than reflection, has a longer track record for polymorphic and custom adapters and eases Java interop in mixed codebases or when parsing loosely-typed legacy JSON; the trap is defaulting to Gson out of habit, since its reflection-based approach is slower and gives weaker compile-time safety than either alternative.