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

Housing.com, part of REA India, is one of India's most active real estate portals, connecting buyers, renters, and sellers across hundreds of cities. As of July 2026, knok jobradar tracked 188 open roles at Housing, making it one of the largest single-company hiring bursts in the Data Engineer market. The broader India market shows 542 Data Engineer openings, with Bangalore leading at 92, Delhi at 66, and Hyderabad and Pune each at 23.

Housing's data engineering work covers property listings, pricing signals, user search behaviour, lead pipelines, and agent performance data. Interviews typically assess SQL depth, pipeline architecture, and your ability to model messy real-world property data. Candidates report a process of a screening call, one or two technical rounds, and a final hiring manager discussion.

Salary ranges for Data Engineers across the market (commonly cited on Glassdoor and industry surveys, not Housing-specific guarantees):

These ranges reflect the broader India Data Engineer market. Housing's specific offers depend on team, role scope, and your negotiation.

1. Walk me through a data pipeline you built end-to-end. What design decisions did you make and why?

1. Write a SQL query to find the top 5 localities by average listing price.

1. How would you design a pipeline to ingest real-time property listing updates at scale?

1. How do you handle duplicate or malformed records in a listings ingestion job?

1. What is the difference between a star schema and a snowflake schema? Which would you pick for a real estate data warehouse and why?

1. You notice a sudden spike in NULL values in a key column mid-pipeline. How do you debug it?

1. How would you build a data model to track a property across its full lifecycle: listed, price changed, rented or sold, then delisted?

1. Describe a time a data quality issue affected a business decision. How did you catch it and fix it?

1. How would you optimise a Spark job that processes millions of listing events daily?

1. What does data observability mean to you, and how have you set it up before?

1. How would you build a near-real-time lead-scoring pipeline for Housing's sales team?

1. Looking at Housing's product (listings, search, agent tools), what data engineering challenges do you think the team faces most?

Q: Describe a data pipeline you built end-to-end.

*Situation:* My previous company ran a classifieds platform where listing data arrived from multiple city-level scrapers with inconsistent schemas.

*Task:* I had to build a reliable ingestion pipeline that unified these feeds into a clean, query-ready table for the analytics team.

*Action:* I set up an Airflow DAG that pulled raw JSON from S3, ran schema validation with Great Expectations, applied deduplication logic using a listing-ID hash, and loaded clean records into a Redshift staging table before a final merge. I added row-count anomaly alerts so silent failures would surface immediately.

*Result:* Data freshness improved from a daily batch to a few hours, and analyst complaints about missing or duplicate listings dropped significantly. The pipeline ran without manual intervention for several months.

---

Q: A sudden spike in NULLs appears in a key column. Walk me through your approach.

*Situation:* At a previous role, our property-price column started showing a high NULL rate overnight, breaking a downstream pricing dashboard.

*Task:* I had to find the root cause quickly because the sales team relied on that dashboard each morning.

*Action:* I checked row counts by source feed to isolate whether it was one upstream source or all of them. I then compared the schema of the current file against the previous day's file and found a vendor had renamed a field. I patched the parser, re-ran the affected partition, and added a schema-change alert for that feed going forward.

*Result:* The dashboard recovered before the sales team's start of day. We also added automated schema diffing as a standard pre-load check across all feeds.

---

Q: How would you model a property's full lifecycle in a data warehouse?

*Situation:* At a real estate analytics project, we needed to track how long properties stayed listed and what events happened before a transaction.

*Task:* Design a model that captured listing creation, price changes, status transitions, and eventual closure without losing history.

*Action:* I used a slowly changing dimension (SCD Type 2) approach for the property entity, with a separate fact table for events (price change, status change, agent reassignment). Each event row had a timestamp, event type, and before/after values. This let analysts query 'current state' easily while still being able to replay history.

*Result:* The model supported both operational dashboards and cohort analyses without any schema changes, because we designed for extensibility upfront. The team adopted it as their standard property modelling pattern.

For pipeline design questions: Use a structure of Source, Transform, Load, Monitor. Describe the source format and volume, how you validate and clean, where you load the output, and how you know the job succeeded or failed. Housing's interviewers care about 'what happens when things go wrong,' so always include your error-handling and alerting approach.

For SQL questions: Think aloud. State your assumptions first (for example: 'I will assume one row per listing per day in this table'). Write the query in stages: filter first, aggregate second, window functions last. For Housing's domain, common patterns are locality-level aggregations, time-series price tracking, and funnel-step counts.

For system design questions: Start with scale and constraints: events per day, latency requirement, team size maintaining it. Then sketch the flow: ingestion layer, processing, storage, serving. Use tools you have actually worked with rather than listing every buzzword. Housing typically uses cloud-native stacks, so AWS or GCP references land well.

For behavioural questions: Use STAR (Situation, Task, Action, Result). Keep Situation short (two sentences). Spend most time on Action: specific tools, specific decisions, and why you chose them. Result should be concrete but honest, even if you only have qualitative outcomes.

Housing's interviewers, based on candidate reports, look for a few things beyond raw technical skill.

Domain curiosity. Can you connect your answers to real estate? Listing data, pricing signals, search logs, lead pipelines. Candidates who ask sharp questions about Housing's actual data challenges tend to get stronger feedback.

Ownership mindset. They want engineers who see a pipeline as their responsibility end-to-end, not just the code they wrote. Mentioning monitoring, alerting, and incident response signals this clearly.

SQL depth. Real estate analytics is heavily SQL-driven. Window functions, CTEs, optimisation basics, and the ability to debug a slow query are tested consistently. Candidates report at least one hands-on SQL problem in every technical round.

Practical trade-offs. Interviewers appreciate when you say 'I chose X over Y because of Z constraint' rather than describing a theoretically perfect system. Realistic trade-off thinking stands out.

Communication clarity. Think aloud, structure your answers, and ask clarifying questions before diving in. This matters especially in system design rounds.

Week 1: SQL and domain grounding

Solve locality-level aggregation problems: average prices by city, funnel drop-off rates, ranking queries with window functions. Read publicly available Housing.com product blogs or press coverage to understand their buyer-renter-seller model and main product lines.

Week 2: Pipeline design and tooling

Revisit Airflow or whichever orchestration tool you know best. Review partitioning strategies, incremental loading patterns, and SCD Type 2 modelling. Pick one cloud platform (AWS or GCP) and be ready to sketch an end-to-end pipeline on a whiteboard or shared doc.

Week 3: Mock rounds and behavioural prep

Write out three to four STAR stories from your past covering: a pipeline failure you debugged, a data quality issue you caught, and a design decision you made under constraints. Practise talking through SQL queries aloud, because interviewers want to hear your reasoning, not just the final answer.

Before the interview: Review Housing's current product features and think about what data engineering challenges they plausibly face. Prepare two or three genuine questions for the interviewers about their stack, data quality practices, or team structure.

Jumping into code without clarifying assumptions. Interviewers at Housing typically want to see how you think before you write. State your assumptions, ask about scale and constraints, then code.

Ignoring failure modes. A pipeline answer that only covers the happy path signals inexperience. Always mention what happens when upstream data is late, malformed, or missing.

Generic answers with no domain link. Saying 'I would use Spark for large-scale processing' without tying it to listings, pricing, or search data sounds rehearsed. Connect your answers to real estate context wherever you can.

Overselling unfamiliar tools. If you have not used Kafka in production, say so. Claiming familiarity and then struggling on a follow-up hurts more than honesty does.

Skipping the result in STAR answers. Many candidates describe the action in detail but forget to close with what actually happened. Results, even qualitative ones, show you care about outcomes.

Not asking any questions. Candidates report that Housing interviewers expect genuine curiosity about the team and product. Asking nothing reads as low interest.