Don't neglect behavioral preparation — see our behavioral interview guide.
For technical interview preparation, our system design guide is essential reading.
Your resume is the first impression — get it right with our resume guide.
When offers arrive, consult our salary negotiation guide.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Android Engineer Interview Guide",
"description": "Android engineering interviews are a distinct category. They combine standard SWE fundamentals with deep mobile-specific knowledge: Activity lifecycle.",
"datePublished": "2026-03-23",
"author": {
"@type": "Organization",
"name": "CodeSwiftr Team"
},
"url": "https://codeswiftr.com/blog/android-engineer-interview-guide"
}
Related Reading
- AI Interview Practice Tools Comparison
- Amazon Leadership Principles Interview Guide
- The 30-Minute Daily Routine for FAANG Offers
- Airbnb Software Engineer Deep Dive
- Airbnb Software Engineer Interview Guide
Elevate your prep with AI. Practice your technical interviews with CodeSwiftr and get real-time feedback on your delivery, STAR method compliance, and technical depth.
Explore Related Topics
- 10 System Design Interview Tips That Actually Matter
- 10 Technical Interview Mistakes to Avoid (And What to Do...
- 25 Coding Patterns for Technical Interviews: A Visual Guide
Related Guides
- System Design Interview Guide
- Amazon Leadership Principles Interview Questions
- Behavioral Interview Star Method
Ready to practice? Start your free mock interview on CodeSwiftr.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is the Activity lifecycle in Android and why is it tested in interviews?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The Android Activity lifecycle defines how an Activity transitions through states as the user navigates. Key states: onCreate (initialize views and ViewModel, called once per Activity instance), onStart (Activity becomes visible), onResume (Activity is in the foreground and interactive), onPause (partially obscured — save lightweight state, pause animations), onStop (completely hidden — unregister heavy callbacks, pause background work), onDestroy (Activity is finishing or being recreated for config change). The critical interview question: What's the difference between onPause and onStop? onPause fires when another activity is in the foreground but the current activity may still be visible (e.g., a dialog or transparent activity above it). onStop fires when the activity is completely hidden. ViewModel survives configuration changes (screen rotation) but onDestroy is still called on rotation — distinguishing these is a common source of bugs."
}
},
{
"@type": "Question",
"name": "When should Android developers use WorkManager versus Foreground Services?",
"acceptedAnswer": {
"@type": "Answer",
"text": "WorkManager is for guaranteed background work that doesn't require immediate execution and can be deferred: database sync, uploading analytics, downloading content, sending logs. WorkManager respects battery optimization, persists tasks across app restarts and reboots, and supports constraints (only on WiFi, only when charging). Use WorkManager when the user doesn't need to know the work is happening. Foreground Services are for long-running operations that require user awareness — shown via a persistent notification: music playback, navigation, workout tracking, file download with progress. The distinction is user awareness: foreground services keep the user informed; WorkManager operates silently. Note: Services are generally discouraged for background work — WorkManager is the replacement for AsyncTask, IntentService, and most background Service uses."
}
},
{
"@type": "Question",
"name": "What is the difference between Fragment add and replace transactions?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Fragment add() keeps the existing Fragment in the container and adds the new Fragment on top — the existing Fragment remains in the lifecycle (onPause is not called) and its view is preserved in memory. Fragment replace() removes any existing Fragment from the container before adding the new one — the removed Fragment goes through onDestroyView and potentially onDestroy. Use add() for overlaying fragments (dialogs, bottom sheets). Use replace() for navigation where you want to swap content and avoid accumulating Fragment instances. The practical consequence: if you use add() for navigation, the back stack grows with Fragment instances that remain running in the background. For most navigation use cases, replace() is correct — or use Jetpack Navigation component which handles this correctly by default."
}
},
{
"@type": "Question",
"name": "How do you share data between Fragments in modern Android development?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The modern approach to Fragment-to-Fragment communication uses a shared ViewModel scoped to the Activity or a Navigation back stack entry. Both Fragments observe the same ViewModel's StateFlow — when Fragment A updates state, Fragment B observes the change automatically. This avoids direct Fragment-to-Fragment references (which create tight coupling and lifecycle issues). For Navigation component users, activityViewModels() gives the Activity-scoped ViewModel, while navGraphViewModels() gives a ViewModel scoped to a specific Navigation graph sub-graph. Avoid the older approach of passing data through the Activity via interfaces — it is verbose and does not survive configuration changes. Never call Fragment methods directly from another Fragment."
}
}
]
}