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

Anarock is one of India's leading proptech companies, building technology for real estate transactions, broker networks, and property data analytics. As of July 2026, the company has 10 open Software Engineer roles, making it an active hiring season for engineers who want to work at the intersection of tech and real estate.

The interview process typically covers three to four rounds: a recruiter or HR screening call, one or two technical rounds focusing on coding and system design, and a final discussion with a senior engineer or manager. Candidates report that Anarock's technical rounds are practical, emphasising real-world scenarios over abstract puzzles. You may be asked to solve a coding problem live, design a data-heavy backend system, or walk through past engineering decisions you have made.

Because Anarock's products serve property buyers, sellers, brokers, and developers, having a basic sense of how a real estate platform works (search, lead capture, transaction tracking) gives you a genuine edge when contextualising your answers.

Salary ranges for Software Engineers in India, from knok jobradar data:

Your actual offer from Anarock will depend on your specific experience, skills, and negotiation.

These questions have been reported by candidates or are closely aligned with the kinds of problems Anarock's engineering teams solve. Prepare concrete answers for each.

1. Walk us through a backend system you designed or built from scratch.
2. How would you design a property search feature that returns results quickly for a dataset with millions of listings?
3. Describe a time you identified and fixed a slow query or performance bottleneck in a production system.
4. How do you decide between SQL and NoSQL for a new project? Give a real example if you can.
5. How would you build a notification service that alerts buyers in real time when a matching property is listed?
6. Tell us about a time you had to deliver a feature under a tight deadline. What trade-offs did you make?
7. How do you approach securing a REST API you have built?
8. Describe a particularly difficult bug you debugged in production. What was your process?
9. How would you plan a migration from a monolithic application to microservices without breaking existing users?
10. Tell us about a time you disagreed with a teammate on a technical approach. What happened?
11. How do you write and maintain tests for features that change frequently?
12. What does a good code review look like to you, and what do you prioritise when reviewing someone else's code?

Use these as a starting point and replace the details with your own experience.

---

Q: Describe a time you identified and fixed a performance bottleneck in a production system.

*Situation:* At my previous company, our property listing API was timing out for users during peak hours. Response times had climbed to a point where the product team was fielding complaints.

*Task:* I was asked to investigate and fix the issue within a week without taking the API offline.

*Action:* I started by adding detailed query logging to identify which database calls were the slowest. I found that a join query across three large tables was doing a full table scan because an index had been accidentally dropped during a migration. I recreated the index, rewrote the query to reduce the result set before the join, and added a Redis caching layer for repeated searches with the same filters.

*Result:* Response times dropped significantly according to our monitoring tools, and the product team confirmed that timeout complaints stopped. I also wrote a runbook so the team could catch index issues earlier in future migrations.

---

Q: Tell us about a time you had to balance technical debt against a product deadline.

*Situation:* Our team was building a new broker dashboard for a client launch. Midway through, our engineering lead noticed that the data access layer was not following the patterns we had agreed on, which would make it harder to maintain long term.

*Task:* I had to decide whether to refactor the layer correctly before launch or ship with the existing approach and clean it up later.

*Action:* I had an honest conversation with my lead and the product manager. I proposed a middle path: ship the feature using the existing approach, document the technical debt clearly in our tracker, and schedule a focused cleanup sprint in the next cycle. I also added a comment in the code pointing to the tracker item so no one would forget it existed.

*Result:* We hit the client launch date. The cleanup sprint was completed two cycles later, and the refactored layer is now the standard pattern for all new modules in that service.

---

Q: Tell us about a time you disagreed with a teammate on a technical approach. What happened?

*Situation:* A colleague wanted to use a third-party service for handling property image uploads, while I believed we should build a lightweight internal solution to avoid vendor dependency and extra cost.

*Task:* We needed to align quickly because the feature was blocking another team.

*Action:* Instead of debating based on preference, I put together a short comparison covering setup time, ongoing cost, failure modes, and team control for each option. I shared this with the team and invited my colleague to add anything I had missed. We then presented both options to the engineering manager together.

*Result:* The manager chose the third-party service for the first version, with an agreed review point at six months. My colleague and I both felt heard. At the six-month review, the service was working well, so we kept it.

The STAR method (Situation, Task, Action, Result) is the most reliable structure for behavioural questions. State the context briefly, explain what you were responsible for, describe the specific steps you took, and close with a concrete outcome. Aim for around two minutes per answer.

For system design questions, start by clarifying requirements before jumping into architecture. Candidates report that Anarock interviewers appreciate when you ask: 'What is the expected volume of users?' or 'Does this need to be real time, or can it be near-real-time?' Then sketch a high-level design, walk through the data model, and talk through trade-offs. For a property search system, for example, you would cover indexing strategies, caching, and how you handle filters at scale.

For coding questions, think out loud as you go. Anarock interviewers typically want to see your problem-solving process, not just the final answer. Start with a brute-force approach, state its complexity, and then improve it step by step. If you are unsure about something, say so and talk through your reasoning rather than going silent.

For questions about past decisions, be honest about trade-offs. Avoid presenting yourself as always making the perfect call. Interviewers value engineers who can articulate what they learned from a mistake and what they would do differently next time.

Strong fundamentals. Anarock engineers build data-intensive products, so expect to demonstrate solid knowledge of databases (query optimisation, indexing, transactions), REST API design, and at least one backend language or framework well.

Practical problem-solving. The technical rounds are reported to be grounded in realistic scenarios, like designing a search feature or handling concurrent writes. Interviewers want to see how you break down a problem, not just whether you can name an algorithm.

Domain curiosity. You do not need to be a real estate expert, but showing that you have thought about what a property platform needs (fast search, reliable transaction records, notifications, broker tools) signals genuine interest in the company's work.

Collaboration and communication. For mid and senior roles, candidates report that Anarock places real weight on how you work with product managers, designers, and other engineers. Be ready to talk about how you handle disagreements, unblock teammates, and communicate technical constraints to non-technical stakeholders.

Ownership. Anarock is a growth-stage company, and interviewers typically respond well to candidates who take end-to-end responsibility for features, including deployment, monitoring, and bug fixes after launch.

Week 1: Refresh your fundamentals.
Revisit data structures and algorithms at the level of arrays, trees, graphs, and dynamic programming. Practice writing clean code in your primary language. Brush up on database concepts: indexing, query plans, transactions, and when to use relational vs. document stores.

Week 2: Practice system design.
Work through two or three system design problems relevant to Anarock's domain. Try designing a property search API, a notification service, or a lead management system. Practice articulating trade-offs clearly. Read about caching strategies (Redis, CDN), message queues, and API gateway patterns.

Week 3: Prepare your stories.
Write out five to seven experiences from your career using the STAR format. Cover at least one example each of: solving a performance problem, handling a deadline under pressure, a technical disagreement you navigated, and something you built and maintained end-to-end.

Week 4: Research Anarock and do mock interviews.
Read about Anarock's products and the problems they solve in the Indian real estate market. Do at least two mock interviews with a peer or on an online practice platform. Review your code for any live coding practice and ask for honest feedback on your communication.

On the day: Prepare two or three thoughtful questions for your interviewer. Asking about the tech stack, team structure, or a recent engineering challenge shows genuine interest and leaves a strong impression.

Going straight to code without clarifying requirements. In system design and even coding rounds, candidates who jump to implementation before asking clarifying questions often solve the wrong problem. Take thirty seconds to confirm scope before writing a single line.

Vague STAR answers. Saying 'I improved performance' is not enough. Interviewers want to know what you specifically did, what tools you used, and what changed as a result. If you do not have exact metrics, describe the qualitative impact clearly and confidently.

Over-engineering system design. A common mistake is proposing a highly complex distributed architecture for a problem that does not need it. Anarock interviewers typically value a pragmatic design that addresses the actual requirements over a theoretically impressive one that ignores constraints.

Not knowing your own resume. Candidates sometimes cannot explain projects or technologies listed on their CV in depth. Every item on your resume is fair game. Be ready to go deep on anything you have listed, especially projects that seem impressive on paper.

Treating salary as an afterthought. Know your number before the HR round. Research market ranges using sources like Glassdoor or levels.fyi and be ready to state a range confidently. Vague answers like 'whatever is standard' leave money on the table.

Not asking questions. Candidates who ask nothing at the end of an interview signal low interest. Prepare two or three genuine questions about the role, the team, or the product roadmap.