housing Data Scientist Interview: Questions & Prep (2026)

Housing is one of India's leading real estate tech platforms, part of the REA India group alongside PropTiger and Makaan. Their data science teams work on property price prediction, personalised listing recommendations, search ranking, broker lead scoring, and buyer-intent modelling. Housing currently has 188 open Data Scientist roles as of July 2026, making it one of the more active proptech hirers in India right now.

The interview process typically spans three to four rounds: an online test or take-home case study, a technical round covering statistics and machine learning, a product analytics or system design discussion, and a hiring-manager conversation. Candidates report that real estate domain thinking is weighted alongside pure ML skills.

Salary ranges above are based on tracked Data Scientist job postings across India (July 2026).

These questions come up frequently in Housing data science interviews, based on candidate reports and the product areas Housing is known for.

1. How would you build a property price prediction model for a new city where you have very few historical transactions?
2. Housing's recommendation engine must suggest properties to users who have viewed only one or two listings. How do you tackle the cold-start problem?
3. Design a lead-scoring model that helps brokers prioritise buyer inquiries. What features would you use and why?
4. Walk us through a production model you owned: how did you monitor it and what did you do when its performance dropped?
5. How would you detect fraudulent or duplicate property listings using machine learning?
6. Housing has millions of unstructured property descriptions. How would you extract structured features like amenities, furnishing type, and floor number from them?
7. Property prices follow a heavy right skew. How do you handle this when training a regression model?
8. How would you design an A/B test to evaluate a new property search ranking algorithm? What is your primary success metric?
9. Explain gradient boosting in plain terms. When would you choose it over a deep learning approach for tabular real estate data?
10. How do you engineer features from location data such as latitude, longitude, locality name, and pincode?
11. A recommendation model you deployed six months ago is showing declining engagement. How do you diagnose the root cause?
12. How would you measure whether Housing's personalisation feature is genuinely improving user experience, beyond raw click counts?

Q: Housing's recommendation engine must suggest properties to users who have viewed only one or two listings. How do you tackle the cold-start problem?

*Situation:* At my previous company we launched a new property category where there was no user interaction history at all.

*Task:* I had to surface relevant listings to new users before collaborative filtering had enough signal to work.

*Action:* I built a content-based fallback using structured property attributes (BHK count, price band, locality tier, amenities tags) and combined it with a seven-day popularity signal from similar-locality views. Once a user accumulated enough interactions, the system blended in collaborative signals through a weighted hybrid model. I also used session context, such as the search filters a user had set, as a real-time feature to sharpen early recommendations.

*Result:* The hybrid approach reduced early-session drop-off and gave the collaborative model enough warm-start data within a user's first few sessions. The team later extended this same pattern to two other new categories.

---

Q: Walk us through a production model you owned and how you handled performance degradation.

*Situation:* I owned a lead-scoring model at a proptech startup that ranked inbound buyer inquiries for the sales team.

*Task:* About four months after launch, the sales team noticed that top-scored leads were converting at a lower rate than before.

*Action:* I built a monitoring dashboard tracking input feature distributions and score distributions daily. I found that a new paid traffic source had shifted user demographics, changing the relationship between features and actual conversion. I retrained on a rolling three-month window, added the traffic-source channel as an explicit feature, and set up a weekly automated retraining job so the model could adapt faster to future shifts.

*Result:* Lead quality scores aligned with sales outcomes again within two weeks of the retrain. We also documented a model-health checklist the team now runs every month.

---

Q: How would you design an A/B test for a new property search ranking algorithm?

*Situation:* My team at a previous company wanted to test a re-ranked search algorithm that boosted verified listings higher in results.

*Task:* Design an experiment that isolates the ranking change, chooses the right success metric, and avoids common pitfalls.

*Action:* I set up a user-level split (not session-level, to avoid contamination from the same user seeing both variants) with a holdout group on the old ranking. The primary metric was contact-initiation rate (user taps 'call broker' or 'schedule visit') as a direct signal of purchase intent, with session depth as a guardrail to ensure we were not just boosting clicks on worse results. I ran a power analysis to size the experiment and scheduled a two-week runtime to capture weekly seasonality in property search behaviour.

*Result:* The test reached significance on schedule. The new ranking improved contact-initiation rate and the team shipped the change with high confidence. The post-experiment write-up became a template for future search ranking tests.

STAR for behavioural questions ('tell me about a time you...'): Keep Situation and Task brief (two to three sentences combined) and spend most of your time on Action and Result. Quantify the Result with business outcomes, not just model metrics, whenever possible.

Technical design questions follow a consistent structure: clarify the problem and constraints first, state your approach and your reasoning, walk through the data pipeline, describe how you would evaluate and monitor, and close with trade-offs you considered.

Product analytics and case questions: Housing interviewers typically want to see you define the metric that matters for the business, describe how to measure it, identify data quality issues or confounds, and then propose an experiment or analysis plan.

Explaining ML concepts: always link the concept back to a Housing use case. If asked about regularisation, explain it and then say how L1 regularisation could help in a price model where many postcode dummy variables are sparse. This shows applied thinking, not just theory recall.

When you do not know the answer: say what you do know, reason from first principles out loud, and ask a clarifying question. Interviewers at product companies commonly value structured thinking over memorised answers.

Domain connection. Interviewers want to see that you can map ML techniques to real estate problems. Answers that stay purely abstract, without mentioning property data, listings, brokers, or buyer intent, are typically rated lower than answers that show product awareness.

Product intuition. Housing is a consumer product with brokers as a second key stakeholder. Expect questions about what metric matters to the business and how a model change translates into user or revenue impact, not just model accuracy.

Data hygiene awareness. Real estate data is messy: duplicate listings, missing carpet-area values, inconsistent locality names. Candidates who proactively discuss data validation and cleaning signal experience with production ML, not just notebook experiments.

Communication clarity. Data scientists at Housing work closely with product managers and broker-facing teams. Interviewers sometimes ask you to explain a model to a non-technical stakeholder as part of the round, so practise plain-language explanations.

End-to-end ownership. Show that you think about deployment, monitoring, and retraining, not just model building. Candidates who naturally bring up data drift, A/B testing, or retraining cadence as part of their workflow tend to stand out from those who stop at 'the model trained well.'

Week 1: Core ML and statistics

Revise regression, classification, tree-based models, and clustering. Focus on gradient boosting (XGBoost, LightGBM) since structured real estate data suits these well. Review probability, Bayes theorem, and hypothesis testing, which appear often in take-home assignments and early technical rounds.

Week 2: Product and domain prep

Use Housing's app actively. Note how search ranking works, what filters exist, and where personalisation appears. Think through how you would measure success for each product surface: recommendations, search results, and listing detail pages.

Week 3: Case studies and system design

Practise open-ended questions such as 'Design a property price estimator for tier-2 cities' or 'Build a fraud detection system for listings.' Use the technical design framework above to structure your answers before you start speaking.

Week 4: Behavioural prep and mock interviews

Prepare three to four STAR stories covering model ownership, cross-functional collaboration, and handling failure or ambiguity. Do at least two timed mock interviews with a peer or mentor who can give honest feedback on your clarity and structure.

While you prep, knok checks 150+ job sites nightly, applies to Data Scientist openings that match your resume (including Housing's active listings), and messages HR on your behalf. That keeps your application pipeline moving even when you are deep in interview preparation.

1. Skipping domain context. Answering a recommendation question with generic theory, without connecting it to property search or Housing's product, leaves interviewers underwhelmed. Always link your answer to a real estate use case.

1. Ignoring data quality. Jumping straight to modelling without discussing how you would clean or validate real estate data signals inexperience with production ML pipelines.

1. Optimising only for model accuracy. Housing cares about business outcomes such as contacts made, site visits booked, and listings converted. Candidates who only discuss precision or recall without linking to business impact miss the mark.

1. Over-engineering answers. Proposing a complex deep learning pipeline when a well-tuned gradient boosting model with good features would serve structured property data better is a flag for poor practical judgment.

1. Not asking clarifying questions. In design rounds, jumping to a solution before pinning down scale, latency constraints, or available data suggests shallow problem-solving. Pause, ask, then answer.

1. Weak results in STAR answers. Saying 'the model improved' without any concrete outcome (even a qualitative one like 'the sales team reported higher conversion on top-scored leads') makes behavioural answers hard to evaluate and forgettable.