anarock Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

Anarock is one of India's largest real estate advisory and technology platforms, using data to connect buyers, sellers, and developers across the country. As of July 2026, knok's job radar shows anarock has 10 open Machine Learning Engineer positions. For wider market context, there are 803 ML Engineer roles tracked across India, with Bangalore leading at 165 openings, followed by Delhi (50), Hyderabad (27), Mumbai (15), Pune (14), and Chennai (14).

At anarock, ML engineers typically work on property price prediction, lead scoring, buyer recommendation systems, and NLP pipelines for extracting insights from listing text and documents. Candidates report that the process typically involves an initial screening call, a take-home or online coding assessment, and two or three technical rounds followed by a hiring manager or culture discussion. Expect questions that blend core ML theory with real estate business context.

These questions come up most often, based on what candidates report from anarock ML Engineer interviews:

1. How would you build a property price prediction model from historical transaction data?
2. Walk us through how you would design a recommendation system for property listings.
3. How do you handle missing, noisy, or incomplete data in a real estate dataset?
4. How would you approach lead scoring for home buyers at different stages of their search?
5. When would you choose a gradient boosted tree model over a neural network for a structured data problem?
6. Describe a time you took an ML model from a notebook prototype to a production system.
7. How do you detect and respond to data drift in a live price prediction model?
8. What feature engineering techniques work well with location and geospatial data?
9. How do you evaluate a recommendation model when you have no explicit star ratings from users?
10. How would NLP help you extract structured information from unstructured property listing text?
11. How would you design an ML pipeline that retrains automatically on new data each week?
12. Tell me about a time your model failed or underperformed. What did you do?

Q: Describe a time you took a model from prototype to production.

*Situation:* At my previous company, the data science team had built a churn prediction model in a notebook, but it had never been deployed.

*Task:* My task was to productionize it so business teams could act on its output daily.

*Action:* I refactored the notebook into modular Python code, added unit tests for each transformation step, containerised it with Docker, and set up a scheduled pipeline to retrain on fresh data. I also built a simple monitoring dashboard to track prediction distribution and flag drift.

*Result:* The model went live within the same quarter. The customer success team used the daily churn scores to prioritise outreach, and renewal rates improved over the following months, which the business attributed in part to earlier interventions.

---

Q: Tell me about a time your model underperformed. What did you do?

*Situation:* I was working on a price estimation model for properties in tier-2 cities.

*Task:* After deployment, users flagged that estimates for certain localities felt off. My job was to investigate and fix the issue.

*Action:* I pulled error breakdowns by city and locality and found that the model was systematically underestimating prices in fast-appreciating micro-markets because training data from those areas was sparse. I sourced additional listings data, created locality-level embeddings as features, and retrained with a stratified split to ensure better coverage of those segments.

*Result:* Median absolute error dropped noticeably on the affected localities in post-deployment monitoring. I also set up alerts for when error rates crossed a threshold in any locality, so issues could be caught earlier next time.

---

Q: How do you handle missing data in a real estate dataset?

*Situation:* On a project involving property listings, key features like carpet area, floor number, and age of building had significant gaps.

*Task:* Simply dropping rows would have cost us a large share of training samples, so I needed a smarter approach.

*Action:* I first analysed missingness patterns to check whether data was missing at random or systematically. For numerical fields like area, I used median imputation grouped by locality and property type. For categorical fields, I added a dedicated 'unknown' category rather than guessing. I also created missingness indicator flags as additional features so the model could learn from the pattern itself.

*Result:* The model trained on the fuller dataset outperformed the version trained on complete cases only, and the missingness flags turned out to be predictive features in their own right.

For technical design questions (price prediction, recommendations, lead scoring), use this structure:

1. Frame the business problem in one or two sentences before touching any algorithm.
2. Describe the data you would need and where it might come from.
3. Walk through feature engineering choices, especially domain-specific ones like location, property type, or buyer intent signals.
4. Explain your model selection rationale, including why you would start simple.
5. Define the evaluation metric and why it fits the business goal.
6. Mention production considerations: retraining frequency, monitoring, and failure modes.

For behavioural questions, use the STAR structure: Situation, Task, Action, Result. Keep Situation and Task concise so you can devote most of your time to Action and Result. Interviewers want to hear what *you* did specifically, not just what the team did, so use 'I' when describing your own contribution.

For model comparison questions, avoid saying one approach is always better. Instead, reason through the trade-offs for the specific context: data size, interpretability requirements, latency constraints, and team familiarity. Anarock operates in a domain where business stakeholders often need to understand model outputs, so mentioning interpretability signals good judgement.

Candidates report that anarock interviewers look for a combination of solid ML fundamentals and genuine curiosity about the real estate domain. They want to see that you can connect a modelling decision to a business outcome, not just optimise a metric in isolation.

Domain awareness matters. You do not need prior real estate experience, but showing that you have thought about what makes property data different from typical tabular datasets (geospatial features, thin data in new localities, seasonality, regulatory changes) signals that you will ramp up quickly.

Production mindset is consistently valued. Being able to talk about monitoring, retraining pipelines, and handling model failures shows you think beyond the notebook.

Communication is important too. ML outputs at anarock inform decisions made by sales teams, product managers, and leadership. Interviewers want to know you can explain a model's output clearly to a non-technical audience.

Honesty about trade-offs is appreciated. Candidates who acknowledge limitations in their approach and reason through alternatives tend to do better than those who present a single answer as definitive.

First, understand anarock's product context. Read their public materials and news coverage. Knowing whether they focus more on CRM intelligence, pricing tools, or search personalisation will help you tailor your examples.

Second, solidify your ML fundamentals. Review supervised and unsupervised learning, regularisation, gradient boosting (XGBoost, LightGBM), and basic neural network concepts. Be ready to explain bias-variance trade-off and cross-validation clearly.

Third, practise applied problem-solving. Set up mock problems: design a property price predictor, a lead scoring model, and a listing recommendation engine. Walk through each end-to-end, including feature engineering and evaluation metrics.

Fourth, prepare your STAR stories. Have ready at least three examples from your own work: a model you shipped, a failure you diagnosed, and a time you worked with business stakeholders to define the problem. Keep each story crisp and specific.

Fifth, review ML system design. Be comfortable sketching out a retraining pipeline, a feature store setup, and a monitoring approach on a shared doc. Anarock candidates report that at least one round touches system design.

Sixth, prepare thoughtful questions. Ask about the team's current model deployment infrastructure, how ML outputs are consumed by business teams, and what the biggest unsolved data problems are. This signals genuine interest.

Jumping straight to a complex model. When asked to design a system, many candidates start with deep learning or large language models before considering whether a simpler model would work. Interviewers notice this and see it as poor judgement. Always justify model complexity.

Ignoring the business context. Saying 'I would minimise RMSE' without connecting it to what the business actually cares about, such as getting price estimates within a range acceptable to buyers, misses the point. Tie your technical choices to outcomes.

Vague STAR answers. Saying 'we built a recommendation system and it performed well' is not a STAR answer. Specify what *you* did, what the challenge was, and what changed as a result. Vagueness reads as low ownership.

Ignoring data quality issues. Real estate data is notoriously messy. Candidates who assume clean, complete datasets in their answers signal a lack of practical experience. Proactively raise data quality concerns.

Not asking clarifying questions. In design rounds, jumping into an answer without asking about scale, latency requirements, or available data signals poor engineering habits. A few well-chosen clarifying questions show structured thinking.

Over-claiming results. Avoid stating specific metric improvements you cannot substantiate. Interviewers sometimes probe numbers, and inconsistency damages credibility. Saying 'improved noticeably' or 'reduced error on the held-out set' is more honest and harder to challenge.