What are Room's three main components and their functions?
Tests whether you know Room's architectural layers. Name the three: Database holds config and is the access point; Entity represents a table schema; DAO defines SQL operations. Red flag: confusing DAOs with Repositories or claiming Room is a full ORM.
What's really being asked
Even at a senior level, interviewers use this question to verify you did not just copy-paste Room setup from a template. They want to see that you understand the separation of concerns between the database holder, the schema definition, and the query interface. It also reveals whether you appreciate compile-time safety and how Room abstracts SQLite without hiding it completely.
The full answer
A good answer hits three things in order: first, the Database class, which is an abstract class annotated with @Database that extends RoomDatabase, holds the singleton reference, serves as the main access point for the underlying SQLite database, and lists the entities and version number; second, the Entity, which is a data class annotated with @Entity that maps to a table where each property corresponds to a column and each instance represents a row; third, the DAO, which is an interface or abstract class annotated with @Dao that defines methods for CRUD operations using annotations like @Query, @Insert, @Update, and @Delete, with SQL validated at compile time. A senior candidate also notes that the DAO abstracts the actual SQL execution so the rest of the app does not touch raw SQLite.
The mistakes people make
Common wrong answers include omitting the Database class entirely and only mentioning entities and DAOs, conflating the DAO with a Repository pattern layer, describing Room as a full ORM like Hibernate rather than an abstraction layer over SQLite, saying Entities manage queries, or claiming that Room replaces SQLite rather than sitting on top of it. Another red flag is confusing the DAO with the ViewModel or suggesting that SQL runs on the main thread by default.
What usually comes next
Likely follow-ups include asking how Room handles migrations when the schema changes, how you would expose Room data to the UI through Flow or LiveData, why you should use a Repository between the DAO and ViewModel, how to test Room databases using an in-memory database, or what happens if you perform a Room query on the main thread.
A concrete example
For a todo app, you might define a TaskEntity with @Entity(tableName = "tasks") and columns for id and title. You would define a TaskDao with @Query("SELECT * FROM tasks") and @Insert. Finally, you would define an abstract AppDatabase class annotated with @Database(entities = [TaskEntity::class], version = 1) that exposes an abstract fun taskDao(): TaskDao. The app then uses Room.databaseBuilder to instantiate AppDatabase and calls taskDao() to get the DAO.
Interview question
In Room, which architectural layer is responsible for defining database operations while keeping raw SQL details away from the rest of the app?
- a.Entity, because it maps class properties to table columns
- b.Repository, because it sits between the ViewModel and the data source
- c.DAO, because it declares operations and abstracts SQL executionCorrect
- d.Database, because it serves as the main access point and singleton holder
Why? this is the answer
The DAO defines CRUD operations and abstracts raw SQL execution so the rest of the app does not touch SQLite directly. A common misconception is confusing the DAO with a Repository pattern layer or with the Database class, which merely serves as the singleton access point that exposes DAOs.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #room
- #sqlite
- #persistence
- #architecture-components
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