Chain WorkManager tasks and pass a file URI between workers.
This tests WorkManager chaining and data passing. A strong answer chains Download, Unzip, and Process with WorkContinuation, passes URI via outputData, and reads it with inputData. A red flag is suggesting global state, SharedPreferences, or thread blocking.
What's really being asked
The interviewer wants to know if you understand WorkManager beyond simple one-off tasks. Specifically, they are testing two things: first, whether you know how to use WorkContinuation to build dependent chains so that work executes sequentially; second, whether you understand the correct mechanism for passing lightweight data between workers using Data objects rather than external mutable state. At the senior level, they also care if you recognize the constraints of Data, such as the 10 KB size limit, and whether you know how to handle failure propagation in a chain.
The full answer
A strong response starts by describing a chain created with WorkManager.getInstance(context).beginWith(downloadWorkRequest).then(unzipWorkRequest).then(processWorkRequest).enqueue(). It then explains that the DownloadWorker computes the file URI and packages it into a Data object using Data.Builder, then returns Result.success(outputData). The UnzipWorker receives this payload through its inputData and extracts the URI with inputData.getString(KEY_URI). The candidate should mention that WorkManager guarantees the chain runs in order and that each worker runs only after the previous one succeeds. They should also note that Data is intended for small payloads only and that large files should be referenced by URI or file path rather than being passed as byte arrays.
The mistakes people make
Red flags include suggesting static variables, SharedPreferences, or an event bus to communicate the URI between steps. These break when the process dies and WorkManager reschedules work. Another mistake is trying to pass the actual file bytes through Data, which will crash or fail due to the 10 KB limit. Some candidates also suggest calling enqueue separately on each WorkRequest without chaining, which destroys the ordering guarantee. Finally, returning Result.failure without explaining how it halts the chain is a gap senior interviewers notice.
What usually comes next
The interviewer may ask what happens if the download worker returns Result.failure. The correct answer is that the chain halts unless you have configured a unique work policy or used an observer to retry. They might also ask how to run unzip and process in parallel after download, which requires using then with a list of OneTimeWorkRequests. Another common follow-up is how to tag workers for cancellation or how to observe chain progress using LiveData or Flow.
A concrete example
Imagine downloading a 50 MB zip of user assets. The DownloadWorker writes the file to context.cacheDir and produces outputData with putString("zip_uri", file.toURI().toString()). The UnzipWorker reads inputData.getString("zip_uri"), extracts entries to a folder, and outputs putString("folder_path", folder.getAbsolutePath()). The ProcessWorker reads "folder_path" and uploads parsed metadata. The entire chain is built with beginWith(download).then(unzip).then(process) and observed via WorkManager.getWorkInfosForLiveData to show a notification progress bar.
Interview question
In a WorkManager chain, what is the correct way to pass a file URI from one worker to the next?
- a.Enqueue each request separately and broadcast the URI via an application event bus
- b.Write the URI to SharedPreferences in the first worker and read it in the second
- c.Store the URI in a static variable shared between the worker classes
- d.Return the URI in a Data object via Result.success and read it from the next worker's inputDataCorrect
Why? this is the answer
WorkManager guarantees sequential execution and delivers Data payloads across outputData and inputData, surviving process restarts. SharedPreferences might seem persistent but is external mutable state that can become stale or race when WorkManager reschedules work after process death.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
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