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

Housing.com is one of India's top property search platforms, now part of REA India (backed by the global REA Group). Their QA team keeps property listings, search filters, map features, and booking flows working reliably for millions of users. As of July 2026, Housing has 188 open QA Engineer roles, making it one of the most active hirers in this space among the 459 QA Engineer openings tracked in the broader market.

The interview process typically spans 3-4 rounds. Candidates report an initial HR screening call, followed by one or two technical rounds covering manual testing concepts, automation tools (Selenium, Appium, or REST Assured), SQL queries, and scenario-based testing tied to Housing's own product. A final round with a manager or senior QA lead is also common. The complete process typically wraps up within 2-3 weeks from application to offer.

Salary bands for QA roles at Housing.com align with market data: Entry-level (0-2 years) roles fall in the 4-9 LPA range, mid-level (3-5 years) in the 9-17 LPA range, senior (6-9 years) in the 17-30 LPA range, and lead roles in the 28-45+ LPA range.

1. How would you write a test plan for the property search feature, covering filters like BHK type, price range, and locality?
2. Walk us through how you would test a map-based property listing page end-to-end.
3. How have you used Selenium or Appium in a previous project? Describe a real automation challenge you solved.
4. How would you approach API testing for a property listings endpoint? What validations would you include?
5. What is your process for writing SQL queries to validate data during backend testing?
6. Housing's app sees high traffic during festive seasons. How would you approach performance or load testing for the search feature?
7. Describe how you have handled flaky or unstable tests in an automation suite.
8. How do you decide which test cases to automate versus keep as manual tests?
9. You find three bugs on the day before a release. How do you prioritize and communicate them to the team?
10. How would you test a new 'saved search' or 'property alerts' feature added to the Housing app?
11. Walk us through your experience integrating automated tests into a CI/CD pipeline.
12. How do you test location-based features like map pins, locality auto-suggest, or radius-based property search?

Q: How would you write a test plan for the property search feature, covering filters like BHK type, price range, and locality?

*Situation:* At my previous company, we launched a multi-filter search feature for a classifieds platform with a flow very similar to Housing's property search.

*Task:* I was responsible for creating the complete test plan for the filter functionality before the feature went live.

*Action:* I broke the feature into functional, boundary, and negative test cases. For BHK type, I tested valid selections (1 BHK, 2 BHK, 3 BHK, 4+ BHK), multi-select combinations, and deselection behavior. For price range, I tested reversed min/max inputs, zero values, and overlapping ranges. I also verified filter persistence when navigating back to results and deep-link sharing of filtered search URLs. Finally, I ran cross-browser checks on Chrome, Firefox, and the mobile app.

*Result:* We caught several defects before release, including a critical issue where the minimum price filter was being ignored on the backend. The feature launched with no severity-1 issues reported in the first week.

---

Q: Describe how you have handled flaky or unstable tests in an automation suite.

*Situation:* On a previous project, a large portion of our Selenium tests were failing intermittently in the CI pipeline, causing false alerts and slowing down deployments.

*Task:* My task was to identify the root causes and bring the flakiness rate down to an acceptable level.

*Action:* I tagged all flaky tests and ran them in isolation to reproduce failures consistently. The main causes turned out to be timing issues (missing explicit waits), test data conflicts between parallel runs, and dynamic element IDs that changed between builds. I replaced all implicit waits with explicit waits using ExpectedConditions, created isolated test data sets for each parallel run, and replaced dynamic IDs with stable CSS selectors or data-testid attributes.

*Result:* The flakiness rate dropped significantly within one sprint. The team regained confidence in the pipeline and deployment frequency improved as a result.

---

Q: You find three bugs on the day before a release. How do you prioritize and communicate them to the team?

*Situation:* During final regression testing at my last company, I discovered three bugs the day before a scheduled production release.

*Task:* I had to assess severity, communicate risk clearly, and help the team decide whether to fix, defer, or release with each known issue.

*Action:* I categorized each bug by impact. The first was a P1 (payment flow broken for a specific payment method), the second was a P2 (filter count mismatch on search results), and the third was a P3 (minor UI misalignment on desktop). I documented clear reproduction steps, attached screenshots, and shared a short written summary with the dev lead and product manager. I recommended a hotfix for the P1, a post-release ticket for the P2, and acceptance of the P3 cosmetic issue. I also confirmed a rollback plan was in place before final sign-off.

*Result:* The P1 was fixed and verified within a few hours. The release went ahead on schedule and there were no production incidents related to quality.

The STAR method (Situation, Task, Action, Result) works best for behavioral questions at Housing and at most product companies. Keep each spoken answer to 2-3 minutes. Lead with context, spend most of your time on the Action, and end with a concrete outcome.

For technical scenario questions (such as 'how would you test X'), use a structured breakdown:

• Ask clarifying questions first: scope, platform (web or app), new feature or regression, user persona
• List the test types you would cover: functional, boundary, negative, performance, accessibility
• Cover all relevant layers: UI, API, database
• State your priority order and what you would automate versus keep manual

For SQL or API questions, talk through your logic step by step before writing anything. Interviewers want to hear your reasoning, not just the final answer.

For communication-style questions (how do you report a bug, how do you work with developers), use the 'Context, Action, Outcome' structure: briefly describe the situation, state what you personally did, and close with the result.

Housing.com QA interviewers typically look for candidates who understand the product, not just generic QA theory. If you have used the Housing app before the interview, you can reference real features (the property listing page, the map view, the home loan EMI calculator, saved searches) in your answers. This shows initiative and product awareness that textbook answers cannot.

Beyond technical skills, interviewers commonly value the following:

Product curiosity: Can you think like a user? Do you ask 'what could go wrong for the buyer or the seller' rather than just 'what are the acceptance criteria'?

Automation maturity: Entry-level candidates are expected to demonstrate Selenium or Appium basics. Mid and senior candidates should have built or maintained a framework, not just written test scripts inside someone else's setup.

Clear communication under pressure: Bug triage, release decisions, and dev-QA disagreements come up in behavioral rounds. Show that you can state your position clearly without being confrontational.

Ownership: Candidates who say 'the developer should have caught that' tend to get filtered out. Housing values QA engineers who treat quality as a shared responsibility and proactively raise risks early in the development cycle.

A focused two-week plan covers most of what Housing typically tests.

Week 1: Core technical skills

Spend the first few days revisiting Selenium WebDriver fundamentals: locators, explicit waits, the page object model, and handling dynamic elements. If you work with Appium for mobile, practice setting up a basic test on an Android emulator. Next, practice REST API testing using Postman or REST Assured: write GET and POST requests, validate response codes and JSON schema, and check error-handling behavior. Then solve several SQL problems covering joins, aggregations, and subqueries, using a property or listings-style schema as your context.

Week 2: Product and behavioral prep

Download the Housing.com app and spend an hour testing it as a user. Note 3-4 areas where testing would be complex, such as map-based search, price filter edge cases, or the lead submission form. Prepare STAR answers for: a bug you found late in the cycle, an automation challenge you solved, a time you disagreed with a developer on severity, and a feature you tested end-to-end.

Practice saying each answer aloud to stay within 2-3 minutes. On the day before the interview, review your resume line by line and be ready to explain or demo every tool and framework you have listed.

Giving only textbook definitions. If you say 'smoke testing checks the most critical features' and stop there, that tells the interviewer nothing. Always follow a definition with a concrete example from your own work.

Not asking clarifying questions on scenario questions. When asked 'how would you test Housing's property search,' jumping straight into test cases without first asking about scope (web or app, new feature or regression, which user persona) looks careless. A strong QA candidate asks before answering.

Overstating automation experience. If your resume lists Selenium but you only used a framework someone else built, be upfront. Interviewers probe with follow-up questions, and inconsistency looks worse than an honest gap.

Ignoring the product context. Generic answers like 'I would test all boundary values' without tying them to a Housing feature sound disconnected. Answers that reference property listings, booking flows, or the map view show you prepared seriously.

Focusing only on bugs found, never on bugs prevented. Housing values QA engineers who join sprint planning early and review requirements before code is written. Mention times you caught issues before they became defects, not just after.

Skipping non-functional testing. Performance, security basics, and accessibility are part of modern QA. Interviewers commonly ask at least one question about handling load on a high-traffic listing page, so have a basic answer ready.

While you focus on interview prep, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so you are not spending prep time on job boards.