Material Design 3 & Adaptive Layouts Interview Questions
UI › Material & Nav
When would you deliberately turn off or override dynamic color instead of using it everywhere, and what's the risk of leaving it on unexamined?
What a strong answer covers: You override it for brand-critical surfaces, marketing screens, empty states, illustrations, anywhere color carries brand identity that shouldn't shift with the user's wallpaper, or where your accessibility/contrast testing assumed a fixed palette. The risk of leaving it on everywhere untested is that dynamic color derives from the wallpaper, so certain wallpapers can produce low-contrast or muddy combinations you never verified, like two adjacent surfaces landing on nearly the same tone. A strong answer also flags that dynamic color is API 31+ only, so testing solely on a device with a vivid wallpaper hides regressions in the static fallback scheme that most of your install base actually sees.
Walk me through how you'd adapt a single-pane phone screen to work well on a foldable or tablet without maintaining two separate screen implementations.
What a strong answer covers: The strong approach computes the window size class once near the root, via currentWindowAdaptiveInfo or WindowSizeClass, and lets one composable branch its layout, not its logic, based on width, for example swapping a NavHost-driven list/detail flow for a ListDetailPaneScaffold that shows both panes side by side at Expanded width while reusing the exact same ViewModel and state. The trap is hardcoding device checks like isTablet or branching at the Activity level, which duplicates state management; the correct mental model is that business logic and state don't change, only which composables are shown together on screen at once.
What problem does Material 3's tonal elevation actually solve compared to Material 2's shadow-only elevation, and what new problems does it introduce, particularly in dark theme?
What a strong answer covers: M2 elevation was purely a shadow effect, which is nearly invisible in dark theme because shadows read poorly against dark backgrounds, so M3 instead lightens a surface's color by overlaying a percentage of the primary color at higher elevations, keeping elevated surfaces visually distinguishable in both light and dark themes. The trade-off a weak answer misses: a Card and its parent Surface no longer look identical just because they share a nominal color, so overlapping elevated or translucent surfaces can produce color banding or reduced contrast that wasn't a concern under M2's model, and teams sometimes still need explicit shadowElevation for genuine depth cues on top of the tonal shift.