How would you implement a constrained photo upload with WorkManager?
Tests knowledge of WorkManager constraints and retry policies for deferrable background uploads. A strong answer names OneTimeWorkRequest with Constraints for charging and unmetered network, plus BackoffPolicy for retry.
What's really being asked
This question evaluates whether you understand the modern Android background execution model and when to use WorkManager versus foreground services or AlarmManager. Specifically, it checks if you know how to express constraints, pass data into a worker, handle retries, and persist work across process death without leaking resources or draining battery.
The full answer
First, subclass CoroutineWorker or Worker and override doWork to perform the upload on a background thread. Second, build a Constraints object using Constraints.Builder and call setRequiredNetworkType(NetworkType.UNMETERED) and setRequiresCharging(true). Third, construct a OneTimeWorkRequest, attach the constraints, set input data with setInputData for the photo URI, and configure retry behavior with setBackoffCriteria using BackoffPolicy.EXPONENTIAL and a delay of at least ten seconds. Fourth, enqueue the request with WorkManager.getInstance and optionally tag it for observation or cancellation. Fifth, mention that WorkManager handles process death automatically and respects Doze and App Standby buckets without additional code.
The mistakes people make
Suggesting a ForegroundService is a red flag because the task is deferrable and does not need to run immediately while the app is visible. Using AlarmManager or a raw JobScheduler also signals a gap in modern architecture knowledge because WorkManager is the recommended abstraction for deferrable guaranteed work. Another red flag is forgetting to set the network constraint or using NetworkType.CONNECTED instead of UNMETERED, which would burn user data. Failing to mention retry or claiming Android will auto-retry without an explicit BackoffPolicy is also incorrect. Claiming the work runs in real time is wrong because WorkManager is for deferrable execution.
What usually comes next
How would you observe the work status from the UI using LiveData or Flow? How would you handle a requirement to retry only three times? What is the difference between Worker and CoroutineWorker? How does WorkManager behave on devices running API 23 versus API 26 and above? Can you expedite this work, and what are the restrictions on expedited work in recent Android versions?
A concrete example
Imagine a user selects a photo in a social app. You create an UploadWorker class extending CoroutineWorker. Inside doWork you read the URI from inputData, open an OkHttp request body, and stream the bytes. You return Result.success if the server responds with HTTP 200, or Result.retry if it returns a 5xx error. You build constraints requiring UNMETERED and charging. You set backoff to EXPONENTIAL with ten seconds. You enqueue the work. Even if the user force-stops the app, WorkManager reschedules the upload when constraints are met.
Interview question
When implementing a deferrable photo upload that must avoid metered data and survive process death, which approach follows modern Android best practices?
- a.Build a OneTimeWorkRequest with NetworkType.CONNECTED and rely on the system to auto-retry on failure
- b.Use a ForegroundService that acquires a WakeLock and retries the upload in a loop until it succeeds
- c.Use JobScheduler directly with JobInfo.Builder requiring an unmetered network and device charging
- d.Subclass CoroutineWorker, require unmetered network and charging, pass the URI via input data, and set exponential backoffCorrect
Why? this is the answer
Subclassing CoroutineWorker with UNMETERED and charging constraints, input data for the URI, and exponential backoff matches the recommended pattern. Option A is tempting because it uses WorkManager, but CONNECTED wastes metered data and the system does not auto-retry without an explicit BackoffPolicy.
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