Explain Retrofit Interceptors and write a static API key interceptor
Tests OkHttp interception and application versus network scope. Strong answers build a new request adding X-Api-Key via newBuilder and chain.proceed; contrast addInterceptor once versus addNetworkInterceptor per hop.
What's really being asked
This question probes whether you understand that Retrofit delegates its HTTP layer to OkHttp, and that interceptors are OkHttp's hook for cross-cutting concerns like authentication, logging, and retry logic. The interviewer wants to see that you know the difference between application interceptors and network interceptors, and that you can correctly implement the chain of responsibility pattern without breaking the request flow.
The full answer
First, define the purpose: interceptors monitor, rewrite, and retry calls. Second, write the implementation by creating a class that implements Interceptor, obtaining the original request with chain.request(), building a new request via request.newBuilder().addHeader("X-Api-Key", "your_key").build(), and returning chain.proceed(newRequest). Third, explain that chain.proceed is where all HTTP work happens and must be called exactly once per interceptor pass unless you are explicitly retrying, in which case previous response bodies must be closed. Fourth, contrast registration methods: addInterceptor is an application interceptor that runs once on the original request and sees the final redirected response, while addNetworkInterceptor runs once per network hop and exposes lower-level details like the Connection object and raw headers such as Accept-Encoding.
The mistakes people make
A major red flag is mutating the original request object instead of building a new one with the builder. Another is forgetting to call chain.proceed and returning a synthetic response without continuing the chain, which breaks the entire stack. Some candidates incorrectly treat interceptors as Retrofit annotations or claim they belong to Retrofit rather than OkHttp. Also, failing to mention that multiple interceptors execute in the order they were added is a sign of shallow knowledge.
What usually comes next
The interviewer may ask how you would refresh an OAuth token on a 401 response, which requires a careful retry pattern with response body closing. They might ask when to choose a network interceptor over an application interceptor, such as when you need to observe raw gzip-encoded bodies or per-hop metrics. Another follow-up is how to avoid adding the API key to specific requests, which you can handle by checking request headers or tags before mutation.
A concrete example
Suppose you register your API key interceptor via OkHttpClient.Builder().addInterceptor(ApiKeyInterceptor("abc123")).build(). When you call a Retrofit endpoint that hits http://example.com/data and receives a 302 redirect to https://example.com/data, the application interceptor runs once and chain.proceed returns the final 200 OK from the HTTPS URL. If you had used addNetworkInterceptor instead, the interceptor would run twice: once for the HTTP 302 and once for the HTTPS 200, logging two separate connections.
Interview question
When an API key interceptor is registered with addInterceptor and the call encounters a 302 redirect, what occurs?
- a.The interceptor is bypassed for the redirected request and the API key header is dropped.
- b.The interceptor runs twice, once for the 302 and once for the final request.
- c.The interceptor runs once and chain.proceed returns the final response after following redirects.Correct
- d.The interceptor must manually call chain.proceed for each hop to follow the redirect.
Why? this is the answer
addInterceptor registers an application interceptor, which runs exactly once and chain.proceed returns the final post-redirect response. Option B describes network interceptor behavior with addNetworkInterceptor, and option D is wrong because OkHttp handles redirects internally after the single proceed call.
Just read this? Test yourself on what you have been reading.
Read the original → square.github.io
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles