App Startup Time Interview Questions

PERFORMANCE › Runtime

Walk me through your approach to reducing cold-start time on an app where Application.onCreate() has ballooned to include a dozen SDK initializations.

What a strong answer covers: A strong answer triages by measuring which initializers are actually on the critical path to first frame, via Perfetto/systrace, versus which can be deferred, then moves non-essential SDK init off the synchronous Application.onCreate path using lazy initialization, App Startup Initializer dependency ordering, or deferring work to after first frame/reportFullyDrawn on a background dispatcher. Should call out that not every SDK is safe to defer, a crash reporter needs to be live early, so the strategy is prioritization by risk and impact, not blanket deferral.

When is TTID actually a misleading metric for user-perceived startup performance, and why might a team optimizing for TTID make the app feel worse to use?

What a strong answer covers: TTID is satisfied the moment the first frame is drawn, which can happen while the screen shows a mostly-empty layout, skeleton, or placeholder, so a team can hit a great TTID number while the actual content the user came for loads afterward and the app still feels slow. A strong answer names TTFD, signalled via reportFullyDrawn(), as the metric that reflects when content is actually usable, and warns that gaming TTID by rendering a blank frame early is a classic Goodhart's-law failure.

You've added lazy initialization and baseline profiles, and TTID hasn't moved much, but users still say the app 'feels slow to open'. What are you missing?

What a strong answer covers: Points to things outside pure launch-to-first-frame timing: a splash screen that doesn't transition smoothly, a jarring layout shift once real content replaces a placeholder, network-bound content loading after first frame with no loading state, or reportFullyDrawn() simply never being called so TTFD and Vitals data don't reflect reality at all. A strong answer stresses startup is a perceived-performance problem as much as a raw-timing one, so profiling numbers alone aren't enough without watching an actual user session.

Back to App Startup Time