Storage interview questions
Storage questions a Mobile developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What belongs in the app’s simple key-value preferences, and what does not?
The strongest answer: Small flat values the app reads at startup: a chosen theme, a flag, the last tab. Not records or lists you need to query or update one at a time, and not secrets
Why it works: Exactly — it is a settings file, so the test is “small, flat, and read whole”.
- Preferences are for small flags.
- Keep values small and flat.
- Records belong in a database.
- Secrets belong in secure storage.
Where do you put a session token on device?
The strongest answer: In the platform secret store — Keychain / EncryptedSharedPreferences or equivalent — not in plain SharedPreferences, UserDefaults, or a world-readable file
Why it works: Exactly. Tokens are secrets. Use the encrypted store; never log them.
- Use Keychain / encrypted prefs.
- Do not put tokens in plaintext storage.
- Do not log tokens.
- Do not bake secrets into the binary.
The app keeps a few thousand orders offline in one JSON file it rewrites on every change. When do you move to a local database?
The strongest answer: When you need to query, sort or page part of it, update one record without rewriting everything, or survive being killed mid-write. A database gives you indexes and transactions; a file gives you neither
Why it works: Right — the trigger is the shape of the access, not the size. Partial reads, partial writes and durability are the tests.
- Files cannot query or transact.
- Move when you query or page.
- Update rows, not whole files.
- Transactions survive a kill.
Downloaded receipts disappear from some users’ phones after a while. Downloaded images never do.
What is the likely cause?
The strongest answer: The receipts were written to the cache directory, which the system may purge when storage runs low. Anything the user would miss goes in the app’s documents area; anything you can fetch again belongs in cache
Why it works: Exactly — the directory you choose is a promise about durability, and re-downloadable files should not be making that promise.
- Cache may vanish; documents stay.
- Cache anything you can re-fetch.
- Documents for what the user would miss.
- Exclude re-fetchable files from backup.
A security review asks exactly which of the app’s data leaves the phone in the platform’s automatic backup.
What do you answer?
The strongest answer: That app files are backed up by default, so I list what we write, exclude caches and anything derived, keep secrets in the platform’s secure store, and check it on a device restored from a backup
Why it works: Exactly — default-on is the key fact, and a restore test is the only way to know what the list really is.
- Backups copy your files by default.
- List everything the app writes.
- Exclude caches and derived data.
- Verify on a restored device.
A release changes the local schema. The shortcut on the table is dropping the database and downloading everything again.
What is your position?
The strongest answer: Not if any local data is the only copy — unsent edits, queued uploads, anything the server has not got. Write the migration, test it from every shipped version, and rebuild only what we can fetch again
Why it works: Right, and the detail that saves you is testing the upgrade from versions you forgot were still out there.
- Local data may be the only copy.
- Migrate from every shipped version.
- Test upgrades, not fresh installs.
- Rebuild only what you can re-fetch.