housing Data Analyst Interview: Questions & Prep (2026)

Housing.com, part of the REA India group, runs one of India's most visited real estate portals covering property buying, renting, and home loans. Data Analysts here sit at the intersection of product, growth, and revenue teams, turning raw listing and search data into decisions that affect millions of property seekers every month.

As of July 2026, Housing had 188 open Data Analyst roles, making it one of the most active hirers in the PropTech space right now. The interview process typically runs 3-4 rounds: an initial screening call, one or two technical rounds covering SQL and case studies, and a final hiring-manager round. Candidates report that Housing interviewers care as much about your understanding of the real estate business as your technical skills, so product intuition matters alongside SQL fluency.

Salary bands for Data Analyst roles across the industry sit at 5-10 LPA for 0-2 years of experience, 10-18 LPA for 3-5 years, 18-30 LPA at senior level (6-9 years), and 28-45+ LPA at lead level.

These 10 questions come up repeatedly in Housing.com Data Analyst interviews, based on candidate reports and the nature of the platform.

1. 'Why did our listing-to-lead conversion drop last week, and how would you diagnose it?' This tests your ability to break a metric into components and find the root cause systematically.

1. 'Write a SQL query to find the top 3 localities in each city by number of active listings.' Expect window functions such as RANK or DENSE_RANK, and a clear definition of what 'active' means.

1. 'How would you design a pricing recommendation tool to help a seller price their flat competitively?' Tests your grasp of regression, feature selection, and business framing in a real estate context.

1. 'We launched a new listing photo carousel. How would you measure whether it improved engagement?' Classic A/B testing and metric-selection question with a Housing-specific hook.

1. 'Our data has many listings with missing BHK count or incorrect carpet area. How do you handle this?' Tests data quality judgment, not just imputation techniques.

1. 'How would you define and calculate time-on-market for a property, and what factors would you expect to influence it?' Looks for real estate domain thinking alongside metric definition skills.

1. 'Segment our daily users into meaningful groups based on their search behavior.' Open-ended question inviting clustering or rule-based segmentation with a clear business purpose.

1. 'How would you detect duplicate or fraudulent property listings at scale?' Tests practical data thinking and anomaly detection reasoning.

1. 'Leads in Pune are falling while Bangalore is growing. What would you investigate first?' Tests structured multi-factor analysis and business context awareness.

1. 'Build a dashboard for the Sales team to prioritise which leads to follow up on first.' Tests your understanding of the sales workflow and which metrics drive real action.

Q: Why did our listing-to-lead conversion drop last week?

*Situation:* At my previous company, a similar metric, form submissions from property detail pages, dropped sharply over a weekend.

*Task:* I needed to find the root cause quickly because the sales team depended on that lead volume.

*Action:* I first checked whether the drop was uniform or concentrated in a segment: device type, city, listing category, or traffic source. I found that mobile traffic from one city had near-zero conversions, which pointed to a UI bug introduced in the latest app release. I confirmed this by cross-referencing the deployment log with the metric timestamp, then escalated to engineering with a reproducible scenario.

*Result:* The bug was rolled back within hours and conversion recovered. The episode also led us to add city-by-device conversion to our daily anomaly alert dashboard.

---

Q: How would you segment users based on search behavior?

*Situation:* A growth team I worked with wanted to personalise push notifications for a real estate app but had no existing user segments.

*Task:* I was asked to propose a segmentation framework and validate it with actual data.

*Action:* I used search filters as signals: whether users searched for rent vs. buy, BHK preference, budget range, and visit frequency. I grouped these into four intent buckets using a combination of rule-based logic and k-means clustering on session features. I validated the clusters by checking whether they showed meaningfully different click-through rates on notification nudges.

*Result:* Personalised notifications for the 'active buyer' segment achieved a noticeably higher open rate than the generic campaign, according to the A/B test results the team ran afterward. The segments became the foundation for all subsequent targeting.

---

Q: How would you handle missing BHK data in listings?

*Situation:* At a data team I joined, many new listings came in without a BHK field populated, a problem that industry surveys suggest is common for portals accepting free-form seller input.

*Task:* The product team needed BHK to be accurate for search filters to work correctly.

*Action:* I audited where the missingness concentrated and found it was mostly from listings entered via the mobile app by individual sellers, not agencies. I built a lightweight model predicting BHK from carpet area, locality, and price band, trained on listings where BHK was known. For edge cases, I flagged listings for a quality-review queue. I also worked with product to make BHK a required field in the app form going forward.

*Result:* Missing BHK dropped sharply over the following two months. The model handled existing gaps with accuracy the product team found acceptable for filter purposes, confirmed through a manual audit of a sample set.

For metric-drop questions, use a top-down decomposition. Start with: is the drop real (data pipeline issue?) or real user behavior (actual change)? Then break the metric into components. Listing-to-lead conversion equals leads divided by listing views, so check both sides. Then cut by segment: city, device, listing type, traffic source. Finally check for external events: competitor campaign, app release, or news affecting buyer sentiment. Interviewers want a systematic path, not guessing.

For SQL questions, Housing interviewers commonly ask about window functions, especially RANK and ROW_NUMBER over partitions like city or locality. They also test self-joins for duplicate detection and date-range filtering for 'active listing' definitions. Write clean, readable SQL with aliases on every table and brief comments explaining each CTE. Candidates report that explaining your logic out loud matters as much as getting the exact syntax right.

For experiment design questions, cover four things in order: what is the primary metric and the guardrail metric, how do you randomise (user-level or listing-level), what sample size is needed (reference publicly reported conversion rates for similar products if you lack internal data), and how long do you run the test. Always explain why you avoid peeking at results mid-experiment.

For open-ended product questions, use a simple structure: restate the business goal, define the metric that measures it, identify the data you need, list the analysis steps, and finish with what decision the output enables. This shows you think in outcomes, not just analysis steps.

Housing.com interviewers typically look for four things beyond raw SQL skill.

Business fluency. Can you connect your analysis to a real estate outcome: seller retention, lead quality, agent productivity, or buyer conversion? Generic answers that could apply to any e-commerce company score lower than answers that reference listing lifecycle, search intent, or property price sensitivity specific to the Housing platform.

Structured thinking under ambiguity. Real estate data is messy: inconsistent area units, duplicate listings, incomplete seller information. Interviewers want to see that you ask clarifying questions, state your assumptions clearly, and have a plan for data quality before diving into the analysis.

Communication for non-technical stakeholders. Housing has large sales and operations teams. Candidates who can explain a cohort drop to a city manager, not just to an engineering team, stand out consistently in the process.

Ownership. Candidates report that Housing values analysts who follow through: you do not just flag a problem, you push for the fix and measure whether it worked. In your STAR answers, always include what happened after your analysis, not just what you discovered.

Week 1: SQL and data fundamentals. Practice window functions (RANK, LAG, LEAD), CTEs, and aggregations on datasets resembling listing or transaction data. LeetCode medium-difficulty problems and StrataScratch both have real estate-flavored SQL questions worth working through.

Week 2: Product and metrics. Study Housing.com's product carefully. Use the app as a property seeker would. Note every metric you can infer: search-to-shortlist rate, listing view duration, lead submission rate, response time from sellers. Think about what moves each metric and what would make it drop.

Week 3: Case study practice. Run through 5-6 metric-drop and experiment-design scenarios out loud. Time yourself to about 10 minutes per answer. Ask a friend to play the interviewer and push back on your assumptions, especially around data quality.

Week 4: Behavioral and company research. Prepare 3-4 STAR stories covering a data quality issue you solved, a time you influenced a decision with data, and a time your analysis was wrong and what you learned from it. Research Housing's recent product launches, their parent company REA India, and PropTech trends in India for 2025-2026.

Day before. Review your SQL notes, re-read your STAR stories, and rest. Do not cram new concepts the night before.

While you prep, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR on your behalf, so you do not miss a new Housing.com opening while you are studying.

Jumping to solutions before defining the problem. When asked 'why are leads dropping,' many candidates immediately suggest causes. Interviewers expect you to first ask: what time period, which city, which listing type, is this metric from a reliable pipeline? Defining the problem well is part of the answer, not a preamble to it.

Writing SQL that works but cannot be explained. If you use a window function, be ready to explain why you chose RANK over ROW_NUMBER and what happens with ties. Candidates who have memorised patterns but cannot trace through the logic often get caught in follow-up questions.

Ignoring data quality in case studies. Real estate data at Housing has known quirks: duplicate listings, missing fields, inflated area claims from sellers. Candidates who assume clean data in their analysis come across as inexperienced with production systems.

Generic behavioral answers. Saying 'I improved the dashboard and stakeholders were happy' is not enough. Give a specific metric that changed, a specific person whose decision shifted, and a specific learning you carried forward.

Underselling the Result in STAR answers. Many candidates spend most of their answer on Situation and Action, then rush the Result in a single sentence. The interviewer cares most about what your work actually changed, so make the Result the most detailed and concrete part of your answer.