AndroidHire

Android WorkManager & Background Interview Questions

Deferred work, constraints, and background limits.

50 questions in this topic · 8 sample questions below

Practice WorkManager & Background in the quiz engine

Sample questions

  1. You need a background task that must complete even if the user closes the app or the device reboots, but it does not need to run at an exact time. Which API is the best fit?

    • A plain coroutine launched in a ViewModel scope
    • WorkManager — correct
    • AlarmManager with setExact
    • A bound Service

    Why: WorkManager is designed for deferrable, guaranteed work that survives process death and reboot by persisting requests in its own database. A ViewModel-scoped coroutine is tied to the UI lifecycle and is cancelled when the app is killed, so it offers no guarantee.

  2. Which statement about WorkManager and JobScheduler is accurate on modern Android?

    • WorkManager replaces JobScheduler entirely and never uses it
    • JobScheduler is only available below API 21
    • WorkManager uses JobScheduler as its underlying scheduler on API 23+ — correct
    • WorkManager and JobScheduler cannot coexist in the same app

    Why: On API 23 and above WorkManager delegates to JobScheduler under the hood, falling back to alarms plus broadcast receivers on older APIs. It is a higher-level abstraction over the platform schedulers, not a total replacement that ignores them.

  3. A message needs to be delivered to the device the instant a server event happens, even when the app is not running. Which is the correct primary mechanism?

    • A PeriodicWorkRequest polling every 15 minutes
    • Firebase Cloud Messaging (FCM) — correct
    • WorkManager expedited work triggered by a timer
    • AlarmManager waking up to poll the server

    Why: Real-time server-initiated pushes are FCM's purpose; the server tells the device when something happens. Polling with periodic work cannot be instant because of the 15-minute floor and batching, and it wastes battery.

  4. For a simple one-off network call that only needs to run while the user is on the current screen and can be discarded if they leave, what is usually the right tool?

    • WorkManager OneTimeWorkRequest
    • AlarmManager
    • A coroutine in viewModelScope — correct
    • A PeriodicWorkRequest

    Why: If the work is tied to the UI and does not need to survive the app being closed, a viewModelScope coroutine is simpler and lighter. WorkManager adds persistence overhead that is unnecessary and even counterproductive for screen-scoped work.

  5. What is the minimum repeat interval allowed for a PeriodicWorkRequest?

    • 15 minutes — correct
    • 5 minutes
    • 1 minute
    • 1 hour

    Why: The system enforces a hard 15-minute minimum interval for periodic work to conserve battery. The belief that it can fire every minute is a common misconception; anything shorter than 15 minutes is clamped up to 15.

  6. A developer schedules a PeriodicWorkRequest with a 15-minute interval and expects it to run precisely every 15 minutes. Why is this expectation wrong?

    • Periodic work only ever runs once
    • The interval is measured in seconds, not minutes
    • Periodic work requires the app to be in the foreground
    • The interval defines a window in which the system may run the work, not an exact firing time — correct

    Why: WorkManager batches and defers periodic executions to respect Doze and battery optimizations, so the interval is a repeating window rather than a precise schedule. WorkManager is not intended for exact timing; use AlarmManager with setExactAndAllowWhileIdle for that.

  7. What is the flexInterval parameter of a PeriodicWorkRequest?

    • A window at the end of each repeat interval during which the work is eligible to run — correct
    • The exact time the work fires
    • The maximum number of retries
    • The backoff delay between attempts

    Why: flexInterval defines a flex window at the tail of each repeat interval where WorkManager may schedule the run, giving the system flexibility to batch. It is not an exact firing time and is unrelated to retries or backoff.

  8. After a device reboot, what happens to work that was enqueued but not yet run?

    • It is lost and must be re-enqueued manually
    • WorkManager reschedules it automatically because requests are persisted — correct
    • Only periodic work survives, one-time work is dropped
    • It runs immediately during boot before the UI loads

    Why: WorkManager persists requests in its database and a boot receiver reschedules pending work after a reboot. Both one-time and periodic requests survive; nothing needs to be re-enqueued by the app manually.

Practice all 50 WorkManager & Background questions

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

Open the quiz

More Android interview topics