Arrange UI elements vertically or horizontally in Jetpack Compose

WHAT THIS TESTS: Even at senior level, interviewers use fundamental questions to check if you internalized the declarative paradigm or are still thinking in View system terms. They want to see that you understand layout as function composition rather than XML configuration, and that you treat Modifier as a core layout mechanism rather than an optional styling layer. Specifically, they are listening for whether you recognize that Column and Row are inline composable functions that emit layout nodes directly without the overhead of a ViewGroup equivalent.

A GOOD ANSWER COVERS: First, name the two primary composables: Column arranges children vertically and Row arranges them horizontally. Second, explain that both accept a Modifier parameter which is used to decorate or change the behavior of the composable, including sizing, padding, background, click handling, and alignment. Third, stress that Modifier uses chaining and that order matters because each modifier wraps the previous one, affecting both measurement and drawing phases. Fourth, mention that Column and Row are inline functions that do not add extra view nodes, unlike LinearLayout in the View system. Fifth, note that these containers expose arrangement and alignment parameters to control main-axis and cross-axis positioning without nested wrappers.

COMMON WRONG ANSWERS: A major red flag is mapping Compose one-to-one to the View system by saying Column is just a vertical LinearLayout without acknowledging the declarative difference. Another is describing Modifier as only for styling or cosmetics rather than a first-class mechanism for layout behavior and input handling. Candidates also stumble by ignoring modifier ordering or claiming that padding before versus after size has the same effect. Some also forget that Modifier is an immutable data structure that is rebuilt on recomposition, which matters for performance at scale.

LIKELY FOLLOW-UPS: The interviewer may ask how modifier ordering changes the result, for example padding then size versus size then padding. They might ask about LazyColumn versus Column for large lists, or how to distribute space using Arrangement and Alignment parameters. They could also ask where state should live when items inside a Column or Row need to interact, or how to avoid recomposition of the entire container when a single item changes.

ONE CONCRETE EXAMPLE: Suppose you need a card with an icon and text side by side. You would use a Row with a Modifier that sets fillMaxWidth and padding. Inside the Row, the Icon gets a size modifier and the Text gets a weight modifier so it takes remaining space. If you accidentally apply background before padding, the background fills only the content area; if you apply padding before background, the background extends into the padding. This shows modifier order in practice. Similarly, applying clickable before padding gives a larger touch target than applying it after, which is a common accessibility pitfall.

Source: developer.android.com