housing Android Engineer Interview: Questions & Prep (2026)

Housing.com (part of REA India) is one of India's top real estate platforms, connecting home buyers, renters, and sellers with property listings across the country. The Android app is central to their business, used by millions searching for homes on mobile.

As of July 2026, Housing has 188 open roles company-wide, with Android Engineers being a core part of the product and engineering team. If you land an interview here, expect a technical process focused on Android fundamentals, system design for real estate features, and product thinking around the home-search experience.

Candidates typically go through multiple rounds covering coding, Android-specific knowledge, system design, and a hiring manager conversation. The team values engineers who build performant, scalable apps and think carefully about the end user.

These are the questions candidates report most often in Housing Android Engineer interviews:

1. Explain Kotlin coroutines. How have you used them in a production app to handle async operations?
2. Walk us through your preferred Android architecture. Why would you choose MVVM or Clean Architecture for a property search app?
3. How would you optimise a RecyclerView that shows hundreds of property listings with images and prices?
4. Describe how you would build a map-based property search feature. What Android APIs and libraries would you use?
5. How do you handle offline scenarios? What caching strategy would you use so users can browse listings without internet?
6. Explain your approach to dependency injection. Have you used Hilt or Dagger in a real project?
7. How do you detect and fix memory leaks in Android? Tell us about a leak you found and resolved.
8. How would you implement push notifications for property price alerts? Walk us through the architecture.
9. Describe your experience with A/B testing or feature flags inside an Android app.
10. How do you write unit tests and UI tests for Android? What tools do you use and what do you prioritise?
11. Tell us about a time your app had a performance problem. How did you profile it and what did you fix?
12. How do you handle API errors and poor network conditions gracefully in the UI?

Q: How would you optimise a RecyclerView showing hundreds of property listings?

*Situation:* At my previous company, our property listing screen had a RecyclerView with high-resolution images and complex view holders. Scroll performance was noticeably poor and users reported jank.

*Task:* I was asked to bring scroll performance to a smooth level without reducing visual quality.

*Action:* I used Android Studio's GPU Profiler to identify overdraw hotspots. I flattened the view hierarchy using ConstraintLayout, replaced our custom image loader with Glide configured with thumbnail requests and a memory cache, and moved all data-binding computations off the main thread using DiffUtil. I also fixed incorrect view recycling and removed redundant setTag calls inside bind.

*Result:* Scroll frame time dropped significantly, jank disappeared, and user complaints about lag stopped after the next release.

---

Q: Tell us about a time your app had a serious crash in production.

*Situation:* One morning after a release, our crash reporting tool showed a spike in NullPointerExceptions inside our map fragment, affecting users on older Android versions.

*Task:* I had to identify the root cause quickly because the map feature was central to the product.

*Action:* I reproduced the crash on a device running an older Android version and traced it to a lifecycle issue where the fragment tried to access a view after it had been destroyed. I added proper null checks, moved map initialisation into onViewCreated, and added a unit test to catch this lifecycle edge case going forward.

*Result:* We pushed a hotfix within hours and the crash-free rate returned to normal by end of day.

---

Q: How have you used Kotlin coroutines in a production app?

*Situation:* Our app's home screen made three separate API calls (featured listings, recent searches, and recommended properties) sequentially, making the screen feel slow to load.

*Task:* I needed to load all three data sets in parallel without blocking the main thread.

*Action:* I replaced the sequential calls with async/await using coroutines inside a viewModelScope. Each network call ran concurrently, and I used a sealed class to represent loading, success, and error states, exposing them via StateFlow to the UI layer.

*Result:* Home screen load time was cut roughly in half based on our internal timing logs, and the code became much easier to read and test than the previous callback chain.

Use STAR for behavioural questions (Situation, Task, Action, Result). Keep Situation and Task brief, and spend most of your time on Action (what you specifically did) and Result (what measurably changed).

For technical questions, follow a 'clarify, design, code, test' flow. Before jumping into code, ask one or two clarifying questions to show product thinking. For example, if asked about offline caching, ask whether the priority is data freshness or battery life.

For system design questions, start with requirements, then move to high-level components, then dig into the Android-specific layer (local database, sync strategy, UI architecture). Housing's app is data-heavy, so always address how you would handle large datasets and slow networks.

For debugging and performance questions, name the tools you use first (Profiler, LeakCanary, StrictMode) before explaining the fix. Interviewers want to understand your diagnostic process, not just the end answer.

Housing's Android team is building a consumer app used by people making one of the biggest financial decisions of their lives. Interviewers look for a few specific qualities.

Solid Android fundamentals. You should be comfortable with the Activity and Fragment lifecycle, ViewModels, LiveData or StateFlow, and Jetpack libraries. Gaps in fundamentals are hard to overlook at a product company of this scale.

Product empathy. Candidates who think about the end user, not just the code, stand out. If you mention how a feature affects a first-time home buyer or someone browsing on a slow connection in a smaller city, that signals product maturity.

Performance mindset. Real estate apps load lots of images and map data. Interviewers want to see that you think about memory usage, scroll performance, and battery impact proactively, not just when something breaks.

Clean, testable code. You will likely write code during the interview. Show that you write code you can test, not just code that runs.

Clear communication. If you get stuck, think out loud. Interviewers at companies like Housing typically value candidates who can articulate their reasoning clearly, even while working through an unfamiliar problem.

Week 1: Android core revision
Revise Kotlin coroutines, Flow, and StateFlow. Practice building a small MVVM app from scratch. Review the Android Activity and Fragment lifecycle until you can draw it from memory.

Week 2: Housing-specific features
Spend time using the Housing app. Notice how listing cards load, how the map search works, and how filters are applied. Think about how you would implement each screen. Practice explaining your design decisions out loud.

Week 3: System design and coding practice
Practise one Android system design question per day (offline feed, image caching strategy, notification system). Work on coding problems focused on data structures that come up in UI work: trees for category filters, graphs for map proximity, queues for loading order.

Week 4: Mock interviews and polish
Do at least two mock interviews with a peer or mentor. Prepare three to four strong STAR stories covering a performance problem you solved, a production incident you owned, a feature you built end to end, and a time you disagreed with a technical decision.

Check Housing's engineering blog and any public talks from their team to understand how they approach architecture and scale.

Skipping the 'why' on architecture choices. Saying 'I use MVVM' is table stakes. If you cannot explain why it suits a property search app better than other patterns, the answer lands flat.

Ignoring network edge cases. Housing's users span India, including areas with patchy connectivity. If you describe a feature without mentioning error states, retry logic, or caching, interviewers notice the gap.

Writing code that cannot be tested. Candidates often write large, tightly coupled Activities during live coding. Show that you separate concerns even under interview pressure.

Not asking clarifying questions. Jumping straight into a system design answer without scoping the problem signals poor engineering judgement.

Treating the interview as one-directional. Not asking any questions at the end signals low interest. Prepare two or three genuine questions about the team's tech stack, their roadmap, or how they handle scaling challenges in the real estate domain.