🔥 ANDROID DEVELOPER (JAVA/KOTLIN) – 50

MEDIUM TO ADVANCED INTERVIEW Q&A

🔹 ARCHITECTURE & DESIGN

1. What is MVVM and why used?

👉 MVVM (Model-View-ViewModel) separates UI
and business logic.
• View → UI (Activity/Fragment/Compose)
• ViewModel → holds UI state
• Model → data layer
👉 Benefit: lifecycle-safe, testable, survives
configuration changes.

2. Difference between MVC, MVP, MVVM?

👉 MVC → tightly coupled👉 MVP → presenter
handles logic👉 MVVM → reactive UI + state driven
(best for Android)

3. Why ViewModel is lifecycle-aware?

👉 It survives configuration changes (rotation)
using lifecycle scope.

4. LiveData vs StateFlow?
👉 LiveData → lifecycle-aware, Android-specific👉
StateFlow → Kotlin Flow, more powerful, supports
 coroutines

5. Why use Repository pattern?

👉 Single source of truth → handles API + DB +
caching.

🔹 NETWORKING

6. How Retrofit works internally?

👉 Uses annotations → builds HTTP request →
OkHttp executes → converts response via
converters.

7. Why OkHttp used?

👉 Handles:
• Connection pooling
• Interceptors
• Retry mechanism

8. What are interceptors?

👉 Modify request/response globally (logging, auth
tokens).

9. How to handle API failure?

👉 Use:
• try/catch
• sealed class (Success/Error/Loading)
• retry mechanism

10. How to prevent duplicate API calls?

👉 Use:
• flag in ViewModel
• synchronized / mutex
• disable button UI

🔹 ROOM DATABASE

11. How Room works internally?

👉 Converts DAO methods → SQL → SQLite
execution.

12. Why Room over SQLite?

👉 Type safety, compile-time checks, less
boilerplate.

13. What is Room Migration?

👉 Updating DB schema without data loss.

14. What is @Transaction?

👉 Ensures multiple DB operations succeed or fail
together.

15. How to handle large data?

👉 Use Paging 3 library.

🔹 COROUTINES & THREADING

16. What is Coroutine?

👉 Lightweight thread for async tasks.

17. Dispatcher types?

👉 Main → UI👉 IO → network/db👉 Default → CPU
work

18. launch vs async?

👉 launch → no result👉 async → returns result
(Deferred)

19. What is structured concurrency?

👉 Child coroutines cancel automatically with
parent.

20. Why coroutines over threads?

👉 Less memory, easier syntax, lifecycle-aware.
🔹 ANDROID LIFECYCLE

21. Activity lifecycle?

👉 onCreate → onStart → onResume → onPause →
onStop → onDestroy

22. What happens on rotation?

👉 Activity recreated, ViewModel survives.

23. What is process death?

👉 App killed → ViewModel lost → restore via
SavedStateHandle.

24. Difference between onPause vs onStop?

👉 onPause → partially visible👉 onStop → not
visible

25. What is LifecycleOwner?

👉 Component that has lifecycle
(Activity/Fragment).

🔹 MEMORY & PERFORMANCE

26. What is memory leak?

👉 Object not garbage collected.
27. Common causes?
👉 Static references, Context misuse.

28. How to detect leaks?

👉 LeakCanary tool.

29. What is ANR?

👉 App Not Responding (main thread blocked >5
sec).

30. How to avoid ANR?

👉 Move heavy work to background thread.

🔹 UI & COMPOSE

31. What is Jetpack Compose?

👉 Declarative UI framework.

32. What is recomposition?

👉 UI redraw when state changes.

33. remember vs rememberSaveable?

👉 remember → temporary👉 rememberSaveable →
survives config change
34. What is derivedStateOf?
👉 Optimizes recomposition.

35. What is side effect in Compose?

👉 LaunchedEffect, DisposableEffect.

🔹 SECURITY (BANKING IMPORTANT)

36. How to secure API?

👉 Use HTTPS + token + encryption.

37. What is certificate pinning?

👉 Validates server certificate to prevent MITM
attack.

38. How to store sensitive data?

👉 EncryptedSharedPreferences / Keystore.

39. What is Play Integrity API?

👉 Detects tampered apps/devices.

40. How to prevent screen recording?

👉 FLAG_SECURE.
 🔹 TESTING

41. Unit vs UI testing?

👉 Unit → logic👉 UI → screen behavior

42. What is Mockito?

👉 Mock dependencies.

43. What is JUnit?

👉 Testing framework.

44. What is Espresso?

👉 UI testing tool.

45. What is Test Dispatcher?

👉 Controls coroutine execution in tests.

🔹 ARCHITECTURE ADVANCED

46. What is Clean Architecture?

👉 Separation:
• Data layer
• Domain layer
• Presentation layer
 47. What is UseCase?
👉 Handles business logic.

48. What is Dependency Injection?

👉 Provide dependencies externally (Hilt/Dagger).

49. Why Hilt?

👉 Simplifies DI with lifecycle awareness.

50. How offline-first works?

👉 Fetch from API → store in DB → UI reads from
DB.

🔥 FINAL INTERVIEW TIP

👉 Always answer with:

• Concept
• Real Android example
• Why used
• Trade-offs

// ========== MVC ==========

class LoginActivity extends Activity { // View +
Controller mixed
void onLoginClick() {
User user =
[Link](username, password); //
Model
if(user != null) showSuccess(); else
showError();
}
}
// Pros: Simple, quick start
// Cons: "God Activities", poor separation, hard to
test

// ========== MVP ==========

interface LoginView { void showSuccess(); void
showError(); }

class LoginPresenter {
private LoginView view;
LoginPresenter(LoginView v) { [Link] =
v; }
 void onLoginClick(String u, String p) {
User user = [Link](u, p); //
Model
if(user != null) [Link](); else
[Link]();
}
}

class LoginActivity extends Activity implements

LoginView {
LoginPresenter presenter = new
LoginPresenter(this);
void onLoginClick()
{ [Link](username, password); }
public void showSuccess() { /* update UI */ }
public void showError() { /* update UI */ }
}
// Pros: Better separation, testable presenter
// Cons: Boilerplate interfaces, verbose

// ========== MVVM ==========

class LoginViewModel extends ViewModel {
 MutableLiveData<Boolean> loginResult =
new MutableLiveData<>();

void login(String u, String p) {

User user = [Link](u, p); //
Model
[Link](user != null);
}
}

class LoginActivity extends Activity {

LoginViewModel vm;
void onCreate() {
vm = new
ViewModelProvider(this).get([Link]
s);
[Link](this, success -> {
if(success) showSuccess(); else
showError();
});
}
void onLoginClick() { [Link](username,
password); }
}
// Pros: Reactive, less boilerplate, highly testable
// Cons: Requires understanding LiveData/Flow,
more setup

// ========== MVVM + Clean Architecture

==========
class UserEntity { String name; } // Entity

interface UserRepository { UserEntity login(String

u, String p); } // Data abstraction

class LoginUseCase {
private UserRepository repo;
LoginUseCase(UserRepository r) { [Link] =
r; }
UserEntity execute(String u, String p)
{ return [Link](u, p); }
}

class LoginViewModel extends ViewModel {

private LoginUseCase useCase;
 MutableLiveData<Boolean> loginResult =
new MutableLiveData<>();

void login(String u, String p) {

UserEntity user = [Link](u, p);
[Link](user != null);
}
}

class LoginActivity extends Activity {

LoginViewModel vm;
void onCreate() {
vm = new
ViewModelProvider(this).get([Link]
s);
[Link](this, success -> {
if(success) showSuccess(); else
showError();
});
}
void onLoginClick() { [Link](username,
password); }
}
// Pros: Maximum separation, testability, scalable
for big teams/projects
// Cons: Complex setup, slower initial
development

==================== MVC (Model–

View–Controller)
====================
- Structure:
Model: Data + business logic
View: UI (Activity/Fragment)
Controller: Handles input, updates model/view
- Example:
Activity acts as both View and Controller →
leads to “God Activities.”
- Pros:
• Simple, easy to start
- Cons:
• Poor separation of concerns
• Hard to test, messy in large apps
- Best Use Case: Small apps or prototypes
==================== MVP (Model–
View–Presenter)
====================
- Structure:
Model: Data layer
View: UI (Activity/Fragment, XML)
Presenter: Middle layer, handles logic, updates
View via interface
- Example:
Login screen: Presenter validates credentials,
View shows success/error.
- Pros:
• Better separation of concerns
• Testable presenters
• Easier maintenance
- Cons:
• Boilerplate code (many interfaces)
• Can get verbose
- Best Use Case: Medium-sized apps with
moderate complexity

==================== MVVM (Model–

View–ViewModel)
====================
- Structure:
Model: Data + repository
View: UI (Activity/Fragment, XML)
ViewModel: Exposes data via
LiveData/StateFlow, handles logic
- Example:
Weather app: ViewModel fetches data, exposes
LiveData; View observes and updates
automatically.
- Pros:
• Reactive and modern
• Less boilerplate
• Highly testable
• Aligns with Jetpack libraries
- Cons:
• Learning curve
• Complex for beginners
- Best Use Case: Large, scalable apps

==================== MVVM + Clean

Architecture ====================
- Structure:
Entities: Core business models
 Use Cases/Interactors: Business rules
Repositories: Data access abstraction
ViewModel: Connects use cases to UI
View: UI layer observing ViewModel
- Example:
E-commerce app:
• Use Case: PlaceOrder
• Repository: OrderRepository
• ViewModel: Calls PlaceOrder, exposes result
• View: Displays confirmation
- Pros:
• Maximum separation of concerns
• High testability
• Scalable for big teams/projects
• Long-term maintainability
- Cons:
• Complex setup
• More layers → slower initial development
- Best Use Case: Enterprise-level apps, long-term
projects
==================== Quick
Comparison ====================
MVC → Fast start, but messy later
MVP → Clearer separation, but verbose
MVVM → Reactive, modern, testable
MVVM + Clean → Strict boundaries, enterprise-
ready, heavy upfront investment

🔥 SOLID PRINCIPLES (JAVA) + ANDROID MVVM

CLEAN ARCHITECTURE MAPPING

🔹 WHAT IS SOLID?

SOLID is a set of 5 design principles used to

write:👉 Maintainable👉 Scalable👉 Testable code

🔥 S = SINGLE RESPONSIBILITY PRINCIPLE (SRP)

✅ Definition
👉 A class should have only ONE reason to change

❌ Bad Example
class UserManager {
void fetchUser() {}
void saveToDb() {}
void logEvent() {}
}
 👉 Problem: multiple responsibilities (API + DB +
Logging)

✅ Good Example
class UserRepository {
void fetchUser() {}
}

class UserDao {
void saveToDb() {}
}

class Logger {
void logEvent() {}
}

🔥 Android Mapping
👉 MVVM Clean Architecture:
• View → UI only
• ViewModel → UI logic
• UseCase → business logic
• Repository → data handling
👉 Each layer has single responsibility

🔥 O = OPEN/CLOSED PRINCIPLE (OCP)

✅ Definition
 👉 Open for extension, closed for modification

❌ Bad Example
class Payment {
void pay(String type) {
if ([Link]("UPI")) {}
else if ([Link]("CARD")) {}
}
}
👉 Problem: need to modify code for new type

✅ Good Example
interface Payment {
void pay();
}

class UpiPayment implements Payment {

public void pay() {}
}

class CardPayment implements Payment {

public void pay() {}
}

🔥 Android Mapping
👉 Add new feature without modifying old code:
• New API → new Repository implementation
• New UI → new Fragment/Compose
 🔥 L = LISKOV SUBSTITUTION PRINCIPLE (LSP)

✅ Definition
👉 Child class should replace parent without
breaking behavior

❌ Bad Example
class Bird {
void fly() {}
}

class Penguin extends Bird {

void fly() { throw new
RuntimeException(); }
}
👉 Problem: Penguin cannot fly

✅ Good Example
interface Bird {}
interface FlyingBird {
void fly();
}

🔥 Android Mapping
👉 Example:
• Repository interface → multiple implementations
(API/DB)
• Both should behave correctly

🔥 I = INTERFACE SEGREGATION PRINCIPLE (ISP)

✅ Definition
👉 Don’t force classes to implement methods they
don’t use

❌ Bad Example
interface Worker {
void work();
void eat();
}

class Robot implements Worker {

public void eat() {} // unnecessary
}

✅ Good Example
interface Workable {
void work();
}

interface Eatable {
void eat();
}

🔥 Android Mapping
👉 Use small interfaces:
• Separate API interfaces
• Separate DAO methods
• Avoid fat repositories

🔥 D = DEPENDENCY INVERSION PRINCIPLE (DIP)

✅ Definition
👉 High-level modules should not depend on low-
level modules👉 Both should depend on
abstraction

❌ Bad Example
class UserViewModel {
UserRepository repo = new
UserRepository();
}
👉 Tight coupling

✅ Good Example
interface UserRepository {
void getUser();
}

class UserViewModel {
private UserRepository repo;

UserViewModel(UserRepository repo) {
[Link] = repo;
 }
}

🔥 Android Mapping
👉 Used with Hilt / Dagger:
• ViewModel depends on interface
• Implementation injected

🔥 FULL ANDROID CLEAN ARCHITECTURE MAPPING

🔹 Presentation Layer (View + ViewModel)

• SRP → View handles UI only
• DIP → ViewModel depends on UseCase interface

🔹 Domain Layer (UseCase)

• SRP → one business logic per use case
• OCP → extend new use cases easily

🔹 Data Layer (Repository)

• DIP → interface + implementation
• LSP → API & DB implementations interchangeable
• ISP → smaller repository interfaces

🔥 REAL FLOW (IMPORTANT)

View → ViewModel → UseCase → Repository
→ API/DB
👉 Each layer follows SOLID

🔥 REAL ANDROID EXAMPLE

interface UserRepository {
User getUser();
}

class UserRepositoryImpl implements

UserRepository {
public User getUser() {
return [Link]();
}
}

class GetUserUseCase {
private UserRepository repo;

GetUserUseCase(UserRepository repo) {
[Link] = repo;
}

User execute() {
return [Link]();
}
}

🔥 FINAL SUMMARY

Principle Android Use

SRP Separate View,
 ViewModel, Repository
Add features without
OCP
modifying existing
Replace
LSP
implementations safely
ISP Small interfaces
Use interfaces + DI
DIP
(Hilt)

🔥 INTERVIEW TIP

👉 Don’t just define SOLID👉 Always explain with:

• Code example
• Android layer mapping
• Real use case

🔥 SOFTWARE DESIGN PATTERNS + DATA

STRUCTURES

(ANDROID MVVM CLEAN ARCHITECTURE – REAL

WORLD EXPLANATION)

🔹 1. WHAT ARE DESIGN PATTERNS?

👉 Design patterns are reusable solutions to

common problems in software design.
 👉 Not exact code, but structured approach to
solve problems

🔹 TYPES OF DESIGN PATTERNS

🔥 1. CREATIONAL PATTERNS (Object Creation)

✅ Singleton
Definition
👉 Ensures only one instance of a class exists

Example
class Database {
private static Database instance;

private Database() {}

public static Database getInstance()

{
if (instance == null) {
instance = new Database();
}
return instance;
}
}

🔥 Android MVVM Use

• Room Database instance
• Retrofit instance
👉 Single source across app

✅ Factory Pattern
Definition
👉 Creates objects without exposing creation logic

Example
interface Payment {
void pay();
}

class UpiPayment implements Payment {

public void pay() {}
}

class PaymentFactory {
Payment create(String type) {
if ([Link]("UPI")) return
new UpiPayment();
return null;
}
}

🔥 Android Use
• ViewModelFactory
• Creating API services dynamically
✅ Builder Pattern
Definition
👉 Builds complex objects step-by-step

Example
class User {
String name;
int age;

static class Builder {

private String name;
private int age;

Builder setName(String name) {

[Link] = name;
return this;
}

Builder setAge(int age) {

[Link] = age;
return this;
}

User build() {
User u = new User();
[Link] = name;
[Link] = age;
return u;
}
}
}
 🔥 Android Use
• [Link]()
• [Link]()
• [Link]()

🔥 2. STRUCTURAL PATTERNS

✅ Adapter Pattern
Definition
👉 Converts one interface into another

Example
class OldApi {
void oldRequest() {}
}

class Adapter {
OldApi api = new OldApi();

void newRequest() {
[Link]();
}
}

🔥 Android Use
• [Link]
• Converting API model → UI model

✅ Decorator Pattern
Definition
👉 Adds new functionality without modifying class

Example
interface Coffee {
String getType();
}

class SimpleCoffee implements Coffee {

public String getType() { return
"Coffee"; }
}

class MilkDecorator implements Coffee {

private Coffee coffee;

MilkDecorator(Coffee coffee) {
[Link] = coffee;
}

public String getType() {

return [Link]() + " +
Milk";
}
}

🔥 Android Use
• OkHttp Interceptors
• Wrapping API responses

🔥 3. BEHAVIORAL PATTERNS

✅ Observer Pattern
Definition
👉 One object notifies multiple observers

Example
interface Observer {
void update();
}

class Subject {
List<Observer> observers = new
ArrayList<>();

void add(Observer o) {
[Link](o);
}

void notifyAllObservers() {
for (Observer o : observers) {
[Link]();
}
}
}
 🔥 Android Use
• LiveData
• StateFlow
👉 UI observes data changes

✅ Strategy Pattern
Definition
👉 Select behavior at runtime

Example
interface PaymentStrategy {
void pay();
}

class UpiStrategy implements

PaymentStrategy {
public void pay() {}
}

class PaymentContext {
private PaymentStrategy strategy;

void setStrategy(PaymentStrategy s) {
strategy = s;
}

void execute() {
[Link]();
 }
}

🔥 Android Use
• Different login methods
• Payment options

🔥 ANDROID MVVM CLEAN ARCHITECTURE FLOW

UI (Activity/Compose)
↓
ViewModel
↓
UseCase
↓
Repository
↓
API / DB

🔥 WHERE PATTERNS FIT

Layer Pattern Used

ViewModel Observer
Repository Strategy
API/DB Singleton
Object creation Factory / Builder
Data conversion Adapter

🔹 2. DATA STRUCTURES
 🔥 1. ARRAY

Definition
👉 Fixed-size collection
int[] arr = {1,2,3};

Android Use
• Simple static data

🔥 2. ARRAYLIST

Definition
👉 Dynamic array
List<String> list = new ArrayList<>();

Android Use
• RecyclerView data

🔥 3. LINKEDLIST

Definition
👉 Node-based structure

Android Use
• Frequent insert/remove
 🔥 4. HASHMAP

Definition
👉 Key-value storage using hashing
Map<String, User> map = new HashMap<>();

Android Use
• Caching API data

🔥 5. HASHSET

Definition
👉 Unique elements only
Set<String> set = new HashSet<>();

Android Use
• Remove duplicates

🔥 6. QUEUE

Definition
👉 FIFO (First In First Out)

Android Use
• Task scheduling
 🔥 7. STACK

Definition
👉 LIFO (Last In First Out)

Android Use
• Navigation back stack

🔥 DATA STRUCTURE SELECTION (IMPORTANT)

Problem Use
Ordered list ArrayList
Unique items HashSet
Fast lookup HashMap
Queue tasks Queue
Undo/Back Stack

🔥 FINAL INTERVIEW STRATEGY

👉 Always answer with:

• Definition
• Code example
• Android real use case
• Why better than others

🔥 PRO TIP (VERY IMPORTANT)

For Android interviews:

 👉 Focus on:
• Singleton → Room/Retrofit
• Observer → LiveData/Flow
• Strategy → Repository logic
• HashMap → caching
• ArrayList → UI data