# Clarify and Implement Search Filters for a Library Table An existing library-management application shows a book table that users find too long and difficult to navigate. The initial request is to add a text search input and two dropdown filters. Important details—filter fields, labels, option values, matching rules, styling, and interaction behavior—have not yet been agreed. Explain how you would gather the missing requirements, turn them into an acceptance contract, locate the relevant code, implement the feature, and provide unit and integration coverage. ### Constraints & Assumptions - Work within an existing frontend/backend repository rather than rebuilding the page. - The table may be backed by either a complete client-side data set or a paginated server query; determine which before choosing the filtering layer. - The feature needs accessible labels, keyboard use, and clear empty/loading/error states. - Avoid assuming the two dropdown dimensions or exact copy until a stakeholder confirms them. ### Clarifying Questions to Ask - Which fields do text search and each dropdown affect, and how are options populated? - Is matching case-sensitive, prefix-based, substring-based, or token-based? - Can filters be combined, and is the relationship AND or OR? - Should state persist in the URL, survive refresh, or be shareable? - How should pagination, sorting, debounce, reset, and “no results” behave? - Which visual and accessibility conventions already exist in the product? ### Part 1: Requirement Discovery Produce a concise acceptance contract that resolves user-visible behavior while identifying any item that still needs a decision. #### What This Part Should Cover - Exact filter semantics, defaults, combinations, and state persistence. - Accessibility and edge-state behavior. - A distinction between required behavior and unconfirmed presentation details. ### Part 2: Implementation and Tests Describe the code changes and test plan. Explain whether filtering belongs on the client or server and how you would protect against regressions in the existing table. #### What This Part Should Cover - Reuse of existing table, form, URL-state, and query abstractions. - A clear data flow and bounded request behavior. - Unit tests for filter logic and integration tests for combined user interactions. ### Solving Hints - Inspect existing patterns before introducing new state or components. - Write the behavior table before editing code so unresolved copy does not block core logic. ### What a Strong Answer Covers - Focused questions that close consequential ambiguity without turning discovery into an endless interview. - Traceability from each accepted behavior to implementation and tests. - Correct handling of server pagination versus client filtering. - Accessible controls, deterministic combined filters, URL/reset behavior, and realistic failure states. - A safe incremental delivery and commit strategy in an unfamiliar repository. ### Follow-up Questions 1. What breaks if you filter only the currently loaded page of a paginated result? 2. How would you prevent stale search responses from replacing newer results? 3. Which tests should use real request handling rather than mocking the data layer? 4. How would you ship the feature if one dropdown's final copy is still undecided?