CRED Android App Development Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About CRED hiring for Android App Development roles
CRED is an Indian fintech platform that rewards members for paying credit card bills and offers products such as CRED Pay, rent payments, CRED Mint and CRED Garage. Its engineering and analytics teams focus on payments, rewards, risk and app experience. It hires for software engineers, SDETs, data analysts and data scientists.
For Android App Development roles, this CRED practice set focuses most on App Architecture, MVVM and Hilt (7), Testing, Performance and Play Store (7), Jetpack Compose (5), Kotlin Fundamentals (3). It has 4 easy, 20 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
Fintech
Headquarters
Bengaluru, India
Main India offices
Bengaluru
CRED Android App Development interview process
Online assessment or assignment
Technical round (coding or SQL)
Problem solving or design round
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for CREDStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
How do you handle one-time navigation after a successful login in MVVM?
Recommended practice is to reflect the result in state, such as isLoggedIn = true in UiState, and have the UI react with LaunchedEffect(state.isLoggedIn) to navigate, then the ViewModel marks it consumed if needed. An alternative is a Channel exposed as Flow and collected with lifecycle awareness. Avoid calling navigation directly from the ViewModel, because it should not reference NavController or views.
02
Write a Hilt module that provides Retrofit and a repository binding.
Use SharedPreferencesMigration when creating the DataStore: preferencesDataStore(name = "settings", produceMigrations = { ctx -> listOf(SharedPreferencesMigration(ctx, "old_prefs")) }). On first access, DataStore copies the values and deletes the old file. Update all reads and writes to go through the new repository at once, because mixing both stores leads to inconsistent values. Test the migration with existing preference files.
04
What is the difference between List and MutableList, and is List truly immutable?
List is a read-only interface exposing only reading operations, while MutableList adds add, remove and set. A List is not guaranteed immutable: the underlying object might be an ArrayList that another reference can still modify. For real immutability use kotlinx.collections.immutable or create defensive copies. In ViewModels, expose List or StateFlow<List> publicly and keep the mutable version private to protect state.
05
Your app shows duplicate orders when users tap Pay twice on a slow network. How do you fix it?
Disable the button and show progress once tapped, but do not rely only on the UI. Generate an idempotency key on the client for each checkout attempt and send it with the request so the server returns the same result for retries. Ensure the payment call is not retried automatically by OkHttp for non-idempotent POSTs, and let the user check order status if the response is lost.
06
Write a delegated property that logs whenever a value changes.
import kotlin.properties.Delegates
class Settings {
var theme: String by Delegates.observable("light") { prop, old, new ->
println("${prop.name} changed from $old to $new")
}
}
// Use Delegates.vetoable if you need to reject a change
// by returning false from the lambda.
07
Where do you see yourself in five years as an Android developer?
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.
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.
09
Your team is migrating a Java Android app to Kotlin. How would you plan it?
Kotlin and Java interoperate, so migrate gradually rather than all at once. Start with new features in Kotlin, then convert leaf classes like models and utilities, writing tests before converting. Add nullability annotations to Java code so Kotlin sees correct types. Review auto-converted code because it often overuses !!. Track progress per module and agree on style rules with ktlint or detekt so the codebase stays consistent.
10
What is the difference between viewModelScope and lifecycleScope?
viewModelScope is cancelled when the ViewModel is cleared, so it survives configuration changes like rotation and suits loading data. lifecycleScope is tied to an Activity or Fragment lifecycle and is cancelled when it is destroyed, so it suits UI-related work. For collecting flows in views, combine lifecycleScope with repeatOnLifecycle(Lifecycle.State.STARTED) so collection stops when the app goes to background. Avoid GlobalScope in app code.
11
Explain the recommended layers in Android app architecture.
The official architecture guide recommends a UI layer (composables or views plus ViewModels as state holders), an optional domain layer (use cases that combine or reuse business logic), and a data layer (repositories that expose data and coordinate data sources like Room and Retrofit). Dependencies point inward: UI depends on domain or data, never the reverse. The repository is the single source of truth for each data type.
12
How do you share data between two screens in a checkout flow?
Options in order of preference: pass small IDs as navigation arguments and load the rest from a repository; store flow data in a repository scoped to the session; or use a ViewModel scoped to a nested navigation graph so all checkout screens share it and it is cleared when the flow ends. Avoid activity-scoped ViewModels holding everything, and avoid passing large objects through arguments.
13
The app's cold start takes 4 seconds. How do you improve it?
Measure first with Macrobenchmark StartupTimingMetric on a release build. Then reduce work in Application.onCreate by deferring SDK initialisation, using App Startup or lazy injection, and moving disk I/O off the main thread. Simplify the first screen, avoid blocking on network before showing UI, use the SplashScreen API properly, and add a Baseline Profile, which often improves startup by about 20 to 30 percent.
14
How do you refresh an expired access token automatically?
Use an OkHttp Authenticator, which is called when the server returns 401. Inside it, synchronise so only one refresh runs at a time, call the refresh endpoint with the refresh token, save the new tokens and return the original request with the new header. If the request already carried the latest token and still failed, or refresh fails, return null and log the user out. Limit retries to avoid loops.
15
The APK size grew to 120 MB and installs from small towns are dropping. How do you reduce it?
Analyse the build with APK Analyzer. Publish as an App Bundle so users get only their density, language and ABI. Enable R8 and resource shrinking, convert images to WebP or vectors, remove unused libraries and duplicate dependencies, and move large optional features or assets to Play Feature Delivery or Play Asset Delivery. Avoid bundling all native libraries for every ABI. Track size in CI.
16
What is MVVM and why is it recommended for Android?
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 Baseline Profile is a list of classes and methods used in critical journeys like startup and scrolling, shipped with the app. The Android Runtime uses it to compile that code ahead of time on install, avoiding slow interpretation and JIT on first runs. You generate it with the Baseline Profile Gradle plugin and Macrobenchmark tests. Compose and many Jetpack libraries ship their own profiles, but an app-specific one gives larger gains.
18
A screen shows a snackbar again every time the device rotates. How do you fix it?
The event is probably stored as state in a StateFlow or LiveData, so it is re-delivered when the new Activity collects again. Options: model it as part of UI state and have the UI call a function like onMessageShown() to clear it after display, which is the approach the official guidance recommends; or send it through a Channel exposed with receiveAsFlow so each event is consumed once. Collect with lifecycle awareness to avoid losing events.
19
A text field loses its typed value after rotation. How do you fix it?
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.
On every pull request, run lint, ktlint or detekt, unit tests and a debug build in a CI service like GitHub Actions or Bitrise, with Gradle caching. On merge to main, build a signed release AAB using secrets, run instrumented tests on emulators or a device farm, and upload to the Play internal track with Gradle Play Publisher or fastlane. Promote to production manually after QA with a staged rollout.
21
The API team wants to switch to GraphQL. What changes on the Android side?
You would use a client like Apollo Kotlin, which generates type-safe models from the schema and queries at build time, and supports normalised caching and coroutines. Benefits are fetching exactly the fields a screen needs and fewer round trips. Costs include learning the tooling, more complex caching and error handling since errors can come with partial data. I would pilot it on one feature before migrating everything.
22
Two screens show different values for the same cart count. How do you fix the architecture?
Each screen probably fetches and caches its own copy. Create a single CartRepository, scoped as a singleton, that owns cart data in Room or an in-memory StateFlow, and have both ViewModels observe its Flow instead of keeping private copies. Mutations go through the repository so every observer updates automatically. This enforces the single source of truth and removes the need for manual refresh calls between screens.
R8 shrinks code by removing unused classes and members, optimises bytecode by inlining and removing dead branches, obfuscates names to make reverse engineering harder and reduce size, and shrinks resources when enabled. It needs keep rules for code accessed by reflection, such as some serialization or SDK classes. Upload the mapping file to Play Console and Crashlytics so obfuscated stack traces can be decoded.
24
What is CompositionLocal and when should you use it?
CompositionLocal passes data implicitly down the tree without threading it through every parameter, like LocalContext, LocalDensity or MaterialTheme values. Create one with compositionLocalOf when values change often, or staticCompositionLocalOf when they rarely change. Use it for cross-cutting values like theme or analytics loggers, not for regular screen data, because implicit dependencies make composables harder to understand and test.
Each frame goes through composition, which decides what UI to show by running composables; layout, which measures and places each element; and drawing, which renders pixels. State read in a phase only invalidates that phase and later ones. Reading scroll state inside Modifier.offset { } or drawBehind defers the read to layout or draw, skipping recomposition entirely, which is a key optimisation for animations and scrolling effects.
26
Your team wants to migrate a large XML app to Compose. How would you plan it?
Start by setting up a shared Compose theme matching the existing design system, then build new screens in Compose. Migrate leaf components and simple screens next, using ComposeView inside fragments, and leave complex custom views wrapped in AndroidView for later. Measure performance with Macrobenchmark and add Baseline Profiles. Add Compose UI and screenshot tests, train the team, and set a rule that new UI is Compose-only.
27
What is a ContentProvider and when would you build one?
A ContentProvider exposes data through a URI-based interface with query, insert, update and delete, and handles permissions for cross-app access. You need one when sharing data with other apps, providing search suggestions, or supporting widgets that read your data. FileProvider is a ready-made provider for sharing files securely with content URIs instead of file paths. For data used only inside your app, Room is simpler.
28
QA says a bug happens only on one manufacturer's phones. How do you debug it?
Get exact device model, OS and skin versions, and steps. Use a remote device lab or Firebase Test Lab to reproduce if you lack the device. Collect logcat and bug reports, and compare behaviour around known differences like battery optimisation, autostart restrictions, custom permission dialogs or WebView versions. Add targeted logging or a non-fatal Crashlytics event, then apply a fix guarded by checks only if necessary.
29
How should a Fragment or Activity collect a Flow safely?
Use lifecycleScope.launch with repeatOnLifecycle(Lifecycle.State.STARTED) so collection starts when the UI is visible and stops in the background, avoiding wasted work and crashes from updating views that are not ready. In a Fragment, use viewLifecycleOwner.lifecycleScope because the fragment view can be destroyed while the fragment lives. In Compose, use collectAsStateWithLifecycle(), which does the same lifecycle-aware collection.
Use the Compose testing APIs with createComposeRule or createAndroidComposeRule. Find nodes by text, content description or testTag, then perform actions and assertions, like onNodeWithText("Login").performClick() and onNodeWithTag("error").assertIsDisplayed(). Test stateless composables with fake state for speed. Tests synchronise with Compose automatically. Screenshot testing tools like Roborazzi or Paparazzi catch visual regressions without a device.
Tips to crack the CRED Android App Development interview
Learn how credit card bill payments, UPI and rewards economics work, as CRED's products are built around them.
Pay attention to product design and user experience, which CRED is known for emphasising in its app.
For analyst roles, practise cases on member engagement, reward cost and credit risk segmentation.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; CRED interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the CRED Android App Development interview?
Candidates usually go through 4 stages: Online assessment or assignment; Technical round (coding or SQL); Problem solving or design round; Hiring manager round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the CRED Android App Development interview?
This practice set leans on App Architecture, MVVM and Hilt (7), Testing, Performance and Play Store (7), Jetpack Compose (5), Kotlin Fundamentals (3). Revise those first, then practise explaining one or two of your own projects end to end, because most CRED interviewers ask you to walk through real work.
Are these the exact questions asked at CRED?
No. These are curated practice questions that match the skills and difficulty usually tested in fintech interviews like CRED's. They are not a leaked or verified list of past questions.
Where does CRED hire Android App Development professionals in India?
CRED has large teams in Bengaluru. Openings and locations change often, so check the CRED careers page and filter by city and experience.
Android App Development questions for similar companies