housing Mobile Engineer Interview: Questions, Experience & Prep (2026)

Housing.com is one of India's leading proptech platforms, and their mobile apps sit at the heart of the property search experience for millions of users. As of mid-2026, Housing has 188 open roles across functions, making it one of the more active hirers in Indian real estate tech.

Candidates typically report a process with a phone screen, one or two coding rounds, a system design discussion, and a hiring manager conversation. The coding rounds tend to focus on data structures, algorithms, and mobile-specific problem solving. System design questions often revolve around building features you would actually see in a property listing app: search, filters, media-heavy feeds, and map integrations.

The mobile engineer role at Housing typically involves working on their Android or iOS apps (some teams use React Native or Flutter). If you are applying from outside the real estate domain, do not worry. Interviewers care more about your mobile fundamentals and problem-solving ability than prior proptech experience.

These questions reflect what candidates commonly report from Housing.com mobile engineer interviews. Your actual experience may vary.

1. How would you architect a property listing feed that loads images, maps, and pricing data without janky scrolling?
2. Walk us through how you would implement offline support so users can browse saved properties without internet.
3. Describe how you handle deep linking in a mobile app, for example, when a user taps a shared property link.
4. How do you manage state in a complex mobile app? Compare approaches you have used (Redux, BLoC, MVVM, etc.).
5. Explain how you would reduce the app's startup time if it currently takes over four seconds to load.
6. How do you approach writing unit tests and UI tests for mobile? What do you prioritize testing?
7. Describe a time you debugged a crash that only happened on specific devices or OS versions.
8. How would you design a real-time chat feature between a buyer and a property agent inside the app?
9. What strategies do you use to keep the APK or IPA size small while adding new features?
10. How do you handle push notifications, including scheduling, permissions, and user preferences?
11. Tell us about a feature you shipped end-to-end on mobile. What tradeoffs did you make?
12. How do you secure sensitive data (like user tokens or saved searches) on the device?

Q: Describe a time you debugged a crash that only happened on specific devices or OS versions.

*Situation:* At my previous company, we started getting crash reports from users on Android 11 devices with less than 3 GB RAM. The crash rate spiked after a release but our internal testing devices could not reproduce it.

*Task:* I was responsible for identifying the root cause and shipping a fix before the next weekly release.

*Action:* I pulled crash logs from our monitoring tool and noticed the crash always occurred during image-heavy list rendering. I set up a low-memory emulator profile matching those device specs and reproduced the issue. The root cause was that our image caching library was holding full-resolution bitmaps in memory. I switched to downsampled thumbnails for the list view and added a memory-aware cache eviction policy.

*Result:* The crash rate on affected devices dropped to near zero within two days of the hotfix. We also adopted low-memory emulator testing as a standard step in our QA checklist going forward.

---

Q: How would you implement offline support so users can browse saved properties without internet?

*Situation:* Our product team wanted users to access their shortlisted properties even in areas with patchy connectivity, which is common in tier-2 and tier-3 Indian cities.

*Task:* I needed to design and build an offline-first data layer for the 'saved properties' section of the app.

*Action:* I used a local SQLite database (via Room on Android) to store property details and thumbnails when the user saved a listing. I implemented a sync mechanism that reconciled local and server data whenever connectivity resumed, using timestamps to resolve conflicts. I also added a small banner in the UI to let users know they were viewing cached data.

*Result:* Engagement with the saved properties feature increased noticeably after launch. The offline approach also reduced redundant API calls, cutting network usage for returning users.

---

Q: Tell us about a feature you shipped end-to-end on mobile. What tradeoffs did you make?

*Situation:* We needed to add a map-based property search feature that let users draw a custom boundary on the map and see listings within that area.

*Task:* I owned the feature from technical design through release, coordinating with the backend team on the geo-query API.

*Action:* I chose to use the platform's native map SDK rather than a cross-platform library because it gave smoother gesture handling for the draw-to-search interaction. The tradeoff was that I had to write the feature separately for Android and iOS. I also decided to debounce the geo-query so the API was not hammered on every small boundary adjustment.

*Result:* The feature shipped on time. Users who used map search had higher session durations. The native approach paid off in responsiveness, and the debounce logic kept our API costs stable even with heavy usage.

STAR for behavioural questions

Situation (set the scene in one or two sentences), Task (what was your specific responsibility), Action (what you did, with technical detail), Result (measurable outcome or lesson learned). Housing interviewers, like most product companies, want to hear real stories, not theoretical answers.

The Mobile System Design Framework

When you get a system design question (e.g., 'design the property feed'), structure your answer in layers:

1. Clarify requirements: ask about scale, platforms, offline needs.
2. High-level architecture: client vs. server responsibilities, API contract.
3. Data layer: local storage, caching strategy, sync logic.
4. UI layer: how you handle rendering performance (lazy loading, pagination, image sizing).
5. Edge cases: poor connectivity, low-end devices, accessibility.

This structure keeps your answer organized and shows you think about mobile holistically.

The Tradeoff Table for technical choices

When asked to compare approaches (e.g., 'Redux vs. BLoC'), briefly lay out pros and cons, then commit to a recommendation with reasoning. Interviewers want to see that you can make decisions, not just list options.

Strong mobile fundamentals over framework trivia. Housing builds consumer-facing apps used by millions. Interviewers want to know you understand lifecycle management, memory handling, smooth scrolling, and responsive layouts, not just that you can recite API names.

Real-world problem solving. Property apps deal with images, maps, location services, and varied network conditions across India. Show that you have dealt with messy, real-world constraints like low-end devices, slow connections, or inconsistent backend data.

Ownership and shipping mindset. Housing typically values engineers who can take a feature from idea to production. Talk about releases you owned, decisions you made under pressure, and how you handled things that went wrong.

Communication clarity. Especially in system design rounds, interviewers want you to think out loud, ask good clarifying questions, and explain your reasoning. A clear, structured walkthrough beats a perfect answer delivered in silence.

Collaboration signals. Mention how you worked with designers, backend engineers, QA, or product managers. Mobile development at a company like Housing is rarely a solo effort.

Week 1: Fundamentals and coding.
Revise core data structures (arrays, trees, hashmaps, graphs) and practice coding problems daily. Focus on problems that commonly appear in mobile engineer interviews: string manipulation, recursion, and caching-related logic.

Week 2: Mobile-specific depth.
Review the platform you are strongest in (Android or iOS) at a deep level. Topics to cover: app lifecycle, memory management, networking libraries, local databases, dependency injection, and testing frameworks. If Housing's job listing mentions a specific stack (Flutter, React Native), spend time building a small project in it.

Week 3: System design and Housing research.
Practice mobile system design problems: design an image-heavy feed, a chat system, a search feature with filters. Download the Housing.com app and study it closely. Note how they handle search, maps, property detail pages, and media. Think about what technical decisions they likely made.

Week 4: Mock interviews and behavioural prep.
Do at least two mock interviews with a friend or online platform. Prepare four to five STAR stories covering: a tough bug you fixed, a feature you shipped, a disagreement with a teammate, a time you improved performance, and a project that failed or pivoted. Practice explaining technical concepts clearly and concisely.

Ongoing: Stay current.
Follow Housing's engineering blog or tech talks if available. Keep an eye on recent mobile development trends (Jetpack Compose, SwiftUI, KMM) that Housing might be adopting.

Ignoring the product context. Housing is a consumer app in real estate. If you answer every question with generic textbook examples and never connect your answers to what a property search app actually needs, you will seem disengaged.

Over-engineering system design answers. Candidates sometimes propose microservices architectures and distributed caching layers for a mobile feature that needs a simple local database and a REST API. Start simple, then add complexity only when the interviewer pushes you.

Skipping edge cases. Mobile apps face spotty networks, low storage, device fragmentation, and accessibility requirements. If your answer does not mention at least one of these, it may feel incomplete.

Talking too long without structure. Rambling for five minutes without a clear framework (like STAR or the design framework above) makes it hard for the interviewer to follow you. Practice being concise.

Not asking clarifying questions. Jumping straight into a solution without asking about constraints (which platform? what scale? online or offline?) signals that you do not think carefully before coding.

Neglecting behavioural preparation. Technical skills get you to the final rounds, but culture fit and communication often determine the offer. Do not skip STAR prep.