housing Frontend Engineer Interview: Questions & Prep (2026)

Housing.com (part of REA India group) is one of India's largest real estate discovery platforms, connecting buyers, renters, and sellers across hundreds of cities. The frontend engineering team is central to the product: they own property search, map-based browsing, listing pages, and lead generation flows.

As of July 2026, Housing has 188 open frontend roles, making it one of the more active hirers in the Indian product-company space right now. The broader market shows 405 Frontend Engineer openings tracked by knok jobradar, with Bangalore leading at 102 roles, Delhi at 36, and Pune at 11.

Candidates report the process typically runs 3-4 rounds: an initial screen or online test, one or two technical rounds covering JavaScript and React, a frontend system design discussion, and a final conversation with the engineering manager. Housing interviewers focus on real-product scenarios tied to maps, search UX, performance, and mobile-first design.

Salary bands for this role (knok jobradar data, July 2026):

These questions reflect patterns candidates report in Housing frontend interviews. They lean heavily toward React architecture, browser performance, and product thinking tied to Housing's actual platform.

1. How would you design the property search results page to handle complex filters, map syncing, and large volumes of listings at the same time?
2. Housing uses maps as a core part of its search experience. How would you render and cluster thousands of property pins without causing the browser to lag?
3. Walk us through how you would cut the initial load time on a listing detail page that has hero images, an embedded map, and dynamic pricing data.
4. How do you handle state sharing between the filter sidebar, the results list, and the map view when filters change rapidly and all three must stay in sync?
5. How would you implement infinite scroll for property listings? When would you prefer pagination instead, and what are the trade-offs for each?
6. A user on a slow mobile connection in a tier-2 city opens the Housing app. What specific frontend techniques would you apply to make their experience usable?
7. How do you approach lazy loading images in a grid of property cards, and how do you prevent layout shift (CLS) as those images load in?
8. How would you structure a micro-frontend setup if Housing's buy, rent, and commercial sections needed to deploy and scale independently?
9. Walk us through how you would build an accessible property search form, covering keyboard navigation and screen reader support end to end.
10. How do you test complex React components that depend on API calls, map libraries, and user interactions across different component states and loading conditions?
11. Describe how you would set up code splitting and dynamic imports in a large React codebase like Housing's to keep bundle sizes manageable.
12. Tell us about the most impactful frontend performance improvement you have shipped. What did you measure, what did you change, and what was the result?

Q: How did you optimize the performance of a data-heavy React application?

*Situation:* At my previous company, our property listing page was loading slowly on mid-range Android devices. Users were dropping off before the main content appeared.

*Task:* I was responsible for improving the Largest Contentful Paint to reach the commonly cited 'good' threshold, which is publicly reported by Google as under 2.5 seconds on mobile.

*Action:* I audited the page with Lighthouse and found three main issues: a large JavaScript bundle, unoptimized images, and several waterfall API calls. I split the bundle using React.lazy and Suspense so non-critical components loaded after the main content. I converted images to WebP with explicit width and height attributes to eliminate layout shift. I then worked with the backend team to combine three separate data calls into one aggregated endpoint.

*Result:* LCP moved into the 'good' range on our internal monitoring. Analytics tracked over a four-week period showed a clear drop in mobile bounce rate that correlated with the deployment.

---

Q: Describe a complex state management problem you solved in React.

*Situation:* Our search page had a filter sidebar, a map view, and a results list that all needed to stay in sync. State was being passed through several component layers via prop drilling, which made the code fragile and hard to extend.

*Task:* I needed to refactor the architecture so any filter change updated both the map and the results list together, without the prop-drilling mess.

*Action:* I introduced a centralized search context using React Context with useReducer. Each filter dispatched a typed action; the map and the results list were both consumers of that context. I also added debouncing on filter changes so we were not firing API calls on every keystroke during rapid input.

*Result:* Adding a new filter went from requiring changes across several files to writing one action type and one new component. QA reported fewer cross-component bugs in the two sprints that followed the refactor.

---

Q: Tell us about a time you built a feature that meaningfully improved user experience.

*Situation:* Users on our platform were dropping off mid-search because scrolling through long result lists was tedious, especially on mobile where the content felt endless.

*Task:* I was asked to prototype and ship a map-first search mode where dragging the map would update the visible results in real time.

*Action:* I integrated a map library with a debounced 'bounds_changed' event listener. When the user stopped dragging, the app fetched listings within those coordinates and updated the results panel alongside the map. I added a skeleton loader so users got immediate feedback while data loaded. I also persisted the last map position in session storage so a page refresh returned users to the same area.

*Result:* Internal analytics showed a measurable increase in listings viewed per session after launch. The team later adopted this as the default search experience for mobile users.

For system design questions (like 'design the search results page'): Start by asking clarifying questions about scale, target devices, and acceptable latency. Then walk through component breakdown, data flow, and state management decisions. Close with performance and accessibility considerations. Housing interviewers want to see that you think about real users, not just clean diagrams.

For performance questions: Use a Measure, Diagnose, Fix structure. Name the specific metric you were targeting (LCP, CLS, INP). Name the tool you used to find the bottleneck. Explain exactly what you changed and why you chose that fix over alternatives. Then state the outcome with whatever real data you had.

For JavaScript or React fundamentals: Answer in layers. Give the correct definition first. Then explain 'why it matters in practice' with a concrete example from your own work. Avoid vague statements like 'it improves performance'; name the specific mechanism that does the work.

For behavioral questions ('tell me about a time...'): Use STAR (Situation, Task, Action, Result) but keep Situation and Task brief, roughly two or three sentences combined. Housing interviewers typically want the bulk of your answer in Action and Result. Quantify the result wherever you have real data to draw on.

Based on candidate reports, Housing frontend interviews consistently look for these qualities:

Product sense alongside technical depth. Interviewers often frame questions around real Housing use cases: map search, listing pages, lead forms. They want to see that you think about users, not just code. Mentioning mobile-first users, slow network conditions, or regional device diversity in your answers tends to land well.

Hands-on React experience, not just theory. Expect to write code during the interview, discuss hooks in depth (useEffect dependencies, custom hooks, memoization trade-offs), and explain why you made specific architectural choices. Citing a library name without being able to explain how it works internally is a common place candidates lose points.

Performance as a first-class concern. Real estate platforms depend on fast-loading pages. Candidates who speak fluently about Core Web Vitals, image optimization, bundle analysis, and lazy loading consistently stand out from those who know the concepts but cannot connect them to real decisions.

Clear communication under pressure. Housing interviews are typically conversational rather than whiteboard-heavy. Interviewers may push back on your approach to see how you handle disagreement. They want to know whether you can defend a technical choice with clear logic, not just confidence.

Week 1: JavaScript and React fundamentals.
Review closures, the event loop, promises, and async/await until you can explain them without notes. For React, revisit useEffect cleanup, useCallback vs useMemo, controlled vs uncontrolled components, and how reconciliation works under the hood. Practice explaining these out loud, not just writing them.

Week 2: Performance and browser internals.
Study Core Web Vitals (LCP, CLS, INP) and how to measure each with Lighthouse and Chrome DevTools. Pick a React app you have access to and practice a mock performance audit: identify three bottlenecks and explain what you would change first and why.

Week 3: Frontend system design.
Practice designing systems that mirror Housing's product: a map-based property search page, an image-heavy listing feed, a real-time saved-search notification panel. For each one, use the structure: clarify requirements, component breakdown, data flow, performance, then accessibility.

Week 4: Behavioral prep and mock interviews.
Write out 4-5 STAR stories from your experience covering a performance win, a complex state problem, a cross-team collaboration, and a failure you learned from. Do at least two timed mock interviews with a peer or an online practice platform so thinking out loud under pressure feels natural.

While you are deep in prep, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so your applications keep moving even when your focus is on interviews.

1. Giving generic React answers. Saying 'I use Redux for state management' without explaining when you would choose it over Context or Zustand, and why, reads as surface-level preparation to Housing interviewers.

1. Skipping the 'why' in system design. Listing components without discussing trade-offs (client-side filtering vs. server-side, one global store vs. co-located state) makes answers feel incomplete even when the components themselves are correct.

1. Ignoring mobile and network constraints. Housing has a large user base on slower networks and mid-range devices. Candidates who design only for fast desktop connections tend to score lower on product empathy questions.

1. Freezing on follow-up questions. Interviewers typically push back to test depth. If you cannot explain the internal behavior behind your answer, treat that as a signal to go deeper on that topic before your interview.

1. Under-preparing for live coding. Knowing a concept is not the same as solving a problem out loud while explaining your thinking under time pressure. Practice this as a separate skill.

1. Not asking clarifying questions in system design. Jumping straight into a solution without confirming scale, user type, or device constraints is one of the most common misses. Interviewers often want to see your thought process before they want your answer.