Interview guides / android

Meta-Style Android Interview Questions

Unofficial Meta-style Android interview prep: Compose lists, caching, architecture, and mobile product tradeoffs.

Unofficial only. Not affiliated with Meta.

Expect Compose list performance, unidirectional state, networking/caching judgment, and coding that stays readable under time pressure.

1. 1.How do you keep a Compose feed smooth with images?

   Stable keys in LazyColumn, remember expensive state, decode off main, bound concurrency, prefetch near viewport, and avoid recomposing whole trees on tiny state changes.

2. 2.Explain UDF/MVI for an engagement-heavy screen.

   Events in, reduce immutable state, render. Side effects like navigation/toasts are explicit so they do not fire twice on recomposition. StateFlow or similar as single source of truth.

3. 3.What causes ANRs, and how do you diagnose them?

   ANRs happen when the main thread is blocked (~5s for input). Avoid disk/network on Main; use coroutines. Diagnose with ANR traces, StrictMode, and Systrace/Perfetto. Mention BroadcastReceiver and Service timeouts too.

4. 4.Security difference between implicit and explicit intents?

   Explicit targets a component. Implicit resolve by filters—risk of interception. Use explicit for internal navigation; validate incoming intent extras.

5. 5.Why specify FLAG_IMMUTABLE/MUTABLE on PendingIntents?

   Required on modern APIs for security. Prefer IMMUTABLE unless you must update extras; prevents intent redirection attacks.

6. 6.What are Entity, DAO, and Database in Room?

   Entity=table, DAO=queries, Database=holder. Use suspend/Flow queries; type converters carefully; migrations mandatory for schema changes.

7. 7.What belongs in a ViewModel vs UI layer?

   UI state and business orchestration surviving rotation. No Android framework Views, no Context leaks (use Application context carefully). Expose immutable UI state flows.

8. 8.How do you expose Retrofit APIs with suspend functions?

   suspend endpoints return body/Response; map errors via HttpException. Prefer repository layer; use Call adapters carefully.

9. 9.How do UI test stacks differ?

   Espresso for Views; Compose testing APIs for semantics nodes. Prefer idling resources/synchronization; keep UI tests for critical paths.

10. 10.Difference between remember and rememberSaveable?

    remember survives recomposition only. rememberSaveable also survives config change via saveable registry. Neither survives process death unless backed by SavedState.

11. 11.Design the rider Android app: maps, realtime location, trip state machine, payments, offline resilience. Thorough client design with diagram-level components and explicit tradeoffs.

    ## Overview Mirror a server-authoritative trip state machine on device, stream location separately from command APIs, and degrade honestly offline. ## Architecture diagram ```mermaid flowchart TB UI[Map + Trip Compose UI] --> VM[TripViewModel] VM --> Domain[TripSession use case] Domain --> Repo[TripRepository] Repo --> REST[Trip REST] Repo --> RT[Location Flow/WebSocket] Repo --> Room[(Room)] Pay[Payments] --> VM ``` ## Architecture UDF/MVVM: TripViewModel exposes immutable UI state; TripSession domain owns transitions. Maps SDK behind an interface. Hilt injection. Foreground service only while trip requires it and policy allows. ## Networking REST commands with idempotency; realtime socket for locations/events; OkHttp authenticator; reconnect backoff; polling fallback. ## Storage & caching Room history; DataStore activeTripId; last location cache; no sensitive payment storage. ## Offline mode Show last state offline; queue cancel; block new requests; reconcile version on reconnect. ## Performance Throttle map invalidations; fused location intervals by phase; sample UI collect at 1–2 Hz; battery budgets; Baseline profiles. ## Tradeoffs ### Trip authority **Option A — Server authoritative:** Correct dispatch/money; client may lag. **Option B — Client authoritative:** Feels instant; desync risk. **Pick A when:** Always. **Pick B when:** Never for dispatch. ### Realtime transport **Option A — WebSocket:** Low latency; connection ops. **Option B — Polling:** Simple; laggy. **Pick A when:** Live tracking core. **Pick B when:** Early MVP. ### Foreground service **Option A — In-trip FS:** Reliable updates; UX/notification cost. **Option B — No FS:** Less reliable background. **Pick A when:** Active ongoing trip. **Pick B when:** Browsing only.

12. 12.Design a robust Android networking layer: auth, refresh, retries, errors, caching, testability.

    ## Overview A single APIClient with interceptor pipeline and protocol boundaries keeps features testable and consistent. ## Architecture diagram ```mermaid flowchart TB VM --> Repo --> APIClient APIClient --> Auth[Auth Interceptor] APIClient --> Retry[Retry Policy] APIClient --> Session[OkHttp/Retrofit] Auth --> EncryptedStorage/DataStore Repo --> DTO[DTO mapper] ``` ## Architecture Features depend on repositories/protocols. APIClient handles auth header, redacted logs, refresh single-flight (actor). Map transport errors to domain errors for ViewModels. ## Networking One session config; refresh-on-401 once; retry idempotent GETs only by default; timeouts; optional pinning for high risk. ## Storage & caching Tokens EncryptedStorage/DataStore; URLCache where safe; DTO≠domain; per-endpoint TTL policies. ## Offline mode ConnectivityManager fail-fast OfflineError; writes use feature outboxes—not generic HTTP magic. ## Performance Cancel on disappear; coalesce duplicate GETs; measure p95; HTTP/2. ## Tradeoffs ### Refresh strategy **Option A — Refresh on 401:** Lazy; can stampede without single-flight. **Option B — Proactive refresh:** Fewer mid-flight failures; more refresh traffic. **Pick A when:** With single-flight lock. **Pick B when:** Short-lived tokens with predictable expiry. ### Library vs OkHttp/Retrofit **Option A — OkHttp/Retrofit:** First-party, enough for most. **Option B — Alamofire/etc:** Faster extras; dependency cost. **Pick A when:** Default modern apps. **Pick B when:** Team already standardized on a lib.