Skip to content
RED SAGSkills
hardMobile App Developer interview question

Your crash reports show rising out-of-memory crashes after a release. How do you find and fix the problem?

What the interviewer wants to hear

  • Use crash data to narrow the version, devices and user flows
  • Reproduce the flow and profile memory over repeated navigation
  • Use LeakCanary, Android Studio Profiler, Xcode Memory Graph or Instruments
  • Common causes: retained contexts, retain cycles, listeners, large bitmaps, caches
  • Fix, add tests or checks, and verify with staged rollout metrics

Model answer

First I narrow it down with data: which version introduced it, which devices, and what breadcrumbs or screens appear before the crash. Rising OOMs after many minutes usually mean a leak, while instant OOMs on one screen point to huge allocations like full-size bitmaps. Then I reproduce the flow, for example opening and closing the product screen twenty times, while watching memory in Android Studio Profiler or Xcode Instruments. If memory climbs and never returns, I take a heap dump or use the Xcode Memory Graph to see which objects are retained and by what. LeakCanary helps catch Android leaks automatically in debug builds. Typical causes are closures capturing self strongly, unregistered listeners, static references to an Activity, unbounded caches and undecoded large images. After fixing, I watch the OOM rate in the staged rollout before releasing to everyone.

Can you answer it under time pressure?

Take a timed hard round and get scored on every answer.

Start mock interview

More hard Mobile App Developer questions