QA interview guide

How would you test search and filters?

Search and filters are deceptively complex because users expect relevant, fast, consistent results. Interviewers look for coverage across input handling, relevance, filter logic, pagination, data freshness, and accessibility.

Practice this scenarioBrowse all questions

Write your own answer and compare it with senior QA coverage.

What interviewers expect

What interviewers expect

A strong answer covers exact search, partial search, empty query, long query, special characters, Unicode, no results, filters, sorting, pagination, highlighting, backend errors, permissions, and performance.

Checklist

Checklist

Use these practical prompts to build a complete answer. Strong interview responses usually include functional behavior, negative cases, security, backend/data risks, UX, accessibility, and reliability.

Functional checks

  • Search by title, body/content, tag, author, or supported fields returns expected results.
  • Exact match, partial match, case-insensitive match, typo handling, and relevance order are checked.
  • Users can open a correct result from the search results.

Filters, sorting, and pagination

  • Single filter, multiple filters, clear one filter, clear all filters, and combined search with filters work.
  • Sorting by relevance, date, name, or supported fields works with ascending and descending direction.
  • Pagination, next page, previous page, result count, no duplicates, and URL state are consistent.

Negative, security, and backend cases

  • Empty query, whitespace query, long query, special characters, Unicode, and no-results state are handled.
  • XSS, SQL/query injection, unauthorized content, private content, and deleted content are not exposed.
  • API parameters, status codes, backend errors, timeouts, and network failures are verified.

UX, accessibility, and performance

  • Loading state, highlighted matches, clear query, search again, keyboard submit, focus, and screen reader result announcements work.
  • Mobile layout avoids horizontal scroll.
  • Large result sets, slow queries, debounce, and search SLA are tested.

Complete interview coverage checklist

Aim to mention 20-40 concrete checks. This expanded list helps you turn a short answer into a structured senior-style response.

Search by title, body/content, tag, author, or supported fields returns expected results.
Exact match, partial match, case-insensitive match, typo handling, and relevance order are checked.
Users can open a correct result from the search results.
Single filter, multiple filters, clear one filter, clear all filters, and combined search with filters work.
Sorting by relevance, date, name, or supported fields works with ascending and descending direction.
Pagination, next page, previous page, result count, no duplicates, and URL state are consistent.
Empty query, whitespace query, long query, special characters, Unicode, and no-results state are handled.
XSS, SQL/query injection, unauthorized content, private content, and deleted content are not exposed.
API parameters, status codes, backend errors, timeouts, and network failures are verified.
Loading state, highlighted matches, clear query, search again, keyboard submit, focus, and screen reader result announcements work.
Mobile layout avoids horizontal scroll.
Large result sets, slow queries, debounce, and search SLA are tested.
Structure your answer: Start with searching existing content by supported fields and opening a result.
Structure your answer: Add input variations: empty, long, special characters, Unicode, exact, partial, case-insensitive.
Structure your answer: Add filters, sorting, pagination, URL state, and result count consistency.
Structure your answer: Add security, permissions, stale index behavior, backend failures, accessibility, and performance.
Do not miss: Relevance order and stale index behavior.
Do not miss: Filters and sorting combined with pagination.
Do not miss: Unauthorized or private content leakage.
Do not miss: Screen reader announcements for result changes.

Ready to practice?

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario

Answer structure

Strong answer structure

  1. Start with searching existing content by supported fields and opening a result.
  2. Add input variations: empty, long, special characters, Unicode, exact, partial, case-insensitive.
  3. Add filters, sorting, pagination, URL state, and result count consistency.
  4. Add security, permissions, stale index behavior, backend failures, accessibility, and performance.

Common missed areas

Common missed risks

Relevance order and stale index behavior.
Filters and sorting combined with pagination.
Unauthorized or private content leakage.
Screen reader announcements for result changes.

Answer template

Use this interview answer template

I would start with exact and partial search results, then cover empty and long queries, special characters, filters, sorting, pagination, no results, highlighted matches, unauthorized content, backend errors, stale index data, UX, accessibility, and performance on large result sets.

Use it as a structure, then replace the examples with specific checks for the feature you are discussing.

Common weak answer

“I would test valid and invalid cases.”

This is too generic because it does not show risk thinking. A stronger answer names the happy path, negative cases, security risks, backend/data behavior, UX/accessibility, and reliability concerns that matter for this exact scenario.

Examples

Weak answer vs stronger answer

Weak answer
“I would search empty name, existing name, and long name.”

This covers a few input cases, but misses search relevance, filters, sorting, pagination, highlighting, permissions, backend errors, accessibility, and performance.

Stronger answer
“I would test searching existing articles by title, body, tag, and author, exact and partial matches, relevance order, multiple results, no results, empty query, whitespace query, long query, special characters, Unicode, filters by tag and author, search combined with filters, sorting by relevance and date, pagination, no duplicate results across pages, highlighted matches, stale or deleted content not shown, unauthorized content hidden, backend errors, timeout, loading state, keyboard submit, screen reader result announcements, mobile layout, and performance on large result sets.”

FAQ

Frequently asked questions

What should I mention first when answering "How would you test search and filters?"

Start with searching existing content by supported fields and opening a result.

Should I include negative and edge cases?

Empty query, whitespace query, long query, special characters, Unicode, and no-results state are handled. XSS, SQL/query injection, unauthorized content, private content, and deleted content are not exposed.

Should I include security, API, or backend risks?

Empty query, whitespace query, long query, special characters, Unicode, and no-results state are handled. XSS, SQL/query injection, unauthorized content, private content, and deleted content are not exposed.

What are common missed risks?

Relevance order and stale index behavior. Filters and sorting combined with pagination. Unauthorized or private content leakage. Screen reader announcements for result changes.

How can I practice this answer?

Use the interactive how would you test search and filters? challenge to write your own answer, get checklist-based feedback, and compare your coverage with stronger QA thinking.

Practice

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario