Android Engineer Interview Questions in India (2026)

Android Engineer roles in India are consistently in demand, with knok jobradar tracking 89 open positions as of July 2026. Bangalore leads with 16 openings, followed by Delhi with 12. Whether you are a fresher targeting your first app-dev role or a senior engineer eyeing a tech lead position, interviews tend to follow a recognisable pattern: a technical screen, one or two coding and system design rounds, and a final behavioural discussion.

This guide covers the questions candidates commonly report facing, the concepts most likely to come up, and a realistic plan to get interview-ready in two to four weeks.

1. Design a rate limiter for an API serving millions of requests per day.
2. Explain a production incident you debugged. What was root cause?
3. How do you approach system design for high availability?
4. Walk through a code review where you caught a serious bug.
5. Trade-offs between SQL and NoSQL for a payments ledger.
6. How do you estimate task complexity for a sprint?

Q: Explain the Android Activity lifecycle. What happens when the user presses Home vs Back?

The Activity lifecycle has six core callbacks: onCreate, onStart, onResume, onPause, onStop, and onDestroy. When the app is running and the user presses Home, Android calls onPause then onStop, but the Activity stays in memory unless the system needs to reclaim resources. When the user returns, onRestart, onStart, and onResume are called in sequence. Pressing Back calls onPause, onStop, and then onDestroy, removing the Activity from the back stack entirely. This distinction matters for saving state: use onSaveInstanceState to preserve data that must survive a Home press, and clean up resources in onDestroy that should not linger.

---

Q: Your app takes more than five seconds to open on mid-range devices. Walk me through how you would diagnose and fix this.

First, I would profile the startup using Android Studio's CPU Profiler and App Startup Tracing to find exactly where time is being spent. Common culprits are heavy work on the main thread in Application.onCreate or the first Activity's onCreate, synchronous network calls at launch, and loading large bitmaps before the first frame is drawn. After identifying the bottleneck, I would move heavy initialisation to a background thread or use Jetpack App Startup to defer non-critical libraries. I would also enable StrictMode during development to catch any blocking I/O on the main thread.

---

Q (Behavioural): Tell me about a time you found a critical bug close to a release deadline. What did you do?

*Situation:* Three days before a major release, I discovered that our payment confirmation screen was silently failing for users on Android 9 due to a deprecated API we had not replaced.

*Task:* I needed to fix it without breaking the feature on newer OS versions, while the rest of the team was finishing other last-minute work.

*Action:* I added a version check to route Android 9 users through a fallback path, wrote targeted unit tests to cover both code paths, and flagged the affected build in our internal testing channel so QA could re-verify the flow that same afternoon.

*Result:* The fix was merged within a few hours, QA signed off the next morning, and the release went out on schedule with no payment-related crashes reported in the first week after launch.

STAR for behavioural questions: 20% situation, 10% task, 50% action, 20% result with numbers.

CIRCLES for product cases (PM): Comprehend, Identify customer, Report needs, Cut through prioritisation, List solutions, Evaluate trade-offs, Summarise recommendation.

For system design (engineering): clarify scale (DAU, QPS), draw high-level boxes, deep-dive one component, discuss failure modes and monitoring.

Signals that move Android Engineer candidates forward in India:
- Ownership of outcomes, not tasks
- Comfort with ambiguity and incomplete data
- Collaboration with cross-functional partners
- Understanding of India-specific constraints (UPI, logistics, multilingual users, price sensitivity)
- Realistic salary expectations aligned with level

Week 1: Solidify the Fundamentals

Spend the first week on lifecycle, Kotlin, and architecture. Re-read the official Android developer docs on Activity and Fragment lifecycles, then build a small demo app that deliberately triggers each callback so you can observe the behaviour. Practice Kotlin coroutines by writing toy examples that use launch, async, Flow, and StateFlow. Review MVVM with a simple to-do list app if you do not already have one in your portfolio.

Week 2: Modern APIs and Depth

Focus on Jetpack Compose, Hilt, Room, and Retrofit. If your current projects use the View system, spend time converting one small screen to Compose to get hands-on experience. Practice writing Room migrations, as schema evolution questions are commonly asked in mid-level interviews.

Week 3: Performance, Testing, and System Design

Profile an existing project using Android Studio's profilers. Write unit tests with MockK for your ViewModel layer and UI tests for at least one Compose screen. For system design, practise talking through a feature aloud, drawing component diagrams, and explaining tradeoffs. Candidates report that interviewers value a structured, narrated walkthrough over a polished final diagram.

Week 4: Mock Interviews and Role-play

Do at least two timed mock interviews with a peer or using an online coding platform. Record yourself answering behavioural questions using the STAR format and watch the playback to catch filler words or vague answers. Review your past projects so you can speak fluently about decisions you made and why.

• Rambling without a clear result metric
• Badmouthing previous employers
• Quoting global salary data without India context
• Ignoring the 'why this company' question
• Over-indexing on frameworks without showing real shipped work

Questions are grouped by theme. Candidates report that most interviews cycle through all three areas.

Fundamentals

1. Explain the Android Activity lifecycle. What happens when the user presses Home vs Back?
2. How do Fragment transactions work, and when would you use a Fragment over a separate Activity?
3. What is Jetpack Compose, and how does recomposition differ from the traditional View system?
4. Explain Kotlin coroutines. What is the difference between launch and async?
5. How does Android handle memory management? What causes an OutOfMemoryError in an app?
6. What is the difference between ViewModel, LiveData, and StateFlow? When would you prefer one over the other?
7. Describe the Room database library. How does it relate to SQLite, and what are DAOs?
8. How does dependency injection work in Android? Compare Hilt and Dagger.

Scenario-based

1. Your app takes more than five seconds to open on mid-range devices. Walk me through how you would diagnose and fix this.
2. The product team wants the app to work fully offline. How would you design data sync between the local database and the backend?
3. A release build crashes on certain devices but not in debug. How do you approach this?

Behavioural

1. Tell me about a time you found a critical bug close to a release deadline. What did you do?

Prioritise these areas based on how frequently they appear in candidate reports and job descriptions.

Core Android
Activity and Fragment lifecycle, back stack management, Intent types (explicit vs implicit), permissions model, background work with WorkManager and Services.

Modern Android Development (MAD)
Jetpack Compose (state, recomposition, side effects), Navigation component, ViewModel with SavedStateHandle, Room, Paging library.

Kotlin
Coroutines and Flow (cold vs hot streams, exception handling, structured concurrency), extension functions, sealed classes, data classes vs regular classes.

Architecture
MVVM and MVI patterns, Clean Architecture layers, Repository pattern, dependency injection with Hilt.

Performance
App startup optimisation, UI rendering (Choreographer, jank, overdraw), memory profiling, ProGuard/R8 basics.

Networking and Data
Retrofit with OkHttp, JSON parsing (Gson vs Moshi vs kotlinx.serialization), offline-first design, caching strategies.

Testing
Unit testing with JUnit and MockK, UI testing with Espresso or Compose Test, test doubles (mocks vs fakes vs stubs).

System Design (Senior roles)
Designing a scalable news feed, a chat app, or a maps feature at the component level. Interviewers commonly ask candidates to discuss tradeoffs between local caching and server-side pagination.

Memorising answers without understanding. Interviewers follow up on every answer. If you say 'I use ViewModel to survive configuration changes' but cannot explain what a configuration change is or what happens to a process under low memory, you will lose credibility quickly. Understand the 'why', not just the 'what'.

Ignoring the question actually asked. Candidates sometimes answer a related question they feel more comfortable with. Listen carefully, and if a question is unclear, ask for clarification before diving in.

Skipping testing knowledge. Testing is commonly cited as a weak area for Android candidates in India. Even if you are not writing tests daily, know the difference between unit, integration, and UI tests and be able to write a basic JUnit test live.

Treating system design as optional for mid-level roles. Companies hiring at the senior level increasingly expect candidates to design a feature at the component level, not just code it.

Not having concrete outcomes ready for your own projects. When discussing past work, interviewers want to hear impact: crash rates, screen load times, user counts. Review your own apps before the interview so you can speak to specific results.

Overlooking Kotlin idioms. If you are writing Android in Java-style Kotlin (null checks instead of safe calls, no extension functions, no data classes), interviewers notice. Brush up on idiomatic Kotlin before your first round.