Studio, Profilers & Firebase Interview Questions
BUILD & TOOLING › Delivery
Walk me through your process when a user reports 'the app is laggy' with no repro steps. How do you narrow down whether it's a rendering, memory, or I/O problem before you even open a specific profiler?
What a strong answer covers: A strong answer separates symptom categories before opening a profiler: when is it slow (cold start vs mid-scroll vs after backgrounding), what devices/OS versions are affected, and check Android Vitals or Crashlytics/Firebase Performance dashboards for ANR and slow-frame rates before assuming a single root cause. It should recognize that jank, ANR, and OOM/leak symptoms point to different capture types (system trace vs CPU profiler vs Memory Profiler), and that guessing which tool to open without narrowing the symptom first wastes profiling sessions.
LeakCanary flags a leak in a screen you don't own. How do you decide whether it's a real production risk versus noise, and how do you triage it without blocking the whole team's workflow?
What a strong answer covers: Should distinguish a genuine leaked Activity/Fragment held past its lifecycle with a large retained heap and a real reference path, from a short-lived object that's collected shortly after being flagged, by reading the leak trace's retained size and reference chain rather than treating every LeakCanary alert as a blocker. A strong answer also notes LeakCanary runs in debug builds and shouldn't gate CI or release builds directly, so the fix gets filed and owned as a normal bug rather than treated as an emergency that stalls the pipeline.
Baseline profiles need to be regenerated as the app changes. What's your strategy for keeping them fresh in a CI/CD pipeline, and what actually happens to startup performance if you let one go stale?
What a strong answer covers: Should describe generating profiles via Macrobenchmark's BaselineProfileRule as part of the release pipeline or a scheduled job so the profile tracks real critical user journeys as code changes, since a stale profile only covers old code paths and quietly stops helping. A strong answer notes the failure mode is graceful, not catastrophic: ART just falls back to JIT-compiling the uncovered hot paths, so startup and early-scroll jank regress silently, which is exactly why staleness goes unnoticed without ongoing measurement.