CRED Android engineer interview questions and process

"Your list scrolls," the interviewer said, "but it stutters slightly every twelve rows or so. The user won't be able to tell you why. They'll just feel that the app is cheap." That sentence — they'll just feel that the app is cheap — is the most CRED thing anyone has ever said in an interview, and it explains the entire loop.

CRED Android engineer interview questions weight craft unusually heavily. Most Android interviews check whether you can build the screen; CRED checks whether the screen feels expensive. That means real depth on rendering, memory, animation and state — not just Jetpack trivia. This guide covers the rounds and what to say.

The CRED Android engineer interview process in 2026

CRED hires Android engineers into its consumer app and platform teams, almost entirely in Bengaluru. The reported CRED Android engineer interview process:

• Screening / take-home — often a small app or feature to build, sometimes replaced by a DSA screen for junior candidates.
• DSA round — LeetCode medium, real but not the deciding round. Arrays, hashmaps, trees, occasionally a graph.
• Android fundamentals round — lifecycle, coroutines, memory, rendering. Deep, specific, and unforgiving of memorised answers.
• Machine coding / UI round — build a working screen or component live, usually 90 minutes: a feed, a card stack, a custom animation.
• Architecture round — module structure, state management, offline behaviour, and how you would scale the codebase across teams.
• Craft / culture round — an app you admire and why, a UI detail you fought for, and how you handle a designer asking for something expensive.

The craft round is not filler. CRED's product positioning is built on polish, and an engineer who cannot articulate why a 300ms ease-out feels better than a 200ms linear is a genuine mismatch for that team.

Android fundamentals: the questions that actually go deep

This round separates people fastest. The recurring CRED Android interview questions:

• Why does a configuration change destroy your Activity, and what are the three ways to survive it? (ViewModel, onSaveInstanceState, and the retained-state mechanisms — plus when each is wrong.)
• What causes a memory leak in Android, concretely? The expected answers: a static or long-lived reference to a Context, a non-static inner class holding the Activity, a listener never unregistered, a coroutine outliving its scope. Then: how would you actually find one? LeakCanary, the Memory Profiler, and a heap dump comparison.
• What is the difference between viewModelScope, lifecycleScope and GlobalScope? And the follow-up nobody expects: why is GlobalScope effectively banned in a production app?
• Explain structured concurrency. Why cancelling a parent cancels children, what a SupervisorJob changes, and what happens to a coroutine that catches CancellationException and swallows it.
• StateFlow vs SharedFlow vs LiveData — and which you would use for a one-shot event like a snackbar, which is a trap because StateFlow replays.

Answers should be concrete. "Coroutines are lightweight threads" is a memorised sentence; "a coroutine launched in viewModelScope is cancelled when the ViewModel clears, which is why network calls tied to a screen belong there rather than in GlobalScope where they leak past navigation" is an answer. Our Kotlin interview questions guide covers the language layer and the Android developer interview questions guide covers the broader syllabus.

Jetpack Compose and the rendering questions

Compose is now the default at CRED-tier product companies, and the questions go past "what is a composable":

• The three phases — composition, layout, drawing — and why moving work from composition to drawing fixes some jank.
• Recomposition — what triggers it, why an unstable parameter causes a composable to recompose unnecessarily, and what @Stable and @Immutable promise the compiler.
• State hoisting — and why remember without rememberSaveable loses state on rotation.
• Keys in LazyColumn — the direct cause of the stutter in the intro. Without stable keys, item identity shifts and Compose re-composes and re-measures more than it needs to.

@Composable
fun TransactionList(items: List<Txn>, onClick: (String) -> Unit) {
    LazyColumn {
        // Stable keys: identity survives insertions, so Compose reuses slots
        items(
            items = items,
            key = { txn -> txn.id },
            contentType = { "txn" },
        ) { txn ->
            // Lambda captures only the id, not the whole item — keeps this stable
            TransactionRow(txn = txn, onClick = remember(txn.id) { { onClick(txn.id) } })
        }
    }
}

Be ready to explain each line, because the follow-up is "what would happen if you removed the key?" — and the honest answer is that on a stable list nothing visible changes, which is exactly why the bug survives code review and ships.

On performance generally, know the frame budget: 16ms at 60Hz, and roughly 8ms on the 120Hz displays CRED's users tend to own. Know that jank is work exceeding that budget on the main thread, and that the tools are the Layout Inspector, the Compose recomposition counts, Perfetto/systrace and Macrobenchmark. Naming baseline profiles for startup time reads as current.

The machine coding round

Ninety minutes, build something that runs. Reported prompts: a transaction feed with pagination and pull-to-refresh, an expandable card stack with animation, a search screen with debounce, an OTP input component, an image-heavy list with caching.

What is scored, in order:

• It runs and does the thing. A working two-thirds beats an elegant half.
• State handling. Loading, empty, error and success are four states, not one. Candidates who only build the success path lose here consistently.
• Separation. UI, ViewModel, repository. Network and mapping do not belong in a composable.
• Lifecycle correctness. Work cancelled on scope death, no leaks, configuration change survived.
• The detail. A debounce on search, a placeholder that does not jump, an animation with an easing curve you chose deliberately. This is where CRED differs from a generic Android loop — polish is scored, not bonus.

Narrate the tradeoffs while building: "I'm putting pagination in the repository so the ViewModel stays testable" and "I'll use a 300ms ease-out here because linear reads as mechanical." Our machine coding round guide covers timeboxing.

Architecture and the craft round

The architecture conversation covers MVVM vs MVI (and why MVI's single immutable state helps when a screen has many interacting flags), multi-module structure and build times, dependency injection with Hilt, offline-first behaviour and the single source of truth pattern, and how you would test each layer.

Then the craft round, which candidates underprepare because it sounds soft. It is not. Come with:

• An app you admire and a specific reason. Not "it's clean" — name a transition, a haptic, an empty state, a loading skeleton, and say why it works.
• A UI detail you fought for. Evidence you care past ticket completion.
• A time you pushed back on a design because it would cost a frame budget or break accessibility — and how you offered an alternative rather than just saying no.
• An opinion on when polish is not worth it. This is the maturity check; "always polish everything" is the wrong answer for a business.

Our tell me about a time you disagreed guide covers the pushback structure, and the how to explain your project guide covers the app walkthrough that usually opens this round.

LeetCode, the Android docs, ChatGPT — where each fits

• The official Android developer documentation — the Compose performance and lifecycle guides answer most fundamentals questions directly, and are more current than courses.
• LeetCode — right band is medium, and it is genuinely the least important part of this loop. Do not spend three weeks here.
• Building a small app end to end — highest yield. Build the transaction feed with all four states, then profile it and find your own jank. That experience answers the fundamentals round.
• Google's Now in Android sample — a real, modern, multi-module Compose codebase to read. Better preparation for the architecture round than any article.
• Blogs and YouTube — fine for Compose recipes, weak on the profiling skills the deep questions target.
• ChatGPT — good for reviewing a composable and explaining an API. It will not tell you the list stutters every twelve rows and wait for you to explain why.
• Greenroom — the spoken layer. Ari, the AI interviewer, runs the fundamentals and craft rounds out loud, pushes when your coroutine answer is a definition rather than a consequence, and scores structure and clarity. Fair tradeoff: Ari will not profile your APK.

How to prepare for the CRED Android interview

• Week 1: fundamentals with consequences — lifecycle, coroutine scopes, structured concurrency, memory leaks. Explain each aloud in sixty seconds using a real example.
• Week 2: Compose depth. Build a list, deliberately remove the keys, measure the recompositions, put them back. Learn the three phases by causing problems in each.
• Week 3: machine coding under a 90-minute timer, three times, always with all four states and one deliberate animation choice.
• Final week: prepare craft answers — an app you admire, a detail you fought for, a design you pushed back on — and run two full spoken mocks with follow-ups.

Interviewing across Indian consumer tech? The general CRED interview questions guide covers the company-wide loop, the Android developer interview questions guide covers the wider syllabus, and the PhonePe backend engineer guide and Meesho frontend engineer guide cover neighbouring loops.

Frequently asked questions

What is the CRED Android engineer interview process?

Candidates report a screening take-home or DSA round, a LeetCode-medium algorithms round, a deep Android fundamentals round covering lifecycle, coroutines, memory and rendering, a machine coding round of about 90 minutes building a working screen, an architecture round on modules, state and offline behaviour, and a craft or culture round about design detail and polish.

What Android fundamentals does CRED ask about?

Recurring questions cover why configuration changes destroy an Activity and the ways to survive them, concrete causes of memory leaks such as static Context references and unregistered listeners plus how you would find them with LeakCanary and the Memory Profiler, the differences between viewModelScope, lifecycleScope and GlobalScope, structured concurrency and SupervisorJob, and choosing between StateFlow, SharedFlow and LiveData for one-shot events.

What Jetpack Compose questions does CRED ask?

Expect the three phases of composition, layout and drawing and how moving work between them affects jank, what triggers recomposition and why unstable parameters cause unnecessary ones, what @Stable and @Immutable promise the compiler, state hoisting and the difference between remember and rememberSaveable, and why stable keys in a LazyColumn matter for item identity and scroll performance.

What is asked in the CRED machine coding round?

You get about 90 minutes to build a working screen. Reported prompts include a transaction feed with pagination and pull-to-refresh, an expandable animated card stack, a search screen with debounce, an OTP input component and an image-heavy cached list. Scoring favours working code, all four states handled including loading, empty and error, clean separation between UI, ViewModel and repository, lifecycle correctness, and deliberate polish.

How should I prepare for the CRED craft round?

Come with specifics rather than adjectives. Prepare an app you admire and name a concrete detail such as a transition, haptic or empty state and explain why it works, a UI detail you personally fought for, a time you pushed back on a design because it would cost frame budget or break accessibility while offering an alternative, and an honest opinion on when polish is not worth the engineering cost.

Is the CRED Android interview hard?

The algorithmic bar is moderate at LeetCode medium and is not where the loop is decided. The difficulty is depth in the fundamentals round and the fact that polish is a scored dimension rather than a bonus. Candidates who have memorised Jetpack definitions but never opened a profiler, caused a recomposition problem, or formed an opinion about animation timing find these rounds significantly harder than a generic Android interview.