Jetpack Compose vs the View system — what tradeoffs does a senior engineer need to articulate?

#The question is really "do you know when to reach for which"

Asking a senior candidate to compare Jetpack Compose and the View system isn't really about whether Compose is "better" — everyone agrees it's Google's future direction. It's about whether you can name concrete tradeoffs: build time, team ramp-up, interop, and the specific classes of bugs each model makes easy or hard to introduce. An interviewer wants to hear you reason about a real migration decision, not repeat a marketing slide.

#Imperative vs. declarative is the real fault line

The View system is imperative: you build a View tree once (usually from XML), and from then on you mutate it — textView.text = newValue, progressBar.visibility = View.GONE. Every mutation is a command you issue by hand, and it's on you to keep every path that touches a widget in sync with the current data. Compose is declarative: a @Composable function describes what the UI should look like for the current state, and the runtime — the Compose compiler plus a recomposer — figures out what changed and updates only the necessary nodes. You never mutate a widget directly; you change state, and UI that reads that state recomposes.

#Recomposition replaces the invalidate/measure/layout/draw dance — but it isn't free

In the View system, "redraw" is invalidate → measure → layout → draw, and you can trigger the expensive parts by accident (calling requestLayout() inside a scroll listener, say). In Compose, the equivalent risk is unnecessary recomposition: a composable re-executes more often than it needs to because its inputs aren't stable (a lambda captured fresh every recomposition, a List instead of an ImmutableList, a data class the compiler can't prove is stable). The mental model shifted from "did I invalidate too eagerly" to "did I give the compiler enough information to skip this composable" — different bug, same category of performance foot-gun, and it's exactly the kind of nuance that separates someone who's shipped Compose in production from someone who's only followed a tutorial.

#Where interop actually happens

Nobody migrates a large app in one pass, which is why ComposeView (drop a Compose subtree into an XML layout) and AndroidView (drop a legacy View — a MapView, a third-party SDK widget with no Compose wrapper yet — into a Compose tree) exist as the two interop primitives. A pragmatic senior answer names the strangler-fig strategy directly: new screens in Compose, existing screens migrated opportunistically when they're touched anyway, and AndroidView/ComposeView as the seam that lets both coexist for years rather than blocking on a rewrite.

#Side by side

// View system: XML layout (res/layout/activity_counter.xml) + Activity
// <TextView android:id="@+id/countText" .../>
// <Button android:id="@+id/incrementButton" .../>

class CounterActivity : AppCompatActivity() {
    private var count = 0
    private lateinit var binding: ActivityCounterBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityCounterBinding.inflate(layoutInflater)
        setContentView(binding.root)

        binding.incrementButton.setOnClickListener {
            count++
            binding.countText.text = "Count: $count"
        }
    }
}

// Compose: no XML, no manual sync — state drives the UI
@Composable
fun CounterScreen() {
    var count by remember { mutableStateOf(0) }

    Column {
        Text(text = "Count: $count")
        Button(onClick = { count++ }) {
            Text("Increment")
        }
    }
}