Explain the res/ directory and resource qualifiers for layouts

Tests your grasp of Android's core resource system. A good answer defines res/ for non-code assets, explains how qualifiers like layout-land match device state, and provides a concrete example.
What's really being asked
This question tests a fundamental Android architecture principle: the separation of app resources from source code. Interviewers want to confirm you understand why this is crucial for handling device configuration changes (like rotation, language, or screen size) efficiently. It's a test of your knowledge of the specific, automatic conventions the Android build tools rely on, rather than manual, conditional code.
The full answer
First, define the purpose of the res/ directory: it holds all static, non-code assets like layouts, drawables, strings, dimensions, and styles. This decouples presentation from logic. Second, explain that the build system compiles these resources and generates the R class, which provides static integer IDs for code to access them (e.g., R.layout.main_activity). Third, define resource qualifiers as suffixes added to directory names that allow the OS to select the best resource for the current device configuration. Finally, provide the specific example: to support landscape, you create a default layout in res/layout/my_activity.xml and a landscape-specific version in res/layout-land/my_activity.xml. The filenames must be identical.
The mistakes people make
Describing a solution that only uses lifecycle callbacks (like in onCreate) to programmatically check the orientation and then manually reconfigure views. This ignores the primary, intended mechanism. Using incorrect qualifier names is another major red flag, for example res/layout-landscape/ (it's -land), res/layout/landscape/ (it's a suffix, not a subdirectory), or believing the default portrait layout needs a res/layout-port/ directory (the default has no qualifier).
What usually comes next
How does the system decide which resource to use if multiple qualifiers match, like layout-en-land versus layout-land? What other qualifiers have you used in a real project? What happens if a qualified resource is requested but no match is found and there is no default? (The app crashes with a Resources.NotFoundException).
A concrete example
For a screen defined by activity_feed.xml, you would have two files. The default (portrait) layout is located at app/src/main/res/layout/activity_feed.xml. The specific landscape layout is at app/src/main/res/layout-land/activity_feed.xml. In your FeedActivity.kt, you simply call setContentView(R.layout.activity_feed). The Android OS handles selecting and inflating the correct XML file automatically when the device is rotated. No if (orientation == LANDSCAPE) logic is needed for this.
Interview question
Which method is the most efficient and recommended for providing a distinct layout for an Android activity when the device is rotated to landscape mode?
- a.Implement onConfigurationChanged() to programmatically check the orientation and load a different layout XML.
- b.Create res/layout/my_activity.xml for portrait and res/layout-land/my_activity.xml for landscape, both with the same root filename.Correct
- c.Define separate layout files in res/layout/portrait/my_activity.xml and res/layout/landscape/my_activity.xml.
- d.Use res/layout-portrait/my_activity.xml and res/layout-landscape/my_activity.xml to specify layouts for each orientation.
Why? this is the answer
Android's resource qualifier system automatically selects the appropriate layout based on the device's configuration, such as orientation, by using suffixes like -land. Manually checking orientation in lifecycle callbacks (Option A) is inefficient and bypasses this intended automatic mechanism.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles