Easy Android App Development Interview Questions

val declares a read-only reference that cannot be reassigned after initialisation, while var declares a mutable reference. Note that val does not make the object immutable: a val pointing to a MutableList can still have items added. Prefer val by default because it makes code easier to reason about and safer in concurrent code, and switch to var only when reassignment is genuinely needed.

Kotlin's type system separates nullable types (String?) from non-nullable types (String). The compiler stops you calling methods on a nullable value without a check. You use the safe call operator ?., the Elvis operator ?: for defaults, smart casts after null checks, or !! to force a value and risk a NullPointerException. This moves most null crashes from runtime to compile time, which is a major reason Android adopted Kotlin.

A data class is a class meant to hold data, declared with the data keyword and at least one property in the primary constructor. The compiler generates equals(), hashCode(), toString(), copy() and componentN() functions for destructuring, all based on primary constructor properties. They are ideal for UI state, API models and Room entities. Properties declared in the class body are not included in the generated equals or toString.

== checks structural equality and calls equals() under the hood, handling nulls safely. === checks referential equality, meaning both references point to the same object in memory. For two data class instances with the same values, == returns true but === returns false unless they are the same instance. For primitive-like types such as Int, === may behave unexpectedly due to boxing, so == is the normal choice.

A higher-order function takes a function as a parameter or returns one. A lambda is an anonymous function literal like { x: Int -> x * 2 }. Collection operations such as map, filter and forEach are higher-order functions. In Android you see them in click listeners, Compose callbacks like onClick = { } and coroutine builders. If the last parameter is a function, the lambda can be written outside the parentheses, known as trailing lambda syntax.

Kotlin functions can define default values, such as fun showToast(msg: String, long: Boolean = false), so callers skip arguments they do not need. Named arguments, like showToast(msg = "Saved", long = true), make calls readable and let you change argument order. Together they replace telescoping constructors and builder patterns in many cases. For Java callers, add @JvmOverloads so overloads are generated automatically.

Explain calmly that !! converts a compile-time check into a possible runtime crash. Suggest alternatives per case: safe calls with ?.let, Elvis with a default or early return, requireNotNull with a clear message, or fixing the type at the source so it is non-null. Add a detekt rule to flag !! in new code. Pair with them on one file so the change feels like help, not criticism.

Situation: my team switched a feature to Kotlin when I only knew Java. Task: deliver a profile screen in two weeks. Action: I spent the first evenings on the official Kotlin koans, converted small utility classes first, and asked a senior to review my early pull requests for idiomatic usage. Result: the screen shipped on time, and my later code needed far fewer review comments. I now learn by building something small immediately.

Give evidence, not adjectives. For example: I have built and published two apps using Kotlin and Jetpack Compose, one with Room and Retrofit and an MVVM structure, and both are on my GitHub with a README and tests. I debug by reading logs and stack traces before asking for help, and I am comfortable learning from code reviews. I can contribute to bug fixes and small features from the first month.

A coroutine is a suspendable computation that can pause at suspension points without blocking the thread it runs on. Thousands of coroutines can share a small thread pool because suspended coroutines do not hold a thread. Threads are managed by the OS, are heavier in memory and context switching. On Android, coroutines let you write asynchronous code like network calls in a sequential style, without callbacks, while keeping the main thread free.

suspend marks a function that can pause and resume later without blocking the thread. It can only be called from another suspend function or a coroutine. The compiler transforms it using continuation-passing style into a state machine. suspend alone does not move work to a background thread; the function must use withContext(Dispatchers.IO) or a main-safe library like Retrofit or Room to avoid blocking the main thread.

Dispatchers.Main runs on the Android UI thread and is used for updating views or state. Dispatchers.IO uses a large shared pool, by default up to 64 threads, for blocking work like disk and network. Dispatchers.Default uses a pool sized to CPU cores for CPU-heavy work like sorting, parsing large JSON or image processing. Use withContext to switch, and keep suspend functions main-safe so callers do not need to know.

launch starts a coroutine for work that returns no result and gives back a Job you can cancel or join. async returns a Deferred<T>, and you call await() to get the result. Use async to run independent tasks in parallel, such as fetching profile and orders together, then awaiting both. Exceptions differ: launch propagates them to the parent immediately, while async holds them until await, though in structured concurrency the parent still gets cancelled.

A suspend function returns a single value once. A Flow is a cold asynchronous stream that emits multiple values over time, like database updates, location changes or search results. Cold means the code inside flow { } runs only when collected, and runs again for each collector. Room, DataStore and many libraries expose Flow so the UI automatically updates when underlying data changes.

I follow the Android Developers blog and release notes for Jetpack libraries, read the Kotlin release notes for each version, and watch sessions from the main yearly Android conferences. I try new APIs in a small side project before proposing them at work, and I read pull requests from experienced colleagues. Once a month I review deprecation warnings in our project so upgrades stay small and planned.

Activities provide a screen the user interacts with. Services run work without a UI, such as music playback. Broadcast receivers respond to system or app-wide events like boot completed or connectivity change. Content providers share structured data between apps, such as contacts. Each component is an entry point the system can start, and most must be declared in AndroidManifest.xml with appropriate intent filters and permissions.

onCreate runs once to set up the UI and state. onStart makes the activity visible, onResume makes it interactive in the foreground. onPause runs when it loses focus, onStop when it is no longer visible, and onDestroy before it is removed. Rotation by default destroys and recreates the activity. Release resources like camera in onPause or onStop, and save transient UI state with ViewModel and SavedStateHandle.

By default the system destroys and recreates the Activity so it can load resources for the new configuration, like landscape layouts or a new language. Fields in the Activity are lost, but a ViewModel survives because it is kept by the ViewModelStore. Views with IDs restore some state automatically, and rememberSaveable in Compose restores small state. Handling changes manually via configChanges is possible but should be a deliberate choice.

An explicit intent names the exact component to start, like Intent(this, DetailActivity::class.java), and is used inside your own app. An implicit intent declares an action and data, such as ACTION_VIEW with a URL or ACTION_SEND with text, and the system finds apps that can handle it through intent filters. For implicit intents, handle the case where no app can respond, and since Android 11 declare package visibility queries when needed.

Dangerous permissions like camera, location and notifications (POST_NOTIFICATIONS since Android 13) must be declared in the manifest and requested at runtime. Use the Activity Result API with RequestPermission or RequestMultiplePermissions contracts. Show a rationale when shouldShowRequestPermissionRationale returns true, handle denial gracefully, and direct users to settings if they deny permanently. Request permissions in context, at the moment the feature needs them.

The manifest declares the app's package identity, components (activities, services, receivers, providers), intent filters, permissions, hardware features, and app-level settings like theme, backup rules and exported flags. Since Android 12, components with intent filters must set android:exported explicitly. Gradle merges manifests from libraries into the final one, so check the merged manifest when unexpected permissions appear in your release build.

Serializable is a Java marker interface that uses reflection and creates many temporary objects, so it is slower. Parcelable is Android-specific and writes fields explicitly to a Parcel, which is much faster for IPC. Writing Parcelable by hand is verbose, but the kotlin-parcelize plugin with @Parcelize generates it. Use Parcelable for Bundles and intents, and never use either as a long-term storage format.

I focus on user impact and options rather than jargon. For example, when asked for background tracking every second, I explained that Android limits background work to save battery, so the app would need a visible notification and stricter Play review. I offered two options with trade-offs and a recommendation. Using a simple diagram helped, and the PM chose the option that met the business need with fewer risks.

Jetpack Compose is Android's modern declarative UI toolkit. You describe the UI as Kotlin functions of state, and Compose redraws the parts that change when state changes. With XML views you inflate layouts and imperatively update views with findViewById or binding. Compose removes adapters and much boilerplate, makes theming and previews easier, and interoperates with views through ComposeView and AndroidView, allowing gradual migration.

Recomposition is Compose re-running composable functions whose inputs or read state changed, to update the UI. Compose tries to skip composables whose parameters are stable and unchanged. Composables can run often and in any order, so they must be side-effect free and fast; do not make network calls or write to variables inside them. Use Layout Inspector recomposition counts to find composables recomposing more than expected.

remember keeps a value across recompositions but loses it when the composable leaves composition, on configuration change or process death. rememberSaveable stores the value in the saved instance state Bundle, so it survives rotation and process death; it works with types that can go in a Bundle or with a custom Saver. Use rememberSaveable for things like text input or selected tab, and a ViewModel for screen-level data.

State hoisting means moving state out of a composable to its caller, and passing the value plus event callbacks down, like value and onValueChange. The composable becomes stateless, reusable and easy to preview and test. State should be hoisted to the lowest common parent that needs to read or change it, and screen-level state usually lives in a ViewModel. This creates unidirectional data flow: state flows down, events flow up.

Modifiers are applied in a chain from left to right, each wrapping the next. Modifier.padding(16.dp).background(Color.Red) adds padding outside the red area, while background first then padding colours the padding too. Similarly, clickable before padding makes the whole padded area clickable. Thinking of each modifier as wrapping the content after it helps predict layout, size and touch target behaviour.

Use val state by viewModel.uiState.collectAsStateWithLifecycle() from lifecycle-runtime-compose. It collects only while the lifecycle is at least STARTED, saving resources in the background, unlike collectAsState which keeps collecting. Pass the resulting state and callbacks to a stateless screen composable, which keeps the screen previewable and testable without a ViewModel. Obtain the ViewModel with hiltViewModel() or viewModel() at the route level.

The call is placed directly in the composable body, which runs on every recomposition. Composables must be side-effect free. Move loading to the ViewModel, triggered in init or by a user event, and expose the result as StateFlow. If something must start from composition, wrap it in LaunchedEffect with a stable key like the item ID, so it runs once per key rather than on every recomposition.

The value is probably held with remember, which is lost when the Activity is recreated. Either use rememberSaveable for local UI state, or keep the text in the ViewModel and pass it down with onValueChange. For data that must survive process death too, store it in SavedStateHandle in the ViewModel. Avoid storing text field state asynchronously, because delayed updates can cause cursor jumps.

MVVM splits an app into Model (data and business logic), View (Activity, Fragment or composable that renders state) and ViewModel (holds UI state and handles user events). The ViewModel survives configuration changes and has no reference to views, so it is easy to unit test. The View observes state from the ViewModel through StateFlow or LiveData. This separation reduces bugs from lifecycle issues and keeps UI code thin.

A ViewModel outlives the Activity during configuration changes. If it holds the old Activity or a view, that Activity cannot be garbage collected after rotation, causing a memory leak and possibly crashes when updating a dead view. Expose state for the UI to observe instead. If you need a Context for resources, inject the Application context or better, move that work into a repository or use resource IDs in state.

In unidirectional data flow, state flows down from the ViewModel to the UI, and events flow up from the UI to the ViewModel. The UI never changes state directly; it calls functions like onAddToCart(id), the ViewModel updates an immutable state object, and the UI re-renders. This makes state changes predictable, traceable and testable, and it is the model that Jetpack Compose is built around.

Dependency injection means classes receive their dependencies from outside rather than creating them, making code testable and loosely coupled. Hilt, built on Dagger, is Jetpack's recommended DI library. It generates code at compile time, provides standard components tied to Android lifecycles (SingletonComponent, ActivityRetainedComponent, ViewModelComponent), and integrates with ViewModels via @HiltViewModel. Errors appear at compile time rather than runtime.

Constructor-inject the repository as an interface, so tests can pass a fake implementation. With Hilt, add @Inject to the constructor and bind the real implementation in a module. Also inject dispatchers rather than using Dispatchers.IO directly. Then tests create ViewModel(FakeRepository()) and control results precisely. This change improves design too, because the ViewModel no longer knows how data is created.

Interfaces let us swap implementations, mainly fakes in tests and alternate data sources, and they define clear contracts between modules so feature modules depend on abstractions instead of concrete network code. But the rule is not absolute: if a class has one implementation and is easy to test directly, an interface adds noise. I would explain the reason with an example test and our team convention.

Room is the Jetpack persistence library built on SQLite. Its main parts are @Entity classes that map to tables, @Dao interfaces with queries annotated by @Query, @Insert, @Update and @Delete, and an abstract @Database class that ties them together. Room verifies SQL at compile time, supports suspend functions and Flow return types, and handles migrations. It removes most SQLite boilerplate while keeping full SQL power.

Jetpack DataStore stores key-value pairs (Preferences DataStore) or typed objects (Proto DataStore) using coroutines and Flow. Unlike SharedPreferences, it is safe to call from the main thread because I/O is asynchronous, it reports errors through exceptions, and updates are transactional. SharedPreferences apply() can still block the main thread during lifecycle events and cause ANRs. Use one DataStore instance per file, ideally as a singleton.

WorkManager schedules deferrable, guaranteed background work that must run even if the app exits or the device restarts, such as syncing data, uploading logs or backing up photos. It supports constraints like network or charging, retries with backoff, chaining and unique work. It is not for exact-time tasks or work that must finish immediately while the user waits; use coroutines for that and AlarmManager for exact alarms.

I rank by user impact and risk: crashes and data loss first, then bugs affecting payments or login, then the feature, then minor UI issues. I share the plan with my lead and product manager so trade-offs are visible, and I ask for help or a scope cut early instead of quietly missing the deadline. Small, safe fixes I batch together to save release overhead.

Check Settings storage breakdown and inspect filesDir, cacheDir and databases with Device Explorer. Common culprits are unbounded image caches, old downloaded files, logs, and databases that never delete old rows. Set size limits on Coil and OkHttp caches, use cacheDir for temporary files so the system can clear them, delete old records with a periodic WorkManager job, and compress or downscale stored images.

Retrofit is a type-safe HTTP client that turns an annotated Kotlin interface into API calls. You declare methods with @GET, @POST, @Path, @Query and @Body, and Retrofit generates the implementation using OkHttp underneath. Marking methods as suspend makes them main-safe and cancellable, returning the parsed body directly or Response<T> when you need status codes and headers. A converter like kotlinx.serialization or Moshi parses JSON.

Use ConnectivityManager with registerDefaultNetworkCallback and NetworkCapabilities to check NET_CAPABILITY_INTERNET and VALIDATED, and expose it as a Flow with callbackFlow. NetworkInfo and the CONNECTIVITY_ACTION broadcast are deprecated. Remember that being connected does not guarantee a working server, so still handle request failures. Use the status to show an offline banner and pause retries, not to block every request.

I agree on the API contract early, with sample JSON, and build against a fake or mock server so my UI and logic are ready. I keep the repository interface stable, so switching to the real API is a small change. I communicate status in standups and raise risks to my lead early if the dependency threatens the deadline, suggesting options like releasing behind a feature flag.

Local unit tests on the JVM cover ViewModels, use cases, repositories and mappers with JUnit, fakes and coroutine test tools; they are fast and most numerous. Instrumented tests run on a device or emulator for Room, Compose UI and integration flows. End-to-end UI tests check critical journeys like login and checkout. Screenshot tests catch visual regressions. Follow the testing pyramid: many unit tests, fewer UI tests.

An ANR (Application Not Responding) happens when the main thread is blocked, for example an input event not handled within about 5 seconds or a BroadcastReceiver taking too long. Causes include disk or network work on the main thread, heavy computation, lock contention and slow SharedPreferences commits. Prevent ANRs by moving work to background dispatchers, using StrictMode in debug builds, and tracking ANR rates in Android vitals.

An App Bundle (.aab) is a publishing format containing all compiled code and resources. The Play Store generates optimised APKs for each device configuration, delivering only the needed screen density, CPU architecture and language resources, which reduces download size. Since August 2021, new apps on Play must use AAB with Play App Signing, where the store holds the app signing key and you sign uploads with an upload key.

Create a developer account, then an app in Play Console. Complete the store listing, content rating, data safety form, target audience, privacy policy and permissions declarations. Build a signed release AAB with a higher versionCode, upload it to internal testing first, then closed or open testing, and finally production with a staged rollout. New personal accounts must run a closed test with at least 12 testers for 14 days before production.

Choose something with clear impact. For example: I built the offline cart for our grocery app. Users in low network areas could add items without connection, and the cart synced later with conflict handling. I used Room, WorkManager and a sync status field, and wrote migration and sync tests. After release, cart abandonment from network errors dropped noticeably, and the pattern was reused for the wishlist feature.

Keep it genuine and tied to growth. For example: in five years I want to be a senior or lead Android engineer who owns the architecture of a large app, mentors juniors and works closely with product on decisions. I plan to deepen my skills in performance, Compose and Kotlin Multiplatform, and contribute to the team's engineering practices. I hope to grow that path in a company like this one.

I first assume the reviewer has a reason and ask questions to understand it. If I still disagree, I explain my reasoning with evidence, such as documentation, a benchmark or a test, and suggest a short call if comments go back and forth. If it is a matter of preference, I follow the team convention. The goal is the best code for the team, not winning the argument.