housing Software Engineer Interview: Questions & Prep (2026)

Housing (part of REA India) is one of India's leading proptech platforms, connecting home buyers, renters, and brokers through map-based property search, locality insights, and AI-driven recommendations. As of July 2026, Housing has 188 open Software Engineer positions, reflecting active hiring across its product, platform, and data teams.

The engineering work spans geospatial search, real-time listing pipelines, pricing intelligence, and mobile-first consumer apps. Candidates typically go through three to four rounds: an online coding screen, one or two technical rounds covering data structures and system design, and a hiring-manager conversation. Most rounds are virtual, though candidates report on-site rounds for senior roles at the Gurugram office.

Software Engineer salary bands at Housing, based on knok's job radar data:

Actual offers vary by team, location, and negotiation.

Housing's interview process is product-aware. Expect technical questions framed around real platform features, not just abstract puzzles. Candidates report these questions coming up frequently:

1. Design a property search API that supports filtering by city, price range, property type, and proximity to a landmark.
2. How would you build a geofencing alert system that notifies a user when a new listing appears in their saved locality?
3. Explain how you would design the backend for Housing's map view, where thousands of property pins must load quickly as the user pans and zooms.
4. You have a listings database table with millions of rows and a search query running slowly. Walk me through how you diagnose and fix it.
5. How would you detect and suppress duplicate or fraudulent listings before they reach the search index?
6. Design a real-time price trend feature that shows how average property prices in a locality have moved over recent years.
7. How would you build a recommendation engine that suggests properties to a returning user based on their search and browsing history?
8. A critical property-details API is returning errors for a portion of requests in production. How do you investigate and resolve this?
9. Housing serves buyers, renters, and brokers on the same platform. How do you handle a feature request that benefits one segment but creates friction for another?
10. How would you implement paginated search results when new listings are added and old ones removed continuously?
11. How would you handle a sudden traffic spike when a high-demand housing project goes live and many users search at the same time?
12. Describe a system you built or improved that had a clear impact on user experience or platform reliability.

Use these as templates and replace the details with your own experience.

Q: Describe a time you improved the performance of a feature used by a large number of users.

*Situation:* At my previous company, our property listing search results page was noticeably slow during peak evening hours, causing users to drop off before results loaded.

*Task:* I was asked to own the investigation and reduce search API latency within the current sprint.

*Action:* I profiled the slow query and found two issues: a missing composite index on the city and listing-type columns, and a subquery that ran once per result row. I added the index, rewrote the subquery as a join, and introduced a short-lived Redis cache for the most popular city-category combinations. I also added monitoring so we could catch regressions early.

*Result:* API response time dropped significantly, on-call alerts for timeouts stopped within a day of the release, and the team adopted the caching pattern for two other slow endpoints.

---

Q: Tell me about a time you balanced technical quality with a tight deadline.

*Situation:* In 2025, my team had two weeks to ship a new search-filter feature before a major marketing campaign was scheduled to go live.

*Task:* I owned the backend changes and needed to coordinate with the frontend team to land both sides on time.

*Action:* I split the work into daily checkpoints, wrote the core logic with unit tests first, and flagged a risky dependency (a third-party geocoding API change) to the tech lead early in the sprint. We agreed to defer that edge case to the next sprint and ship a safe version first. I kept a shared doc updated so the frontend team always knew the current API contract.

*Result:* The feature launched on schedule, the campaign went live without issues, and the deferred improvement was completed cleanly the following sprint with no rework needed.

---

Q: How have you handled a production incident involving a critical API?

*Situation:* Our property-detail page started returning errors for some users on a Friday evening and the error rate was climbing.

*Task:* I was the on-call engineer and needed to identify the root cause and restore service quickly.

*Action:* I checked dashboards first and found CPU on one database replica was maxed out. Slow-query logs pointed to a recently deployed change that introduced a query without a WHERE-clause index. I rolled back the deploy, confirmed error rates dropped, and then wrote a post-mortem with a checklist for query review before future merges.

*Result:* Service was restored within the hour. The checklist was adopted by the team and caught a similar issue in code review the following month.

STAR (Situation, Task, Action, Result) is the standard framework for behavioural questions. Keep Situation and Task brief (two to three sentences combined) and spend most of your answer on Action and Result. Housing interviewers value concrete Results, so close with a specific outcome: a metric that improved, a process that changed, or a feature that shipped on time.

For system design questions, use a structured walk-through: clarify requirements and expected scale, define the API contract, sketch the data model, describe the core components, then discuss trade-offs. At Housing specifically, ground your design in product reality. If asked about a search system, mention that property searches are location-first and read-heavy, so geospatial indexing and caching are natural starting points.

For debugging and incident questions, follow an Observe-Hypothesise-Test loop. Describe what signals you check first (logs, metrics, error rates), how you form a hypothesis, and how you validate it without making the situation worse. Interviewers want to see a methodical process, not a lucky guess.

For product-thinking questions (common at Housing), use a simple Why-Who-What frame: why does this feature matter, who benefits most, and what is the smallest version that delivers real value. Showing that you think about users and not just code is a strong differentiator at a consumer product company.

Housing interviewers look for engineers who connect technical decisions to product impact. Candidates who have gone through the process report being evaluated on a few key traits:

Product curiosity. Interviewers often ask 'why does this matter to users?' as a follow-up to a technical answer. If you can explain why a geospatial index improves the experience for a home buyer browsing the map, you stand out from someone who only discusses query plans.

Clarity under ambiguity. Housing's platform serves buyers, renters, brokers, and developers, often with competing needs. Interviewers want to see you ask clarifying questions before jumping to a solution, especially in system design rounds. Candidates who ask one or two focused questions before answering are consistently rated more highly.

Ownership mindset. Engineers at Housing wear multiple hats. Candidates who describe shipping features end-to-end, writing their own tests, and following up after release tend to score better than those who describe handoff-heavy workflows.

Solid fundamentals. Coding rounds test standard data structures and algorithms. Candidates report that graph problems (relevant to location-based features), tree traversals, and sliding-window patterns come up frequently. Review these before your first technical round.

Communication. Think out loud during coding rounds. Interviewers want to understand your reasoning, not just see the final output. Candidates who narrate their approach and check assumptions with the interviewer consistently report better experiences.

A focused two-to-three week prep plan for a Housing Software Engineer interview:

Week 1: Technical foundations. Revise arrays, hash maps, trees, graphs, and sorting. Practise at least one problem each day in your preferred language. Prioritise graph problems (BFS and DFS) since location and recommendation features map naturally to graph structures. Review database indexing basics, particularly when composite indexes help and when they do not.

Week 2: System design and Housing context. Study how to design a search system at scale, a notification system, and a recommendation engine. Then apply each to Housing's product: property search with geo-filters, saved-search alerts, and personalised property suggestions. Read publicly available engineering case studies on proptech or map-based search to build vocabulary and anchor your designs in real decisions.

Week 3: Behavioural prep and mock interviews. Prepare four to five STAR stories covering: a performance improvement, a cross-team collaboration, a production incident, a product decision you influenced, and a time you pushed back on scope. Run a couple of mock interviews out loud (not just in your head), and time your answers to keep behavioural responses concise.

Before each round, review the job description and map your stories to the skills listed. Prepare two or three questions about the team's current technical challenges or near-term roadmap. If you want to stay on top of new Housing roles while you prep, knok checks 150+ job sites nightly, applies to jobs that match your resume, and messages HR for you so you do not miss an opening while you are deep in interview prep.

Skipping product context in system design. A generic 'design a search engine' answer scores lower at Housing than one that mentions property-specific constraints: listings have a short shelf life, search is location-first, and data freshness matters. Tie your design choices back to the business problem.

Jumping to code without clarifying. Candidates who ask one or two focused questions first (scale, read/write ratio, consistency requirements) are rated higher than those who immediately start typing. A brief pause to align on scope is expected and rewarded.

Weak Results in STAR answers. Many candidates give a solid Situation and Action but end with 'it went well.' Close with a concrete outcome: 'the team adopted it as a standard pattern,' 'on-call alerts stopped,' or 'we shipped on time for the campaign.' Vague endings undercut otherwise strong answers.

Ignoring edge cases in coding rounds. Housing's coding problems often have location or pagination edge cases: empty result sets, coordinate boundary conditions, behaviour on the last page. Mention edge cases before you start coding and handle the most critical ones in your solution.

Not using the product beforehand. Candidates who have clearly used Housing.com and can reference specific features (saved searches, locality insights, the map view) make a stronger impression. Spend half an hour exploring the app before your interview and note one or two things you found interesting or would improve.